Switching to enforcing mode introduces new policy issues?

Switching to enforcing mode introduces new policy issues?

[Spector, Aaron]

[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]

Hi all,

I've been working on writing my first policy for SELinux and I've hit a bit of a snag. I've gotten the policy clean in permissive mode, but when I swap the system over to enforcing, a whole new set of policy issues crop up. Everything I've read says this isn't to be expected so I'm a bit confused as to what's happening. Output from sestatus when in permissive mode is:

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             default
Current mode:                   permissive
Mode from config file:          permissive
Policy MLS status:              enabled
Policy deny_unknown status:     denied
Max kernel policy version:      29

I'm running a version 26 policy and a 3.16.7 kernel.

It seems like the majority of the new deny audits are about the need for search permissions on directories between types that already have what I believe are the necessary file permissions.

So far what I've had to do to get around it is to add to my policy, but that doesn't seem like that should be necessary. If the audit is clean in permissive mode, why isn't it clean in enforcing?

Is it possible that I'm missing policy deny audits when it's in permissive mode?


Thanks,

-Aaron


[-- Attachment #2: Type: text/html, Size: 4478 bytes --]

Re: Switching to enforcing mode introduces new policy issues?

[Paul Moore]

On Thu, Apr 23, 2015 at 5:14 PM, Spector, Aaron
<Aaron_Spector@mcafee.com> wrote:
> Hi all,
>
> I’ve been working on writing my first policy for SELinux and I’ve hit a bit
> of a snag. I’ve gotten the policy clean in permissive mode, but when I swap
> the system over to enforcing, a whole new set of policy issues crop up.
> Everything I’ve read says this isn’t to be expected so I’m a bit confused as
> to what’s happening.

{snip}

> So far what I’ve had to do to get around it is to add to my policy, but that
> doesn’t seem like that should be necessary. If the audit is clean in
> permissive mode, why isn’t it clean in enforcing?
>
> Is it possible that I’m missing policy deny audits when it’s in permissive
> mode?

It's important to remember that when you are in permissive mode you
will only see a given SELinux AVC denial *once*, after that it will
not be reported until the AVC is reset.  My two favorite ways of
resetting the SELinux AVC are to run either 'load_policy' or toggle
the system from permissive into enforcing and then back into
permissive mode.  Try that and I suspect that will solve your problem.

-Paul

-- 
paul moore
www.paul-moore.com

RE: Switching to enforcing mode introduces new policy issues?

[Spector, Aaron]

That sounds like an idea, I'll have to give it a shot. To add a bit more information, I'm seeing a bunch of these changes happen during the boot process in init and I would assume the AVC is cleared between reboots - I've tweaked and added some things there for experimentation. I can boot my system up in permissive and see no problems, but when I restart it in enforcing I start seeing brand new policy violations, things I haven't seen before. It seems odd that the same boot sequence would result in such different behavior.

-Aaron

-----Original Message-----
From: Paul Moore [mailto:paul@paul-moore.com] 
Sent: Thursday, April 23, 2015 5:20 PM
To: Spector, Aaron
Cc: SELinux (selinux@tycho.nsa.gov)
Subject: Re: Switching to enforcing mode introduces new policy issues?

On Thu, Apr 23, 2015 at 5:14 PM, Spector, Aaron <Aaron_Spector@mcafee.com> wrote:
> Hi all,
>
> I’ve been working on writing my first policy for SELinux and I’ve hit 
> a bit of a snag. I’ve gotten the policy clean in permissive mode, but 
> when I swap the system over to enforcing, a whole new set of policy issues crop up.
> Everything I’ve read says this isn’t to be expected so I’m a bit 
> confused as to what’s happening.

{snip}

> So far what I’ve had to do to get around it is to add to my policy, 
> but that doesn’t seem like that should be necessary. If the audit is 
> clean in permissive mode, why isn’t it clean in enforcing?
>
> Is it possible that I’m missing policy deny audits when it’s in 
> permissive mode?

It's important to remember that when you are in permissive mode you will only see a given SELinux AVC denial *once*, after that it will not be reported until the AVC is reset.  My two favorite ways of resetting the SELinux AVC are to run either 'load_policy' or toggle the system from permissive into enforcing and then back into permissive mode.  Try that and I suspect that will solve your problem.

-Paul

--
paul moore
www.paul-moore.com

Re: Switching to enforcing mode introduces new policy issues?

[Gaurav Gangwar]

[-- Attachment #1: Type: text/plain, Size: 2825 bytes --]

Hi Aaron,

also check if you have modified the selinux code
also keep track of dmesg. i have noticed that few denials are only shown in
dmesg so $dmesg | grep avc is quit important while checking the boot time
denials.
one more thing you have to be sure is that u switch between permissive and
enforce mode on the same build/bootimage.


Thanks and Regards
Gaurav Gangwar

On 24 April 2015 at 09:42, Spector, Aaron <Aaron_Spector@mcafee.com> wrote:

> That sounds like an idea, I'll have to give it a shot. To add a bit more
> information, I'm seeing a bunch of these changes happen during the boot
> process in init and I would assume the AVC is cleared between reboots -
> I've tweaked and added some things there for experimentation. I can boot my
> system up in permissive and see no problems, but when I restart it in
> enforcing I start seeing brand new policy violations, things I haven't seen
> before. It seems odd that the same boot sequence would result in such
> different behavior.
>
> -Aaron
>
> -----Original Message-----
> From: Paul Moore [mailto:paul@paul-moore.com]
> Sent: Thursday, April 23, 2015 5:20 PM
> To: Spector, Aaron
> Cc: SELinux (selinux@tycho.nsa.gov)
> Subject: Re: Switching to enforcing mode introduces new policy issues?
>
> On Thu, Apr 23, 2015 at 5:14 PM, Spector, Aaron <Aaron_Spector@mcafee.com>
> wrote:
> > Hi all,
> >
> > I’ve been working on writing my first policy for SELinux and I’ve hit
> > a bit of a snag. I’ve gotten the policy clean in permissive mode, but
> > when I swap the system over to enforcing, a whole new set of policy
> issues crop up.
> > Everything I’ve read says this isn’t to be expected so I’m a bit
> > confused as to what’s happening.
>
> {snip}
>
> > So far what I’ve had to do to get around it is to add to my policy,
> > but that doesn’t seem like that should be necessary. If the audit is
> > clean in permissive mode, why isn’t it clean in enforcing?
> >
> > Is it possible that I’m missing policy deny audits when it’s in
> > permissive mode?
>
> It's important to remember that when you are in permissive mode you will
> only see a given SELinux AVC denial *once*, after that it will not be
> reported until the AVC is reset.  My two favorite ways of resetting the
> SELinux AVC are to run either 'load_policy' or toggle the system from
> permissive into enforcing and then back into permissive mode.  Try that and
> I suspect that will solve your problem.
>
> -Paul
>
> --
> paul moore
> www.paul-moore.com
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to
> Selinux-request@tycho.nsa.gov.

[-- Attachment #2: Type: text/html, Size: 3659 bytes --]

RE: Switching to enforcing mode introduces new policy issues?

[Spector, Aaron]

[-- Attachment #1: Type: text/plain, Size: 3853 bytes --]

Thanks for the suggestion Gaurav. I’m currently checking the audits by looking at dmesg and I’ve got the console being pushed out a to a serial console so I can see all the events - that's how I know my permissive boot is supposedly clean. If I hack my policy to not allow something, the first audit I get is of (<time>:3) which to me says it's the first audit after the policy load which is (<time>:2) on my machine.



I haven't modified the SELinux code.



I’ve changed to enforcing by changing the /etc/selinux/config file and by adding enforcing=1 to kernel cmdline in the bootloader. Both ways result in the same effects.

-Aaron

From: Gaurav Gangwar [mailto:gauravgangwaar@gmail.com]
Sent: Thursday, April 23, 2015 11:54 PM
To: Spector, Aaron
Cc: Paul Moore; SELinux (selinux@tycho.nsa.gov)
Subject: Re: Switching to enforcing mode introduces new policy issues?

Hi Aaron,

also check if you have modified the selinux code
also keep track of dmesg. i have noticed that few denials are only shown in dmesg so $dmesg | grep avc is quit important while checking the boot time denials.
one more thing you have to be sure is that u switch between permissive and enforce mode on the same build/bootimage.


Thanks and Regards
Gaurav Gangwar

On 24 April 2015 at 09:42, Spector, Aaron <Aaron_Spector@mcafee.com<mailto:Aaron_Spector@mcafee.com>> wrote:
That sounds like an idea, I'll have to give it a shot. To add a bit more information, I'm seeing a bunch of these changes happen during the boot process in init and I would assume the AVC is cleared between reboots - I've tweaked and added some things there for experimentation. I can boot my system up in permissive and see no problems, but when I restart it in enforcing I start seeing brand new policy violations, things I haven't seen before. It seems odd that the same boot sequence would result in such different behavior.

-Aaron

-----Original Message-----
From: Paul Moore [mailto:paul@paul-moore.com<mailto:paul@paul-moore.com>]
Sent: Thursday, April 23, 2015 5:20 PM
To: Spector, Aaron
Cc: SELinux (selinux@tycho.nsa.gov<mailto:selinux@tycho.nsa.gov>)
Subject: Re: Switching to enforcing mode introduces new policy issues?

On Thu, Apr 23, 2015 at 5:14 PM, Spector, Aaron <Aaron_Spector@mcafee.com<mailto:Aaron_Spector@mcafee.com>> wrote:
> Hi all,
>
> I’ve been working on writing my first policy for SELinux and I’ve hit
> a bit of a snag. I’ve gotten the policy clean in permissive mode, but
> when I swap the system over to enforcing, a whole new set of policy issues crop up.
> Everything I’ve read says this isn’t to be expected so I’m a bit
> confused as to what’s happening.

{snip}

> So far what I’ve had to do to get around it is to add to my policy,
> but that doesn’t seem like that should be necessary. If the audit is
> clean in permissive mode, why isn’t it clean in enforcing?
>
> Is it possible that I’m missing policy deny audits when it’s in
> permissive mode?

It's important to remember that when you are in permissive mode you will only see a given SELinux AVC denial *once*, after that it will not be reported until the AVC is reset.  My two favorite ways of resetting the SELinux AVC are to run either 'load_policy' or toggle the system from permissive into enforcing and then back into permissive mode.  Try that and I suspect that will solve your problem.

-Paul

--
paul moore
www.paul-moore.com<http://www.paul-moore.com>

_______________________________________________
Selinux mailing list
Selinux@tycho.nsa.gov<mailto:Selinux@tycho.nsa.gov>
To unsubscribe, send email to Selinux-leave@tycho.nsa.gov<mailto:Selinux-leave@tycho.nsa.gov>.
To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov<mailto:Selinux-request@tycho.nsa.gov>.


[-- Attachment #2: Type: text/html, Size: 8195 bytes --]

Re: Switching to enforcing mode introduces new policy issues?

[Miroslav Grepl]

On 04/24/2015 06:12 AM, Spector, Aaron wrote:
> That sounds like an idea, I'll have to give it a shot. To add a bit more information, I'm seeing a bunch of these changes happen during the boot process in init and I would assume the AVC is cleared between reboots - I've tweaked and added some things there for experimentation. I can boot my system up in permissive and see no problems, but when I restart it in enforcing I start seeing brand new policy violations, things I haven't seen before. It seems odd that the same boot sequence would result in such different behavior.
> 
> -Aaron
> 
> -----Original Message-----
> From: Paul Moore [mailto:paul@paul-moore.com] 
> Sent: Thursday, April 23, 2015 5:20 PM
> To: Spector, Aaron
> Cc: SELinux (selinux@tycho.nsa.gov)
> Subject: Re: Switching to enforcing mode introduces new policy issues?
> 
> On Thu, Apr 23, 2015 at 5:14 PM, Spector, Aaron <Aaron_Spector@mcafee.com> wrote:
>> Hi all,
>>
>> I’ve been working on writing my first policy for SELinux and I’ve hit 
>> a bit of a snag. I’ve gotten the policy clean in permissive mode, but 
>> when I swap the system over to enforcing, a whole new set of policy issues crop up.
>> Everything I’ve read says this isn’t to be expected so I’m a bit 
>> confused as to what’s happening.
> 

Try to use journalctl/dmesg to search either SELINUX_ERR or AVCs during
boot time.

> {snip}
> 
>> So far what I’ve had to do to get around it is to add to my policy, 
>> but that doesn’t seem like that should be necessary. If the audit is 
>> clean in permissive mode, why isn’t it clean in enforcing?
>>
>> Is it possible that I’m missing policy deny audits when it’s in 
>> permissive mode?
> 
> It's important to remember that when you are in permissive mode you will only see a given SELinux AVC denial *once*, after that it will not be reported until the AVC is reset.  My two favorite ways of resetting the SELinux AVC are to run either 'load_policy' or toggle the system from permissive into enforcing and then back into permissive mode.  Try that and I suspect that will solve your problem.
> 
> -Paul
> 
> --
> paul moore
> www.paul-moore.com
> 
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
> 


-- 
Miroslav Grepl
Software Engineering, SELinux Solutions
Red Hat, Inc.

Re: Switching to enforcing mode introduces new policy issues?

[Stephen Smalley]

On 04/23/2015 05:14 PM, Spector, Aaron wrote:
> Hi all,
> 
>  
> 
> I’ve been working on writing my first policy for SELinux and I’ve hit a
> bit of a snag. I’ve gotten the policy clean in permissive mode, but when
> I swap the system over to enforcing, a whole new set of policy issues
> crop up. Everything I’ve read says this isn’t to be expected so I’m a
> bit confused as to what’s happening. Output from sestatus when in
> permissive mode is:
> 
>  
> 
> SELinux status:                 enabled
> 
> SELinuxfs mount:                /sys/fs/selinux
> 
> SELinux root directory:         /etc/selinux
> 
> Loaded policy name:             default
> 
> Current mode:                   permissive
> 
> Mode from config file:          permissive
> 
> Policy MLS status:              enabled
> 
> Policy deny_unknown status:     denied
> 
> Max kernel policy version:      29
> 
>  
> 
> I’m running a version 26 policy and a 3.16.7 kernel.
> 
>  
> 
> It seems like the majority of the new deny audits are about the need for
> search permissions on directories between types that already have what I
> believe are the necessary file permissions.
> 
>  
> 
> So far what I’ve had to do to get around it is to add to my policy, but
> that doesn’t seem like that should be necessary. If the audit is clean
> in permissive mode, why isn’t it clean in enforcing?
> 
>  
> 
> Is it possible that I’m missing policy deny audits when it’s in
> permissive mode?

The audit system can be overwhelmed by too many denials and therefore
can drop some of the messages under certain conditions; look for
audit_lost= in your dmesg output after booting.  You may be hitting the
audit rate limit, if set, or the backlog limit, if the userspace audit
daemon cannot keep up, or an OOM condition.  I've seen that for e.g.
Android board bringup where you have too many denials during early boot.
You can try adjusting the backlog or rate limits to improve the capture
of denials, but sometimes you may just have to do it iteratively to
ensure full coverage.

Another possibility is that in enforcing mode, the kernel or userspace
may follow a different code path after the point of the denial since the
denial is then being enforced, and that different code path may itself
trigger further permission checks that were not being triggered while
permissive.  I've seen that before as well.

I am a little puzzled though by your comment about the majority of the
new denials being for search permissions on directories between types
that already have the necessary permissions.  Does that mean that you
have already added allow rules for these denials, rebuilt, reinstalled,
and rebooted with that policy, and yet you are still seeing the same
denials?  If so, then a possible explanation is that the denial are due
to something other than a missing allow rule, e.g. they might be due to
a difference in the user identity or level fields of the source and
target security contexts based on constraints in the policy.  audit2why
can tell you why a given denial occurred, but its ability to give you
detailed info will depend on your policy version and how modern a
version of libselinux and policycoreutils you have.

RE: Switching to enforcing mode introduces new policy issues?

[Spector, Aaron]

I noticed the ratelimiting happening a while ago, but if it was happening here, I should get suppression logs correct? I've been checking my avc audits by examining dmesg / viewing that output via a serial console and nothing in there implies that I'm missing logs. When in permissive I can see the policy load audit (<time>:2) and if I break my policy on purpose, the next one is (<time>:3) as expected. When I reboot in enforcing (without the broken policy), I see the policy load (<time>:2) and then I see a new deny on (<time>:3) that doesn't appear in a permissive boot. I'm also not seeing any gaps in the audit sequence numbers.

It may be that you're right about using different code paths in enforcing, it just seems weird that if I didn't deny it in permissive, why would I deny it in enforcing? It seems logical that I'd see new permission checks if a new portion of code was taken.

What I've had to do to make a bit of progress is add new allow rules for the dir class. The only difference between boots is either I add 'enforcing=1' to the kernel boot params in the bootloader or I alter the /etc/config/selinux file to use enforcing mode. An example would be:

# This is all I needed in permissive mode
Allow type_a_t type_b_t : file { read open };
# In enforcing, I now get denies for this
Allow type_a_t type_b_t : dir { search };

I'm surprised that I've never seen denies that relate to that second rule while in permissive mode before. They're not the only new denies I've seen, but they are most frequent. I've been adding to the policy with the rules to allow the denies, rebuilding, reinstalling, rebooting and I get slightly farther each time due to the new rules.

-Aaron 

-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Friday, April 24, 2015 7:25 AM
To: Spector, Aaron; SELinux (selinux@tycho.nsa.gov); Paul Moore
Subject: Re: Switching to enforcing mode introduces new policy issues?

On 04/23/2015 05:14 PM, Spector, Aaron wrote:
> Hi all,
> 
>  
> 
> I've been working on writing my first policy for SELinux and I've hit 
> a bit of a snag. I've gotten the policy clean in permissive mode, but 
> when I swap the system over to enforcing, a whole new set of policy 
> issues crop up. Everything I've read says this isn't to be expected so 
> I'm a bit confused as to what's happening. Output from sestatus when 
> in permissive mode is:
<snip>
> It seems like the majority of the new deny audits are about the need 
> for search permissions on directories between types that already have 
> what I believe are the necessary file permissions.
> 
>  
> 
> So far what I've had to do to get around it is to add to my policy, 
> but that doesn't seem like that should be necessary. If the audit is 
> clean in permissive mode, why isn't it clean in enforcing?
> 
>  
> 
> Is it possible that I'm missing policy deny audits when it's in 
> permissive mode?

The audit system can be overwhelmed by too many denials and therefore can drop some of the messages under certain conditions; look for audit_lost= in your dmesg output after booting.  You may be hitting the audit rate limit, if set, or the backlog limit, if the userspace audit daemon cannot keep up, or an OOM condition.  I've seen that for e.g.
Android board bringup where you have too many denials during early boot.
You can try adjusting the backlog or rate limits to improve the capture of denials, but sometimes you may just have to do it iteratively to ensure full coverage.

Another possibility is that in enforcing mode, the kernel or userspace may follow a different code path after the point of the denial since the denial is then being enforced, and that different code path may itself trigger further permission checks that were not being triggered while permissive.  I've seen that before as well.

I am a little puzzled though by your comment about the majority of the new denials being for search permissions on directories between types that already have the necessary permissions.  Does that mean that you have already added allow rules for these denials, rebuilt, reinstalled, and rebooted with that policy, and yet you are still seeing the same denials?  If so, then a possible explanation is that the denial are due to something other than a missing allow rule, e.g. they might be due to a difference in the user identity or level fields of the source and target security contexts based on constraints in the policy.  audit2why can tell you why a given denial occurred, but its ability to give you detailed info will depend on your policy version and how modern a version of libselinux and policycoreutils you have.

Re: Switching to enforcing mode introduces new policy issues?

[Stephen Smalley]

On 04/24/2015 11:18 AM, Spector, Aaron wrote:
> I noticed the ratelimiting happening a while ago, but if it was happening here, I should get suppression logs correct? I've been checking my avc audits by examining dmesg / viewing that output via a serial console and nothing in there implies that I'm missing logs. When in permissive I can see the policy load audit (<time>:2) and if I break my policy on purpose, the next one is (<time>:3) as expected. When I reboot in enforcing (without the broken policy), I see the policy load (<time>:2) and then I see a new deny on (<time>:3) that doesn't appear in a permissive boot. I'm also not seeing any gaps in the audit sequence numbers.
> 
> It may be that you're right about using different code paths in enforcing, it just seems weird that if I didn't deny it in permissive, why would I deny it in enforcing? It seems logical that I'd see new permission checks if a new portion of code was taken.
> 
> What I've had to do to make a bit of progress is add new allow rules for the dir class. The only difference between boots is either I add 'enforcing=1' to the kernel boot params in the bootloader or I alter the /etc/config/selinux file to use enforcing mode. An example would be:
> 
> # This is all I needed in permissive mode
> Allow type_a_t type_b_t : file { read open };
> # In enforcing, I now get denies for this
> Allow type_a_t type_b_t : dir { search };
> 
> I'm surprised that I've never seen denies that relate to that second rule while in permissive mode before. They're not the only new denies I've seen, but they are most frequent. I've been adding to the policy with the rules to allow the denies, rebuilding, reinstalling, rebooting and I get slightly farther each time due to the new rules.

Yes, you should see audit_lost= messages if you are losing audit records.

In order to open a file, you have to be able to search the parent
directory, so both rules would always be necessary to open a file in a
directory if they both have the same type.  So you should be getting the
directory search denial even in permissive mode.

In addition to hitting the audit backlog or rate limits, you could be
rolling over the kernel ring buffer and thus losing messages that way on
boot.  Could increase its size by log_buf_len= kernel command line
argument; must be a power of two.

RE: Switching to enforcing mode introduces new policy issues?

[Spector, Aaron]

That's what I thought with regards to the file opens. It seemed to work when I lacked the directory search permission, but once it came up and I thought about it, it made sense. I'm just not sure why I didn't see the deny in permissive mode.. All of the rules I have had to add have made sense in the grand scheme of things.

Is it possible to examine the cache for what lookups have happened, similar to how sesearch works? Perhaps my permissive mode is actually denying some operations, but not telling me for some reason.


If I was rolling over the kernel ring buffer, wouldn't I be missing the initial boot events? I've got the entire boot sequence in dmesg.


-Aaron

-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Friday, April 24, 2015 10:27 AM
To: Spector, Aaron; SELinux (selinux@tycho.nsa.gov); Paul Moore (paul@paul-moore.com)
Subject: Re: Switching to enforcing mode introduces new policy issues?

On 04/24/2015 11:18 AM, Spector, Aaron wrote:
> I noticed the ratelimiting happening a while ago, but if it was happening here, I should get suppression logs correct? I've been checking my avc audits by examining dmesg / viewing that output via a serial console and nothing in there implies that I'm missing logs. When in permissive I can see the policy load audit (<time>:2) and if I break my policy on purpose, the next one is (<time>:3) as expected. When I reboot in enforcing (without the broken policy), I see the policy load (<time>:2) and then I see a new deny on (<time>:3) that doesn't appear in a permissive boot. I'm also not seeing any gaps in the audit sequence numbers.
> 
> It may be that you're right about using different code paths in enforcing, it just seems weird that if I didn't deny it in permissive, why would I deny it in enforcing? It seems logical that I'd see new permission checks if a new portion of code was taken.
> 
> What I've had to do to make a bit of progress is add new allow rules for the dir class. The only difference between boots is either I add 'enforcing=1' to the kernel boot params in the bootloader or I alter the /etc/config/selinux file to use enforcing mode. An example would be:
> 
> # This is all I needed in permissive mode Allow type_a_t type_b_t : 
> file { read open }; # In enforcing, I now get denies for this Allow 
> type_a_t type_b_t : dir { search };
> 
> I'm surprised that I've never seen denies that relate to that second rule while in permissive mode before. They're not the only new denies I've seen, but they are most frequent. I've been adding to the policy with the rules to allow the denies, rebuilding, reinstalling, rebooting and I get slightly farther each time due to the new rules.

Yes, you should see audit_lost= messages if you are losing audit records.

In order to open a file, you have to be able to search the parent directory, so both rules would always be necessary to open a file in a directory if they both have the same type.  So you should be getting the directory search denial even in permissive mode.

In addition to hitting the audit backlog or rate limits, you could be rolling over the kernel ring buffer and thus losing messages that way on boot.  Could increase its size by log_buf_len= kernel command line argument; must be a power of two.

Re: Switching to enforcing mode introduces new policy issues?

[Stephen Smalley]

On 04/24/2015 11:57 AM, Spector, Aaron wrote:
> That's what I thought with regards to the file opens. It seemed to work when I lacked the directory search permission, but once it came up and I thought about it, it made sense. I'm just not sure why I didn't see the deny in permissive mode.. All of the rules I have had to add have made sense in the grand scheme of things.
> 
> Is it possible to examine the cache for what lookups have happened, similar to how sesearch works? Perhaps my permissive mode is actually denying some operations, but not telling me for some reason.

No, the only information about the AVC that is made available to
userspace is statistics via /sys/fs/selinux/avc/cache_stats and hash_stats.

I don't think your permissive mode is denying anything.  The more likely
scenario is audit is just losing events IMHO.  Looking again at the
code, even the audit_lost output is wrapped with a printk_ratelimit
check, so it could be suppressed.

> If I was rolling over the kernel ring buffer, wouldn't I be missing the initial boot events? I've got the entire boot sequence in dmesg.

Yes, so it doesn't sound like you are rolling over that buffer.

Sounds like a bug in audit to me...

Re: Switching to enforcing mode introduces new policy issues?

[Stephen Smalley]

On 04/24/2015 12:03 PM, Stephen Smalley wrote:
> On 04/24/2015 11:57 AM, Spector, Aaron wrote:
>> That's what I thought with regards to the file opens. It seemed to work when I lacked the directory search permission, but once it came up and I thought about it, it made sense. I'm just not sure why I didn't see the deny in permissive mode.. All of the rules I have had to add have made sense in the grand scheme of things.
>>
>> Is it possible to examine the cache for what lookups have happened, similar to how sesearch works? Perhaps my permissive mode is actually denying some operations, but not telling me for some reason.
> 
> No, the only information about the AVC that is made available to
> userspace is statistics via /sys/fs/selinux/avc/cache_stats and hash_stats.

cache_stats btw can be more conveniently summarized or monitored via the
avcstat utility from libselinux.

> 
> I don't think your permissive mode is denying anything.  The more likely
> scenario is audit is just losing events IMHO.  Looking again at the
> code, even the audit_lost output is wrapped with a printk_ratelimit
> check, so it could be suppressed.
> 
>> If I was rolling over the kernel ring buffer, wouldn't I be missing the initial boot events? I've got the entire boot sequence in dmesg.
> 
> Yes, so it doesn't sound like you are rolling over that buffer.
> 
> Sounds like a bug in audit to me...
> 

Re: Switching to enforcing mode introduces new policy issues?

[Stephen Smalley]

On 04/24/2015 12:03 PM, Stephen Smalley wrote:
> On 04/24/2015 11:57 AM, Spector, Aaron wrote:
>> That's what I thought with regards to the file opens. It seemed to work when I lacked the directory search permission, but once it came up and I thought about it, it made sense. I'm just not sure why I didn't see the deny in permissive mode.. All of the rules I have had to add have made sense in the grand scheme of things.
>>
>> Is it possible to examine the cache for what lookups have happened, similar to how sesearch works? Perhaps my permissive mode is actually denying some operations, but not telling me for some reason.
> 
> No, the only information about the AVC that is made available to
> userspace is statistics via /sys/fs/selinux/avc/cache_stats and hash_stats.
> 
> I don't think your permissive mode is denying anything.  The more likely
> scenario is audit is just losing events IMHO.  Looking again at the
> code, even the audit_lost output is wrapped with a printk_ratelimit
> check, so it could be suppressed.
> 
>> If I was rolling over the kernel ring buffer, wouldn't I be missing the initial boot events? I've got the entire boot sequence in dmesg.
> 
> Yes, so it doesn't sound like you are rolling over that buffer.
> 
> Sounds like a bug in audit to me...

Just wanted to check - it sounds like you are not running auditd at all?
 Just letting all of the audit messages go to dmesg?

RE: Switching to enforcing mode introduces new policy issues?

[Spector, Aaron]

Correct, I'm not running auditd.

Is it worth removing the printk_ratelimit call in audit_printk_skb() in audit.c for experimentation purposes? Just let it printk all the audits and if it rolls over, oh well?

-Aaron

-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Friday, April 24, 2015 11:12 AM
To: Spector, Aaron; SELinux (selinux@tycho.nsa.gov); Paul Moore (paul@paul-moore.com)
Subject: Re: Switching to enforcing mode introduces new policy issues?

On 04/24/2015 12:03 PM, Stephen Smalley wrote:
> On 04/24/2015 11:57 AM, Spector, Aaron wrote:
>> That's what I thought with regards to the file opens. It seemed to work when I lacked the directory search permission, but once it came up and I thought about it, it made sense. I'm just not sure why I didn't see the deny in permissive mode.. All of the rules I have had to add have made sense in the grand scheme of things.
>>
>> Is it possible to examine the cache for what lookups have happened, similar to how sesearch works? Perhaps my permissive mode is actually denying some operations, but not telling me for some reason.
> 
> No, the only information about the AVC that is made available to 
> userspace is statistics via /sys/fs/selinux/avc/cache_stats and hash_stats.
> 
> I don't think your permissive mode is denying anything.  The more 
> likely scenario is audit is just losing events IMHO.  Looking again at 
> the code, even the audit_lost output is wrapped with a 
> printk_ratelimit check, so it could be suppressed.
> 
>> If I was rolling over the kernel ring buffer, wouldn't I be missing the initial boot events? I've got the entire boot sequence in dmesg.
> 
> Yes, so it doesn't sound like you are rolling over that buffer.
> 
> Sounds like a bug in audit to me...

Just wanted to check - it sounds like you are not running auditd at all?
 Just letting all of the audit messages go to dmesg?

Re: Switching to enforcing mode introduces new policy issues?

[Stephen Smalley]

On 04/24/2015 12:30 PM, Spector, Aaron wrote:
> Correct, I'm not running auditd.
> 
> Is it worth removing the printk_ratelimit call in audit_printk_skb() in audit.c for experimentation purposes? Just let it printk all the audits and if it rolls over, oh well?

Sure.

Re: Switching to enforcing mode introduces new policy issues?

[Stephen Smalley]

On 04/24/2015 12:33 PM, Stephen Smalley wrote:
> On 04/24/2015 12:30 PM, Spector, Aaron wrote:
>> Correct, I'm not running auditd.
>>
>> Is it worth removing the printk_ratelimit call in audit_printk_skb() in audit.c for experimentation purposes? Just let it printk all the audits and if it rolls over, oh well?
> 
> Sure.

We actually do that in our kernel trees for Android policy development, e.g.
https://bitbucket.org/seandroid/kernel-msm/commits/0388e1630648c481e42929135babb1dbba272e27

RE: Switching to enforcing mode introduces new policy issues?

[Spector, Aaron]

So I gave it a shot and nothing changed. I did however notice some oddity with my serial console though. I get some udevd failures in enforcing and I see the Permission Denied messages there, but I see no audit associated with them on the console. I'm able to get into my system to check dmesg and lo and behold there are audits in dmesg for that udev service that couldn't start.

-Aaron

-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Friday, April 24, 2015 11:36 AM
To: Spector, Aaron; SELinux (selinux@tycho.nsa.gov); Paul Moore (paul@paul-moore.com)
Subject: Re: Switching to enforcing mode introduces new policy issues?

On 04/24/2015 12:33 PM, Stephen Smalley wrote:
> On 04/24/2015 12:30 PM, Spector, Aaron wrote:
>> Correct, I'm not running auditd.
>>
>> Is it worth removing the printk_ratelimit call in audit_printk_skb() in audit.c for experimentation purposes? Just let it printk all the audits and if it rolls over, oh well?
> 
> Sure.

We actually do that in our kernel trees for Android policy development, e.g.
https://bitbucket.org/seandroid/kernel-msm/commits/0388e1630648c481e42929135babb1dbba272e27