Description of problem: passwd directly calls security_compute_av() rather than using the userspace AVC and therefore does not generate an avc denial that can be used to inform the user of the cause of the denial or to generate policy via tools such as audit2allow. It appears that an older version of passwd would log an error message that at least indicated that SELinux was the cause and showed the context, but that this was removed in the latest version. Regardless, converting it to use the AVC would be preferable. A similar issue exists for chage (shadow-utils), pam_rootok (pam), crontab and crond (cronie), and chsh and chfn (util-linux-ng) (and perhaps others that I don't recall). The original modifications of these programs for SELinux predated the creation of the userspace AVC. This was raised as an issue by a RHEL5.3 user in this thread: http://marc.info/?t=125044914800002&r=1&w=2 Version-Release number of selected component (if applicable): any How reproducible: Always Steps to Reproduce: 1. Try to run passwd <username> from a confined domain. 2. Run /sbin/ausearch -m USER_AVC -ts recent. Actual results: No audit messages. Expected results: A USER_AVC audit message with the denial. Additional info: dbusd, nscd, and Xorg (xselinux) all provide examples of using the userspace AVC. xselinux shows the usage of the latest interfaces, e.g. avc_open(), selinux_set_callback(), selinux_set_mapping(). See: http://cgit.freedesktop.org/xorg/xserver/tree/Xext/xselinux.c
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I think there should be some more easy-to-use interface in libselinux for this purpose for this kind of utilities which do not need any caching or similar things as they are not long-running daemons.
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. 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 '13'. 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 13'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 13 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
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Reopening since new customers just hit this problem when running passwd.
Dan, is there some simple example code how to write a single AVC check that does this? Unfortunately the dbus, nscd, and Xorg are pretty complicated ones as they check more than one AVC and so they cache various handles for performance, etc.
I am looking to write a patch for this, not sure if we should put the code in libselinux though.
Note that there are multiple userspace utilities that would benefit from such call - notably crond and pam_selinux.
Yes the problem is the flexibility of the audit code. And I am not sure we want to tie together libselinux and libaudit.
It still would be possible to make the selinux code a simple call and then call audit library from the application with data returned from the libselinux call.
I would be supportive of a simpler libselinux API for this purpose. Ideally as easy to use as the existing selinux_check_passwd_access() but it should: a) only passes strings for classes/permissions, to be internally mapped to values by libselinux, b) internally uses the AVC rather than calling security_compute_av(). We could use __selinux_once() within the function to perform the avc_open() call on the first use of the interface. We might still need the app to first call selinux_set_callback() to set up the SELINUX_CB_LOG callback. Ordinarily I'd ask Eamon to whip something up, but unfortunately he is no longer here.
Created attachment 529008 [details] This patch implements the new API and properly reports a user_avc within the audit.log It does not implement everything Stephen would want, mainly it still uses the hard coded values. But Tomas I think it is a simpler code then what XSelinux.c currently has.
Created attachment 529013 [details] This patch might be a little closer to what Stephen wants.
Note that passwd presently checks permissions in two different ways in two different places - once with its own helper, and once by calling libselinux checkPasswdAccess aka selinux_check_passwd_access (the latter is the preferred name for namespace cleanliness; we wanted to obsolete the former). Ideally you'd take the core logic for both into a libselinux function similar to checkPasswdAccess / selinux_check_passwd_access but that uses the AVC internally. I'm not sure I understand the check_selinux_access() logic in passwd anymore. We aren't typically using the Linux username as the SELinux user identity anymore, so why are we comparing the user from the security context with the username? Don't we just want to apply the SELinux check whenever a username was specified, just as they apply a root check in that case? Then we could just call checkPasswdAccess() in both cases, right next to the existing getuid() != 0 checks.
By the way, we shouldn't have to check selinux_enforcing() separately if we are using the AVC, as that gets checked internally and also handles permissive domains, not just global permissive mode.
Doesn't selinux_check_passwd_access have to call avc_has_perm (user_id, user_id, + SECCLASS_PASSWD, + access, NULL, NULL) < 0) To make this work? I recoded with the default selinux_check_passwd_access, and now the log_callback is not being called.
Yes, you'd need to rewrite selinux_check_passwd_access() to use the AVC internally. And technically what we'd really like is a simpler interface that takes two contexts, a string class name and a string permission name, and then internally calls: avc_context_to_sid() on each context, string_to_security_class() on the class, string_to_av_perm() on the class and permission, avc_has_perm() on those values. And possibly even call avc_open() on entry via __selinux_once() so that the caller doesn't have to do that. Then the caller only needs to call selinux_set_callback() and then start using the new interface. I think.
Created attachment 529526 [details] This patch will just check if passwd is running as root, if yes it will check if the previous context is allowed to execute the passwd command. This patch requires a newer version of libselinux, that is currently in rawhide. Spec file needs this change. -BuildRequires: libselinux-devel +Requires: libselinux >= 2.1.6-3 +BuildRequires: libselinux-devel >= 2.1.6-3
Will back port fixes for F16 in libselinux, once F16 ships...
Great, I'm just waiting for final upstream acceptance of the selinux_check_access() call.
I see this AVC with the patch on Fedora 16: time->Thu Jan 26 18:00:11 2012 type=SYSCALL msg=audit(1327597211.724:2462): arch=c000003e syscall=41 success=no exit=-13 a0=10 a1=3 a2=7 a3=7fff0cddd500 items=0 ppid=12704 pid=12824 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts17 ses=3 comm="passwd" exe="/usr/bin/passwd" subj=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1327597211.724:2462): avc: denied { create } for pid=12824 comm="passwd" scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tclass=netlink_selinux_socket
Fixed in selinux-policy-3.10.0-80.fc17