Summary: SELinux is preventing /usr/bin/kdm "execute" access on /sbin/grub. Detailed Description: [SELinux is in permissive mode. This access was not denied.] SELinux denied access requested by kdm. It is not expected that this access is required by kdm and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Please file a bug report. Additional Information: Source Context system_u:system_r:xdm_t:s0-s0:c0.c1023 Target Context system_u:object_r:bootloader_exec_t:s0 Target Objects /sbin/grub [ file ] Source kdm Source Path 2F7573722F62696E2F6B646D202864656C6574656429 Port <Unknown> Host (removed) Source RPM Packages kdm-4.3.2-1.fc12 Target RPM Packages grub-0.97-60.fc12 Policy RPM selinux-policy-3.6.32-41.fc12 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Plugin Name catchall Host Name (removed) Platform Linux (removed) 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 2009 x86_64 x86_64 Alert Count 54 First Seen Wed 15 Jul 2009 08:01:12 PM CEST Last Seen Wed 18 Nov 2009 09:54:59 PM CET Local ID cadc2259-9b64-4c6d-b434-c3e15a444504 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1258577699.648:102): avc: denied { execute } for pid=2327 comm="kdm" name="grub" dev=dm-1 ino=2860 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:bootloader_exec_t:s0 tclass=file node=(removed) type=SYSCALL msg=audit(1258577699.648:102): arch=c000003e syscall=21 success=yes exit=0 a0=7fffaba30fa6 a1=1 a2=0 a3=7fffaba2fd30 items=0 ppid=1 pid=2327 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="kdm" exe="/usr/bin/kdm" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) Hash String generated from selinux-policy-3.6.32-41.fc12,catchall,kdm,xdm_t,bootloader_exec_t,file,execute audit2allow suggests: #============= xdm_t ============== allow xdm_t bootloader_exec_t:file execute;
This is not allowed by SELinux since allowing the login program to modify the boot config is considered too dangerous from a security point of view. If you want to allow it you can add policy using audit2allow.
*** Bug 540214 has been marked as a duplicate of this bug. ***
*** Bug 540215 has been marked as a duplicate of this bug. ***
*** Bug 558554 has been marked as a duplicate of this bug. ***
*** Bug 564137 has been marked as a duplicate of this bug. ***
*** Bug 589358 has been marked as a duplicate of this bug. ***
Daniel: could you explain further? My take on it is: 1) KDM is already trusted to accept all usernames and passwords and initialize the GUI. There isn't much to gain here. (I'm open to thoughts on what I could be missing) 2) Dualbooting is made easier when you can have KDM tell grub which OS to boot into. That way when you're getting coffee during reboot, you don't accidentally miss the 5 second window where you get to choose your OS.
The idea is people screwing around with a box without a user name and password. kdm/xdm/gdm execute tons of code, especially when you consider "Assistive Technologies". If any of these has a bug, an hacker might have the ability to modify key parts of the system without having a username and password. Allowing the login utility to manipulate the /etc/group entry might allow you to override requiring a password at boot, or allow machine to boot in single user mode. You can change grub to wait for input if you have a problem with the timeout. Or you can modify the SELinux policy to allow this system to work., I might even accept a patch with a boolean. But I am not going to modify the policy for everyone to allow this functionality by default
*** Bug 606070 has been marked as a duplicate of this bug. ***
*** Bug 620113 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > The idea is people screwing around with a box without a user name and password. Then shouldn't the function to tell the system to reboot at the display manager be configured to require authentication? By default KDM is configured to require authentication if you're connecting remotely. If your on the console (i.e., have physical access to the box), then all bets would be off, anyway, so the default config doesn't require authentication to restart or shutdown from the console. I also don't agree that it's the purview of SELinux to restrict this kind of access. This is a legitimate function of many display managers. This restriction doesn't prevent someone from rebooting the system (or powering it off), it merely prevents it from being more convenient when rebooting to specify which GRUB line to boot, at the time the user makes the decision to reboot the system. Does SELinux prevent me from pressing <CTRL>+<ALT>+<F2> or <CTRL>+<ALT>+<DELETE>? No, of course not. If someone's environment needs to be locked down tight enough to prevent a user on the console from being able to reboot/shutdown the system, they'll have to deal with that in their display manager configuration. I humbly suggest that the policy should be altered to allow this functionality.
I answered this via Email, But SELinux is not about trusting applications. Saying you trust the application to require authentication to reboot means nothing the the SELinux system. The question is can I get the kdm process to do evil access do to a bug in kdm? If SELinux can prevent that and still allow kdm to do its primary function, then we are a bit more secure. We now have policy for shutdown, if kdm execs shutdown when it is rebooting, we can probably add code/boolean to allow gdm_t to transition to shutdown_t, without giving gdm_t all the privs required to shut a system down.
Would this work: 1) Write a trivial program that accepts user's credentials and configures the next startup's boot order. 2) When KDM wants to set the boot order, it ask for credentials, then executes the program from (1)
Sure, then I can write policy that confines that application to be able to modify /etc/grub.conf. I just don't understand why this is that important. Allowing login programs to manage /etc/grub seems a good attack root, for turning off SELinux or disabling other security features, booting single user turning off password on the bootloader, all from an app that users can touch without providing authorization.
It's not about changing the boot order when you're at the login screen, but I imagine that must be affected too. For me it's when I click the K menu, choose "Leave" then "Restart". With SELinux disabled, you can choose which Grub entry to reboot into. This is handy when I know that I want to boot into Windows, but only for this one reboot and not normally. With SELinux enabled, it doesn't show me a list of options and all I can do is reboot. KDM trying to get the list of OS choices from Grub is what triggers this alert. There are two subsequent alerts that you'll hit if enforcing is disabled and you choose which OS to boot into. Note: This integration is disabled in Fedora by default. To hit this condition, in systemsettings, choose "Login Screen" then the "Shutdown" tab, then set the boot manager to Grub. If I understand correctly, the reboot dialog could be modified to not show the OS options until the user says that they want to select one, then ask for root's credentials, show the list, then tell grub which OS to boot one time only.
I have to allow xdm_t to manage boot_t in order to allow what you want to work, which allows the login program to change grub.conf. xdm_t is the label of kdm and all programs it executes, boot_t is the label of all files under /boot/grub. Saying the app has to prompt for the user password or root password, means nothing to SELinux. Could you attempt to do what you want in permissive mode and attach all of the AVC messages. I can add a boolean to allow this, which will be turned off by default.
I think I understand what you mean by "means nothing to SELinux". My comment was assuming that I would modify KDM to use the helper app mentioned in my comment 13. The audit messages are: (already reported above) SELinux is preventing /usr/bin/kdm "execute" access on /sbin/grub. node=(removed) type=AVC msg=audit(1287774961.302:68): avc: denied { execute } for pid=4498 comm="kdm" name="grub" dev=sda6 ino=55870 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:bootloader_exec_t:s0 tclass=file node=(removed) type=SYSCALL msg=audit(1287774961.302:68): arch=c000003e syscall=21 success=yes exit=0 a0=7fffb2cce6d6 a1=1 a2=0 a3=34906812a0 items=0 ppid=1 pid=4498 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="kdm" exe="/usr/bin/kdm" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) Then: SELinux is preventing /usr/bin/kdm "read" access on /boot/grub/menu.lst. node=(removed) type=AVC msg=audit(1287774961.303:69): avc: denied { read } for pid=4498 comm="kdm" name="menu.lst" dev=sda5 ino=65032 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:boot_t:s0 tclass=lnk_file node=(removed) type=AVC msg=audit(1287774961.303:69): avc: denied { read } for pid=4498 comm="kdm" name="grub.conf" dev=sda5 ino=65031 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:boot_t:s0 tclass=file node=(removed) type=AVC msg=audit(1287774961.303:69): avc: denied { open } for pid=4498 comm="kdm" name="grub.conf" dev=sda5 ino=65031 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:boot_t:s0 tclass=file node=(removed) type=SYSCALL msg=audit(1287774961.303:69): arch=c000003e syscall=2 success=yes exit=13 a0=41f66a a1=0 a2=1b6 a3=0 items=0 ppid=1 pid=4498 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="kdm" exe="/usr/bin/kdm" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) Finally: SELinux is preventing /usr/bin/kdm "getattr" access on /boot/grub/grub.conf. node=reflexionsmart type=AVC msg=audit(1287774961.303:70): avc: denied { getattr } for pid=4498 comm="kdm" path="/boot/grub/grub.conf" dev=sda5 ino=65031 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:boot_t:s0 tclass=file node=reflexionsmart type=SYSCALL msg=audit(1287774961.303:70): arch=c000003e syscall=5 success=yes exit=0 a0=d a1=7fffb2cce5a0 a2=7fffb2cce5a0 a3=7fffb2cce490 items=0 ppid=1 pid=4498 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="kdm" exe="/usr/bin/kdm" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
Should the status of this bug still be CLOSED WONTFIX?
No Miroslav can you write a boolean xdm_exec_bootloader and add these rules, for F12-F15.
Fixed in selinux-policy-3.6.32-126.fc12.noarch
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
selinux-policy-3.6.32-127.fc12 has been submitted as an update for Fedora 12. https://admin.fedoraproject.org/updates/selinux-policy-3.6.32-127.fc12
selinux-policy-3.6.32-127.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update selinux-policy'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/selinux-policy-3.6.32-127.fc12
Is this available in F14 as well? I don't see a xdm_exec_bootloader boolean in system-config-selinux.
selinux-policy-3.6.32-127.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.