checking user status

checking user status

[Larry Ross]

[-- Attachment #1: Type: text/plain, Size: 1777 bytes --]

Using the RHEL5.3 strict policy I am trying to allow a custom selinux user
permission to use the passwd and chage commands to get the status of a local
user.

With selinux in permissive it works as expected, with selinux in enforcing,
all I get are cryptic error messages.  I installed the enableaudit.pp base
policy module, still no denials.

Does anyone know what permissions I need to add or what I could be doing
wrong?  Is this even possible?

  Thank you,
  Larry

[secadm@newhost ~]$ sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          permissive
Policy version:                 21
Policy from config file:        strict

[secadm@newhost ~]$ sudo chage -l user
chage: Permission denied.
[secadm@newhost ~]$ sudo /usr/bin/passwd -S user
Only root can do that.

[secadm@newhost ~]$ sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          permissive
Policy version:                 21
Policy from config file:        strict

[secadm@newhost ~]$ sudo chage -l user
Last password change                                    : May 14, 2009
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

[secadm@newhost ~]$ sudo /usr/bin/passwd -S user
user PS 2009-05-13 0 99999 7 -1 (Password set, unknown crypt variant.)
[secadm@newhost ~]$

[-- Attachment #2: Type: text/html, Size: 2029 bytes --]

Re: checking user status

[Stephen Smalley]

On Sun, 2009-08-16 at 11:53 -0700, Larry Ross wrote:
> Using the RHEL5.3 strict policy I am trying to allow a custom selinux
> user permission to use the passwd and chage commands to get the status
> of a local user.
>  
> With selinux in permissive it works as expected, with selinux in
> enforcing, all I get are cryptic error messages.  I installed the
> enableaudit.pp base policy module, still no denials.
>  
> Does anyone know what permissions I need to add or what I could
> be doing wrong?  Is this even possible?

Did you allow the :passwd permission to the custom selinux user's
domain?

allow <userdomain> self:passwd { passwd };

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: checking user status

[Christopher J. PeBenito]

On Mon, 2009-08-17 at 08:29 -0400, Stephen Smalley wrote:
> On Sun, 2009-08-16 at 11:53 -0700, Larry Ross wrote:
> > Using the RHEL5.3 strict policy I am trying to allow a custom selinux
> > user permission to use the passwd and chage commands to get the status
> > of a local user.
> >  
> > With selinux in permissive it works as expected, with selinux in
> > enforcing, all I get are cryptic error messages.  I installed the
> > enableaudit.pp base policy module, still no denials.
> >  
> > Does anyone know what permissions I need to add or what I could
> > be doing wrong?  Is this even possible?
> 
> Did you allow the :passwd permission to the custom selinux user's
> domain?
> 
> allow <userdomain> self:passwd { passwd };

Perhaps a denial message should be emitted from
selinux_check_passwd_access() so people know when this perm check is
denied.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


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

Re: checking user status

[Stephen Smalley]

On Mon, 2009-08-17 at 08:42 -0400, Christopher J. PeBenito wrote:
> On Mon, 2009-08-17 at 08:29 -0400, Stephen Smalley wrote:
> > On Sun, 2009-08-16 at 11:53 -0700, Larry Ross wrote:
> > > Using the RHEL5.3 strict policy I am trying to allow a custom selinux
> > > user permission to use the passwd and chage commands to get the status
> > > of a local user.
> > >  
> > > With selinux in permissive it works as expected, with selinux in
> > > enforcing, all I get are cryptic error messages.  I installed the
> > > enableaudit.pp base policy module, still no denials.
> > >  
> > > Does anyone know what permissions I need to add or what I could
> > > be doing wrong?  Is this even possible?
> > 
> > Did you allow the :passwd permission to the custom selinux user's
> > domain?
> > 
> > allow <userdomain> self:passwd { passwd };
> 
> Perhaps a denial message should be emitted from
> selinux_check_passwd_access() so people know when this perm check is
> denied.

Ideally we'd convert the callers of this function and all direct callers
of security_compute_av() to using the userspace AVC.  The userspace AVC
just didn't exist when passwd and friends (and crond) were originally
instrumented for SELinux.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: checking user status

[Daniel J Walsh]

On 08/17/2009 08:42 AM, Christopher J. PeBenito wrote:
> On Mon, 2009-08-17 at 08:29 -0400, Stephen Smalley wrote:
>> On Sun, 2009-08-16 at 11:53 -0700, Larry Ross wrote:
>>> Using the RHEL5.3 strict policy I am trying to allow a custom selinux
>>> user permission to use the passwd and chage commands to get the status
>>> of a local user.
>>>  
>>> With selinux in permissive it works as expected, with selinux in
>>> enforcing, all I get are cryptic error messages.  I installed the
>>> enableaudit.pp base policy module, still no denials.
>>>  
>>> Does anyone know what permissions I need to add or what I could
>>> be doing wrong?  Is this even possible?
>>
>> Did you allow the :passwd permission to the custom selinux user's
>> domain?
>>
>> allow <userdomain> self:passwd { passwd };
> 
> Perhaps a denial message should be emitted from
> selinux_check_passwd_access() so people know when this perm check is
> denied.
> 
Please open a bugzilla on the passwd command.

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

Re: checking user status

[Larry Ross]

[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]

On Mon, Aug 17, 2009 at 7:47 AM, Larry Ross <selinux.larry@gmail.com> wrote:

>  On Mon, Aug 17, 2009 at 5:29 AM, Stephen Smalley <sds@tycho.nsa.gov>wrote:
>
>> On Sun, 2009-08-16 at 11:53 -0700, Larry Ross wrote:
>> > Using the RHEL5.3 strict policy I am trying to allow a custom selinux
>> > user permission to use the passwd and chage commands to get the status
>> > of a local user.
>> >
>> > With selinux in permissive it works as expected, with selinux in
>> > enforcing, all I get are cryptic error messages.  I installed the
>> > enableaudit.pp base policy module, still no denials.
>> >
>> > Does anyone know what permissions I need to add or what I could
>> > be doing wrong?  Is this even possible?
>>
>
>  Stephen,
> Thank you for your response.
>
>
>
>> Did you allow the :passwd permission to the custom selinux user's
>> domain?
>
>
>> allow <userdomain> self:passwd { passwd };
>
>
>  I would have if I had know about it, is this documented somewhere?.
>
> That worked for "passwd -S", is there something similar to allow a user to
> use the chage command?
>

Stephen,
  Sorry for the off list reply.  I think I found it: "rootok".  It works,
but I'm not sure what it means.  Could you explain what the rootok
permission means?  Is it intended for this use?

  Thank you,
  Larry



>
>    Thank you,
>    Larry
>
>
>
>>
>>
>> --
>> Stephen Smalley
>> National Security Agency
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 2927 bytes --]

Re: checking user status

[Daniel J Walsh]

On 08/17/2009 10:54 AM, Larry Ross wrote:
> On Mon, Aug 17, 2009 at 7:47 AM, Larry Ross <selinux.larry@gmail.com> wrote:
> 
>>  On Mon, Aug 17, 2009 at 5:29 AM, Stephen Smalley <sds@tycho.nsa.gov>wrote:
>>
>>> On Sun, 2009-08-16 at 11:53 -0700, Larry Ross wrote:
>>>> Using the RHEL5.3 strict policy I am trying to allow a custom selinux
>>>> user permission to use the passwd and chage commands to get the status
>>>> of a local user.
>>>>
>>>> With selinux in permissive it works as expected, with selinux in
>>>> enforcing, all I get are cryptic error messages.  I installed the
>>>> enableaudit.pp base policy module, still no denials.
>>>>
>>>> Does anyone know what permissions I need to add or what I could
>>>> be doing wrong?  Is this even possible?
>>>
>>
>>  Stephen,
>> Thank you for your response.
>>
>>
>>
>>> Did you allow the :passwd permission to the custom selinux user's
>>> domain?
>>
>>
>>> allow <userdomain> self:passwd { passwd };
>>
>>
>>  I would have if I had know about it, is this documented somewhere?.
>>
>> That worked for "passwd -S", is there something similar to allow a user to
>> use the chage command?
>>
> 
> Stephen,
>   Sorry for the off list reply.  I think I found it: "rootok".  It works,
> but I'm not sure what it means.  Could you explain what the rootok
> permission means?  Is it intended for this use?
> 
>   Thank you,
>   Larry
> 
> 
> 
>>
>>    Thank you,
>>    Larry
>>
>>
>>
>>>
>>>
>>> --
>>> Stephen Smalley
>>> National Security Agency
>>>
>>>
>>
> 
rootok is a check within the password command to see if the administrator who is running the password command override password accounts other then its own.

The idea is to stop applications that are running as root, from changing password data without providing the old password.
If the type does not have rootok, the password utility will ask for a password before changing any password data.

This prevents a confined administrator from becoming root and changing the root other other passwords.

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

Re: checking user status

[Larry Ross]

[-- Attachment #1: Type: text/plain, Size: 1782 bytes --]

On Mon, Aug 17, 2009 at 7:57 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:

>  On Mon, 2009-08-17 at 07:47 -0700, Larry Ross wrote:
> > On Mon, Aug 17, 2009 at 5:29 AM, Stephen Smalley <sds@tycho.nsa.gov>
> > wrote:
> >         On Sun, 2009-08-16 at 11:53 -0700, Larry Ross wrote:
> >         > Using the RHEL5.3 strict policy I am trying to allow a
> >         custom selinux
> >         > user permission to use the passwd and chage commands to get
> >         the status
> >         > of a local user.
> >         >
> >         > With selinux in permissive it works as expected, with
> >         selinux in
> >         > enforcing, all I get are cryptic error messages.  I
> >         installed the
> >         > enableaudit.pp base policy module, still no denials.
> >         >
> >         > Does anyone know what permissions I need to add or what I
> >         could
> >         > be doing wrong?  Is this even possible?
> >
> > Stephen,
> > Thank you for your response.
> >
> >
> >         Did you allow the :passwd permission to the custom selinux
> >         user's
> >         domain?
> >
> >         allow <userdomain> self:passwd { passwd };
> >
> > I would have if I had know about it, is this documented somewhere?.
> >
> > That worked for "passwd -S", is there something similar to allow a
> > user to use the chage command?
>
> Looks like that is using rootok, although it ought to use a permission
> of its own rather than overlapping with pam_rootok.
>
> So:
>        allow <userdomain> self:passwd { passwd rootok };
>
> These programs ought to be converted to using the userspace AVC so that
> they emit proper avc messages on denials.


I will agree with that.  Thank you for your help.

  -- Larry


>
>
> --
>  Stephen Smalley
> National Security Agency
>
>

[-- Attachment #2: Type: text/html, Size: 2617 bytes --]

Re: checking user status

[Larry Ross]

[-- Attachment #1: Type: text/plain, Size: 2607 bytes --]

On Mon, Aug 17, 2009 at 7:55 AM, Larry Ross <selinux.larry@gmail.com> wrote:

>   On Mon, Aug 17, 2009 at 7:57 AM, Stephen Smalley <sds@tycho.nsa.gov>wrote:
>
>>  On Mon, 2009-08-17 at 07:47 -0700, Larry Ross wrote:
>> > On Mon, Aug 17, 2009 at 5:29 AM, Stephen Smalley <sds@tycho.nsa.gov>
>> > wrote:
>> >         On Sun, 2009-08-16 at 11:53 -0700, Larry Ross wrote:
>> >         > Using the RHEL5.3 strict policy I am trying to allow a
>> >         custom selinux
>> >         > user permission to use the passwd and chage commands to get
>> >         the status
>> >         > of a local user.
>> >         >
>> >         > With selinux in permissive it works as expected, with
>> >         selinux in
>> >         > enforcing, all I get are cryptic error messages.  I
>> >         installed the
>> >         > enableaudit.pp base policy module, still no denials.
>> >         >
>> >         > Does anyone know what permissions I need to add or what I
>> >         could
>> >         > be doing wrong?  Is this even possible?
>> >
>> > Stephen,
>> > Thank you for your response.
>> >
>> >
>> >         Did you allow the :passwd permission to the custom selinux
>> >         user's
>> >         domain?
>> >
>> >         allow <userdomain> self:passwd { passwd };
>> >
>> > I would have if I had know about it, is this documented somewhere?.
>> >
>> > That worked for "passwd -S", is there something similar to allow a
>> > user to use the chage command?
>>
>> Looks like that is using rootok, although it ought to use a permission
>> of its own rather than overlapping with pam_rootok.
>>
>> So:
>>        allow <userdomain> self:passwd { passwd rootok };
>
>
Similar issue.  I have created a new user and used chage to expire their
password so they are required to create a new one on their first login.

Logging in to the Gnome Greeter, with SELinux permissive, there is no issue,
with SELinux enforcing (still the strict policy, a custom user), I get a
message that says "The change of the authentication token failed.  Please
try again later or contact the system administrator."

No SELinux denials.

Two questions:
1. Anyone know what permission or permissions are required so this works and
which domain or domains need it?
2. Anyone have any direction on how I can answer these questions for myself?

  Thank you,
  Larry





>
>>
>> These programs ought to be converted to using the userspace AVC so that
>> they emit proper avc messages on denials.
>
>
> I will agree with that.  Thank you for your help.
>
>   -- Larry
>
>
>>
>>
>> --
>>   Stephen Smalley
>> National Security Agency
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 4267 bytes --]

Re: checking user status

[Stephen Smalley]

On Mon, 2009-08-17 at 13:38 -0700, Larry Ross wrote:
> On Mon, Aug 17, 2009 at 7:55 AM, Larry Ross <selinux.larry@gmail.com>
> wrote:
>         
>         On Mon, Aug 17, 2009 at 7:57 AM, Stephen Smalley
>         <sds@tycho.nsa.gov> wrote:
>                 
>                 On Mon, 2009-08-17 at 07:47 -0700, Larry Ross wrote:
>                 > On Mon, Aug 17, 2009 at 5:29 AM, Stephen Smalley
>                 <sds@tycho.nsa.gov>
>                 > wrote:
>                 >         On Sun, 2009-08-16 at 11:53 -0700, Larry
>                 Ross wrote:
>                 >         > Using the RHEL5.3 strict policy I am
>                 trying to allow a
>                 >         custom selinux
>                 >         > user permission to use the passwd and
>                 chage commands to get
>                 >         the status
>                 >         > of a local user.
>                 >         >
>                 >         > With selinux in permissive it works as
>                 expected, with
>                 >         selinux in
>                 >         > enforcing, all I get are cryptic error
>                 messages.  I
>                 >         installed the
>                 >         > enableaudit.pp base policy module, still
>                 no denials.
>                 >         >
>                 >         > Does anyone know what permissions I need
>                 to add or what I
>                 >         could
>                 >         > be doing wrong?  Is this even possible?
>                 >
>                 > Stephen,
>                 > Thank you for your response.
>                 >
>                 >
>                 >         Did you allow the :passwd permission to the
>                 custom selinux
>                 >         user's
>                 >         domain?
>                 >
>                 >         allow <userdomain> self:passwd { passwd };
>                 >
>                 > I would have if I had know about it, is this
>                 documented somewhere?.
>                 >
>                 > That worked for "passwd -S", is there something
>                 similar to allow a
>                 > user to use the chage command?
>                 
>                 
>                 Looks like that is using rootok, although it ought to
>                 use a permission
>                 of its own rather than overlapping with pam_rootok.
>                 
>                 So:
>                        allow <userdomain> self:passwd { passwd
>                 rootok };
>  
> Similar issue.  I have created a new user and used chage to expire
> their password so they are required to create a new one on their first
> login.   
>  
> Logging in to the Gnome Greeter, with SELinux permissive, there is no
> issue, with SELinux enforcing (still the strict policy, a custom
> user), I get a message that says "The change of the authentication
> token failed.  Please try again later or contact the system
> administrator."
>  
> No SELinux denials.
>  
> Two questions:
> 1. Anyone know what permission or permissions are required so this
> works and which domain or domains need it?
> 2. Anyone have any direction on how I can answer these questions for
> myself?

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.

Dan - we should really convert those programs over to using the avc so
that we'll get AVC denials.  Look to xselinux.c in Xorg as the canonical
modern example.  Not sure if dbusd or nscd have really been updated to
the latest interfaces.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: checking user status

[Stephen Smalley]

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);
 	}
 

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: checking user status

[Larry Ross]

[-- Attachment #1: Type: text/plain, Size: 1746 bytes --]

On Tue, Aug 18, 2009 at 5:39 AM, Stephen Smalley <sds@tycho.nsa.gov> 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
>
>

[-- Attachment #2: Type: text/html, Size: 2472 bytes --]

Re: checking user status

[Daniel J Walsh]

On 08/18/2009 01:15 PM, Larry Ross wrote:
> On Tue, Aug 18, 2009 at 5:39 AM, Stephen Smalley <sds@tycho.nsa.gov> 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.

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

Re: checking user status

[Larry]

[-- Attachment #1: Type: text/plain, Size: 2682 bytes --]

On Tue, Aug 18, 2009 at 11:10 AM, Daniel J Walsh <dwalsh@redhat.com> wrote:

>  On 08/18/2009 01:15 PM, Larry Ross wrote:
> > On Tue, Aug 18, 2009 at 5:39 AM, Stephen Smalley <sds@tycho.nsa.gov>
> 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.


In the meantime, do you have any suggestions on how I can determine what the
problem is?

   Thank you,
   Larry




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

[-- Attachment #2: Type: text/html, Size: 3861 bytes --]

Re: checking user status

[Stephen Smalley]

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@tycho.nsa.gov> 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?

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: checking user status

[Steve Grubb]

On Wednesday 19 August 2009 10:34:21 am Stephen Smalley wrote:
> 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).

Right. Also libaudit has the functions in place to correctly handle encoding 
if they are needed.

> I think the bug would be against shadow-utils.  Did anyone already open
> it?

It would be against password.

-Steve

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

Re: checking user status

[Stephen Smalley]

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@tycho.nsa.gov> 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.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: checking user status

[Stephen Smalley]

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@tycho.nsa.gov> 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: checking user status

[Larry]

[-- Attachment #1: Type: text/plain, Size: 2517 bytes --]

On Tue, Aug 18, 2009 at 10:15 AM, Larry Ross <selinux.larry@gmail.com>wrote:

>   On Tue, Aug 18, 2009 at 5:39 AM, Stephen Smalley <sds@tycho.nsa.gov>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);
>
>
Looks like this should have been:
                        syslog(LOG_ERR,
                              "avc:  denied { %s } for scontext=%s "
                              "tcontext=%s tclass=passwd\n",
                              security_av_perm_to_string(SECCLASS_PASSWD,
                                               requested),
                              user_context, user_context);


Where should the reference to "security_av_perm_to_string'" come from?

checkAccess.lo: In function `selinux_check_passwd_access':
checkAccess.c:(.text+0x9d): undefined reference to
`security_av_perm_to_string'

  -- Larry


>
>>                }
>> +
>>                freecon(user_context);
>>         }
>>
>
> Where does the passwd_class come from?
>
>   -- Larry
>
>
>
>
>>
>>
>>
>> --
>> Stephen Smalley
>> National Security Agency
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 4019 bytes --]

Re: checking user status

[Stephen Smalley]

On Tue, 2009-08-18 at 12:10 -0700, Larry wrote:
> On Tue, Aug 18, 2009 at 10:15 AM, Larry Ross <selinux.larry@gmail.com>
> wrote:
>         
>         On Tue, Aug 18, 2009 at 5:39 AM, Stephen Smalley
>         <sds@tycho.nsa.gov> 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);
>  
> Looks like this should have been:
>                         syslog(LOG_ERR,
>                               "avc:  denied { %s } for scontext=%s "
>                               "tcontext=%s tclass=passwd\n",
> 
> security_av_perm_to_string(SECCLASS_PASSWD,
>                                                requested),
>                               user_context, user_context);
>  
>  
> Where should the reference to "security_av_perm_to_string'" come from?
>  
> checkAccess.lo: In function `selinux_check_passwd_access':
> checkAccess.c:(.text+0x9d): undefined reference to
> `security_av_perm_to_string'

My patch was relative to the latest version of libselinux from
http://userspace.selinuxproject.org.  The one shipped in RHEL5 is
obviously much older and may lack that function.  The older function
would have been print_access_vector() and/or avc_dump_av(), but you'd
have to adjust them to syslog() the output.  Or you could patch, build,
and install the latest libselinux from userspace.selinuxproject.org.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.