+++ This bug was initially created as a clone of Bug #540213 +++


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;

--- Additional comment from dwalsh on 2009-11-23 10:56:45 EST ---

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.

--- Additional comment from dwalsh on 2009-11-23 10:56:55 EST ---

*** Bug 540214 has been marked as a duplicate of this bug. ***

--- Additional comment from dwalsh on 2009-11-23 10:57:06 EST ---

*** Bug 540215 has been marked as a duplicate of this bug. ***

--- Additional comment from mgrepl on 2010-01-25 12:05:31 EST ---

*** Bug 558554 has been marked as a duplicate of this bug. ***

--- Additional comment from mgrepl on 2010-02-12 03:38:24 EST ---

*** Bug 564137 has been marked as a duplicate of this bug. ***

--- Additional comment from mgrepl on 2010-05-06 03:40:15 EDT ---

*** Bug 589358 has been marked as a duplicate of this bug. ***

--- Additional comment from greg.martyn on 2010-06-08 16:42:22 EDT ---

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.

--- Additional comment from dwalsh on 2010-06-09 07:18:00 EDT ---

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

--- Additional comment from mgrepl on 2010-06-21 08:19:40 EDT ---

*** Bug 606070 has been marked as a duplicate of this bug. ***

--- Additional comment from mgrepl on 2010-08-02 12:01:29 EDT ---

*** Bug 620113 has been marked as a duplicate of this bug. ***

--- Additional comment from peregrine on 2010-10-19 19:31:11 EDT ---

(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.

--- Additional comment from dwalsh on 2010-10-20 08:53:28 EDT ---

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.

--- Additional comment from greg.martyn on 2010-10-20 17:17:10 EDT ---

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)

--- Additional comment from dwalsh on 2010-10-22 09:11:24 EDT ---

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.

--- Additional comment from greg.martyn on 2010-10-22 14:23:24 EDT ---

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.

--- Additional comment from dwalsh on 2010-10-22 14:50:57 EDT ---

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.

--- Additional comment from greg.martyn on 2010-10-22 15:37:07 EDT ---

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)

--- Additional comment from greg.martyn on 2010-10-22 17:19:21 EDT ---

Should the status of this bug still be CLOSED WONTFIX?

--- Additional comment from dwalsh on 2010-10-25 12:48:38 EDT ---

No Miroslav can you write a boolean xdm_exec_bootloader and add these rules, for F12-F15.

--- Additional comment from mgrepl on 2010-11-03 08:18:55 EDT ---

Fixed in selinux-policy-3.6.32-126.fc12.noarch

--- Additional comment from fedora-triage-list on 2010-11-04 01:42:31 EDT ---


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

--- Additional comment from fedora-admin-xmlrpc on 2010-11-08 16:47:58 EST ---

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

--- Additional comment from updates on 2010-11-16 08:15:52 EST ---

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

--- Additional comment from updates on 2010-11-16 18:13:36 EST ---

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

--- Additional comment from greg.martyn on 2010-11-17 21:38:42 EST ---

Is this available in F14 as well? I don't see a xdm_exec_bootloader boolean in system-config-selinux.