|
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@xxxxxxxxx]
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@xxxxxxxxxx> 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. |
_______________________________________________ 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.
