Re: checking user status

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2009-08-19 at 10:39 -0400, Stephen Smalley wrote:
> On Wed, 2009-08-19 at 10:34 -0400, Stephen Smalley wrote:
> > On Tue, 2009-08-18 at 14:10 -0400, Daniel J Walsh wrote:
> > > On 08/18/2009 01:15 PM, Larry Ross wrote:
> > > > On Tue, Aug 18, 2009 at 5:39 AM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
> > > > 
> > > >> On Tue, 2009-08-18 at 08:19 -0400, Stephen Smalley wrote:
> > > >>> If this is another manifestation of the same problem, then the easiest
> > > >>> approach would be to grab the libselinux .src.rpm, patch
> > > >>> libselinux/src/checkAccess.c to syslog() a message whenever there is a
> > > >>> denial, build and install your patched libselinux, and then retry and
> > > >>> look for the log message.
> > > >>
> > > >> Something like this patch (un-tested, against the current upstream
> > > >> libselinux):
> > > >>
> > > >> diff --git a/libselinux/src/checkAccess.c b/libselinux/src/checkAccess.c
> > > >> index c1982c7..cae1626 100644
> > > >> --- a/libselinux/src/checkAccess.c
> > > >> +++ b/libselinux/src/checkAccess.c
> > > >> @@ -2,6 +2,7 @@
> > > >>  #include <sys/types.h>
> > > >>  #include <stdlib.h>
> > > >>  #include <errno.h>
> > > >> +#include <syslog.h>
> > > >>  #include "selinux_internal.h"
> > > >>  #include <selinux/flask.h>
> > > >>  #include <selinux/av_permissions.h>
> > > >> @@ -29,7 +30,15 @@ int selinux_check_passwd_access(access_vector_t
> > > >> requested)
> > > >>
> > > >>                if ((retval == 0) && ((requested & avd.allowed) ==
> > > >> requested)) {
> > > >>                        status = 0;
> > > >> +               } else {
> > > >> +                       syslog(LOG_ERR,
> > > >> +                              "avc:  denied { %s } for scontext=%s "
> > > >> +                              "tcontext=%s tclass=passwd\n",
> > > >> +                              security_av_perm_to_string(passwd_class,
> > > >> +                                                         requested),
> > > >> +                              user_context, user_context);
> > > >>                }
> > > >> +
> > > >>                freecon(user_context);
> > > >>         }
> > > >>
> > > > 
> > > > Where does the passwd_class come from?
> > > > 
> > > >   -- Larry
> > > > 
> > > > 
> > > > 
> > > > 
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Stephen Smalley
> > > >> National Security Agency
> > > >>
> > > >>
> > > > 
> > > 
> > > This is not the responsibility of the library to log this fact, it is the responsibility of the tool (passwd) to log 
> > > any denials.  I am surprised that we do not audit this event.  Since I think a MAC denial on changing a security sensitive object should probably be audited.
> > 
> > But only the library function has all the necessary information to
> > generate an audit or log record that can be processed by e.g.
> > audit2allow (the source and target contexts, class, and permission).
> > 
> > I do agree that the callers should be modified to use the userspace AVC;
> > then they would pick up the normal avc auditing support (but would need
> > to set up the proper callback to invoke the audit interfaces, just like
> > dbusd does).
> > 
> > I think the bug would be against shadow-utils.  Did anyone already open
> > it?
> 
> Actually, it appears to affect:
> pam (for pam_rootok)
> shadow-utils (for chage)
> passwd (for passwd)
> util-linux-ng (for chsh, chfn)
> cronie (for crontab)
> 
> And maybe others.

https://bugzilla.redhat.com/show_bug.cgi?id=518268

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux