RE: Switching to enforcing mode introduces new policy issues?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxx] 
Sent: Friday, April 24, 2015 11:12 AM
To: Spector, Aaron; SELinux (selinux@xxxxxxxxxxxxx); Paul Moore (paul@xxxxxxxxxxxxxx)
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?



_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.




[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux