Bug 518268 - passwd does not generate an avc audit record on denials
Summary: passwd does not generate an avc audit record on denials
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: passwd
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-19 17:09 UTC by Stephen Smalley
Modified: 2012-01-27 13:43 UTC (History)
4 users (show)

Fixed In Version: passwd-0.78.99-1.fc17
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-27 13:43:42 UTC


Attachments (Terms of Use)
This patch implements the new API and properly reports a user_avc within the audit.log (4.20 KB, patch)
2011-10-19 13:51 UTC, Daniel Walsh
no flags Details | Diff
This patch might be a little closer to what Stephen wants. (4.20 KB, patch)
2011-10-19 14:14 UTC, Daniel Walsh
no flags Details | Diff
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. (4.86 KB, patch)
2011-10-21 15:34 UTC, Daniel Walsh
no flags Details | Diff

Description Stephen Smalley 2009-08-19 17:09:31 UTC
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

Comment 1 Bug Zapper 2009-11-16 11:33:13 UTC
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

Comment 2 Tomas Mraz 2009-12-22 08:53:38 UTC
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.

Comment 3 Bug Zapper 2010-03-15 12:46:45 UTC
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

Comment 4 Bug Zapper 2011-06-02 17:49:15 UTC
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

Comment 5 Bug Zapper 2011-06-27 14:21:08 UTC
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.

Comment 6 Daniel Walsh 2011-10-18 13:41:42 UTC
Reopening since new customers just hit this problem when running passwd.

Comment 7 Tomas Mraz 2011-10-18 13:51:17 UTC
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.

Comment 8 Daniel Walsh 2011-10-18 14:26:00 UTC
I am looking to write a patch for this, not sure if we should put the code in libselinux though.

Comment 9 Tomas Mraz 2011-10-18 14:36:12 UTC
Note that there are multiple userspace utilities that would benefit from such call - notably crond and pam_selinux.

Comment 10 Daniel Walsh 2011-10-18 15:17:11 UTC
Yes the problem is the flexibility of the audit code.

And I am not sure we want to tie together libselinux and libaudit.

Comment 11 Tomas Mraz 2011-10-19 07:00:12 UTC
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.

Comment 12 Stephen Smalley 2011-10-19 13:40:07 UTC
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.

Comment 13 Daniel Walsh 2011-10-19 13:51:53 UTC
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.

Comment 14 Daniel Walsh 2011-10-19 14:14:56 UTC
Created attachment 529013 [details]
This patch might be a little closer to what Stephen wants.

Comment 15 Stephen Smalley 2011-10-19 14:19:14 UTC
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.

Comment 16 Stephen Smalley 2011-10-19 14:25:50 UTC
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.

Comment 17 Daniel Walsh 2011-10-19 14:57:50 UTC
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.

Comment 18 Stephen Smalley 2011-10-19 15:06:48 UTC
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.

Comment 19 Daniel Walsh 2011-10-21 15:34:40 UTC
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

Comment 20 Daniel Walsh 2011-10-21 15:35:11 UTC
Will back port fixes for F16 in libselinux, once F16 ships...

Comment 21 Tomas Mraz 2011-10-24 11:17:03 UTC
Great, I'm just waiting for final upstream acceptance of the selinux_check_access() call.

Comment 22 Tomas Mraz 2012-01-26 17:04:13 UTC
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

Comment 23 Daniel Walsh 2012-01-26 22:59:09 UTC
Fixed in selinux-policy-3.10.0-80.fc17


Note You need to log in before you can comment on or make changes to this bug.