sudo + selinux

sudo + selinux

[James Cammarata]

Hi, we're looking towards running SELinux on RHEL5 in strict mode here,
however I'm not having any luck finding resources on configuring sudo to
work with SELinux properly.  Are there any guides/resources to getting this
working?  I've found some older mailing list threads that discuss adding
some new features to sudo to make it selinux-aware, but that doesn't seem
to have found it's way into RHEL5 yet (at least, as of 5.4).

Thanks,

James Cammarata

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--
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: sudo + selinux

[James Cammarata]

On Tue, 13 Apr 2010 17:41:53 -0400, Chad Sellers <csellers@tresys.com>
wrote:
> On 4/12/10 3:30 PM, "James Cammarata" <jimi@sngx.net> wrote:
> 
>> 
>> Hi, we're looking towards running SELinux on RHEL5 in strict mode here,
>> however I'm not having any luck finding resources on configuring sudo to
>> work with SELinux properly.  Are there any guides/resources to getting
>> this
>> working?  I've found some older mailing list threads that discuss adding
>> some new features to sudo to make it selinux-aware, but that doesn't
seem
>> to have found it's way into RHEL5 yet (at least, as of 5.4).
>> 
> Hi James,
> 
> What do you want sudo to do with respect to SELinux? Are you looking for
it
> to transition to a more trusted domain when it is run?
> 
> Most of the time, we let sudo remain a DAC privilege escalation
mechanism,
> but do not use it to escalate SELinux priveleges. We do generally
> transition
> into a derived domain for sudo (see sudo_role_template in reference
policy
> for more info), so you could easily grant that derived domain additional
> privileges if that's what you're looking to do, but that's just policy
and
> requires no SELinux knowledge in sudo.
> 
> Thanks,
> Chad


I basically just want to allow non-privileged users the ability to run sudo
commands to administer the system without needing to know how to execute
newrole or anything like that.  In running strict, when users log in, the
context is user_u:user_r:user_t.  Sudo (on RHEL5 anyway) is running things
as user_u:user_r:user_sudo_t:s0.  For instance, here's the AVC generated by
trying to run "sudo tail /var/log/audit/audit.log":

type=AVC msg=audit(1271195194.912:157): avc:  denied  { getattr } for 
pid=4240 comm="tail" path="/var/log/audit/audit.log" dev=dm-1 ino=98326
scontext=user_u:user_r:user_sudo_t:s0
tcontext=system_u:object_r:auditd_log_t:s0 tclass=file
type=SYSCALL msg=audit(1271195194.912:157): arch=c000003e syscall=5
success=yes exit=0 a0=3 a1=7fff54158d70 a2=7fff54158d70 a3=0 items=0
ppid=2393 pid=4240 auid=129320 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=pts0 ses=2 comm="tail" exe="/usr/bin/tail"
subj=user_u:user_r:user_sudo_t:s0 key=(null)

Running audit2allow says I should add these rules:

#============= user_sudo_t ==============
allow user_sudo_t auditd_log_t:dir search;
allow user_sudo_t auditd_log_t:file { read getattr };


It seems like RHEL has made it more difficult than it needs to be.  I
really don't want to have to add policy changes for every sudo command I
want non-privileged users to run.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--
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: sudo + selinux

[James Cammarata]

On Wed, 14 Apr 2010 08:35:56 -0400, Daniel J Walsh <dwalsh@redhat.com>
wrote:
> sudo in RHEL6 and F11 and beyond added newrole type functionality to
> sudo.  This package will not be back ported to RHEL5.  (Sorry).
> One option would be to add newrole to a shell script executed by sudo.
> 
> sudo audit.sh
> 
> cat audit.sh
> newrole -r auditadm_r -t auditadm_t COMMAND
> 
> Then add pam_rootok to /etc/pam.d/newrole

That's a bit of a bummer.  I had seen your discussions with the sudo devs
that was about a year or more old, so I was hoping this had found its way
into RHEL already.  I'll test this workaround today and see if it does what
I want.

Thanks!

James C.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--
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: sudo + selinux

[James Cammarata]

On Wed, 14 Apr 2010 10:30:27 -0400, Daniel J Walsh <dwalsh@redhat.com>
> We are very careful of what we backport and sudo has not come up on the
> priority list.  With Shipping versions of RHEL we are hesitant to make
> major modifications that could cause a regression.

Understood, I'm just surprised that running SElinux in strict mode breaks
sudo isn't more of a priority.  Are that few people using strict mode?

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--
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: sudo + selinux

[Chad Sellers]

On 4/12/10 3:30 PM, "James Cammarata" <jimi@sngx.net> wrote:

> 
> Hi, we're looking towards running SELinux on RHEL5 in strict mode here,
> however I'm not having any luck finding resources on configuring sudo to
> work with SELinux properly.  Are there any guides/resources to getting this
> working?  I've found some older mailing list threads that discuss adding
> some new features to sudo to make it selinux-aware, but that doesn't seem
> to have found it's way into RHEL5 yet (at least, as of 5.4).
> 
Hi James,

What do you want sudo to do with respect to SELinux? Are you looking for it
to transition to a more trusted domain when it is run?

Most of the time, we let sudo remain a DAC privilege escalation mechanism,
but do not use it to escalate SELinux priveleges. We do generally transition
into a derived domain for sudo (see sudo_role_template in reference policy
for more info), so you could easily grant that derived domain additional
privileges if that's what you're looking to do, but that's just policy and
requires no SELinux knowledge in sudo.

Thanks,
Chad


--
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: sudo + selinux

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/12/2010 03:56 PM, James Cammarata wrote:
> 
> On Tue, 13 Apr 2010 17:41:53 -0400, Chad Sellers <csellers@tresys.com>
> wrote:
>> On 4/12/10 3:30 PM, "James Cammarata" <jimi@sngx.net> wrote:
>>
>>>
>>> Hi, we're looking towards running SELinux on RHEL5 in strict mode here,
>>> however I'm not having any luck finding resources on configuring sudo to
>>> work with SELinux properly.  Are there any guides/resources to getting
>>> this
>>> working?  I've found some older mailing list threads that discuss adding
>>> some new features to sudo to make it selinux-aware, but that doesn't
> seem
>>> to have found it's way into RHEL5 yet (at least, as of 5.4).
>>>
>> Hi James,
>>
>> What do you want sudo to do with respect to SELinux? Are you looking for
> it
>> to transition to a more trusted domain when it is run?
>>
>> Most of the time, we let sudo remain a DAC privilege escalation
> mechanism,
>> but do not use it to escalate SELinux priveleges. We do generally
>> transition
>> into a derived domain for sudo (see sudo_role_template in reference
> policy
>> for more info), so you could easily grant that derived domain additional
>> privileges if that's what you're looking to do, but that's just policy
> and
>> requires no SELinux knowledge in sudo.
>>
>> Thanks,
>> Chad
> 
> 
> I basically just want to allow non-privileged users the ability to run sudo
> commands to administer the system without needing to know how to execute
> newrole or anything like that.  In running strict, when users log in, the
> context is user_u:user_r:user_t.  Sudo (on RHEL5 anyway) is running things
> as user_u:user_r:user_sudo_t:s0.  For instance, here's the AVC generated by
> trying to run "sudo tail /var/log/audit/audit.log":
> 
> type=AVC msg=audit(1271195194.912:157): avc:  denied  { getattr } for 
> pid=4240 comm="tail" path="/var/log/audit/audit.log" dev=dm-1 ino=98326
> scontext=user_u:user_r:user_sudo_t:s0
> tcontext=system_u:object_r:auditd_log_t:s0 tclass=file
> type=SYSCALL msg=audit(1271195194.912:157): arch=c000003e syscall=5
> success=yes exit=0 a0=3 a1=7fff54158d70 a2=7fff54158d70 a3=0 items=0
> ppid=2393 pid=4240 auid=129320 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> sgid=0 fsgid=0 tty=pts0 ses=2 comm="tail" exe="/usr/bin/tail"
> subj=user_u:user_r:user_sudo_t:s0 key=(null)
> 
> Running audit2allow says I should add these rules:
> 
> #============= user_sudo_t ==============
> allow user_sudo_t auditd_log_t:dir search;
> allow user_sudo_t auditd_log_t:file { read getattr };
> 
> 
> It seems like RHEL has made it more difficult than it needs to be.  I
> really don't want to have to add policy changes for every sudo command I
> want non-privileged users to run.
> 
sudo in RHEL6 and F11 and beyond added newrole type functionality to
sudo.  This package will not be back ported to RHEL5.  (Sorry).
One option would be to add newrole to a shell script executed by sudo.

sudo audit.sh

cat audit.sh
newrole -r auditadm_r -t auditadm_t COMMAND

Then add pam_rootok to /etc/pam.d/newrole


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkvFtqwACgkQrlYvE4MpobPwTACfVZGp+dTFOF/b1E82xG522pom
oH8AoOHUrIh4qXuGgb/PZGdcWK9o6Wyy
=UfIW
-----END PGP SIGNATURE-----

--
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: sudo + selinux

[James Cammarata]

So, I was playing with this yesterday and couldn't get it to work quite
right.  I created a shell script (/usr/bin/audit.sh), which contains the
following:

[root@kvm001 ~]# cat /usr/bin/audit.sh
newrole -r sysadm_r -t sysadm_t -- $*

And sudoers has this:

test ALL=(ALL) NOPASSWD: /usr/bin/audit.sh

[root@kvm001 ~]# cat /etc/pam.d/newrole
#%PAM-1.0
auth       sufficient   pam_rootok.so
auth       include      system-auth
account    include      system-auth
password   include      system-auth
session    required     pam_namespace.so unmnt_remnt no_unmount_on_close

[root@kvm001 ~]# semanage login -l

Login Name                SELinux User              MLS/MCS Range

__default__               user_u                    s0
root                      root                      SystemLow-SystemHigh
system_u                  system_u                  SystemLow-SystemHigh
test                      staff_u                   s0

Added some policy to allow staff_t to run audit.sh via sudo:

[root@kvm001 ~]# cat staffsudo.te
module staffsudo 0.0.1;

require {
        type bin_t;
        type staff_t;
        type staff_sudo_t;
        class file { execute execute_no_trans };
        class capability { dac_read_search dac_override };
}

#============= staff_sudo_t ==============
allow staff_sudo_t bin_t:file { execute execute_no_trans };

#============= staff_t ==============
allow staff_t self:capability { dac_read_search dac_override };



But, when I try to run the command as the "test" user via sudo, here's all
I get:

[test@kvm001 ~]$ sudo /usr/bin/audit.sh less /var/log/messages
Password:
/usr/bin/less: /usr/bin/less: cannot execute binary file


And here is the audit.log output from that:

type=CRED_ACQ msg=audit(1271345951.906:1159790): user pid=9218 uid=0
auid=502 subj=staff_u:staff_r:staff_sudo_t:s0 msg='PAM: setcred acct="root"
: exe="/usr/bin/sudo" (hostname=kvm001.sandbox.pri, addr=1.1.1.100,
terminal=/dev/pts/1 res=success)'
type=USER_START msg=audit(1271345951.920:1159791): user pid=9218 uid=0
auid=502 subj=staff_u:staff_r:staff_sudo_t:s0 msg='PAM: session open
acct="root" : exe="/usr/bin/sudo" (hostname=kvm001.sandbox.pri,
addr=1.1.1.100, terminal=/dev/pts/1 res=success)'
type=USER_END msg=audit(1271345951.927:1159792): user pid=9218 uid=0
auid=502 subj=staff_u:staff_r:staff_sudo_t:s0 msg='PAM: session close
acct="root" : exe="/usr/bin/sudo" (hostname=kvm001.sandbox.pri,
addr=1.1.1.100, terminal=/dev/pts/1 res=success)'
type=USER_CMD msg=audit(1271345951.930:1159793): user pid=9218 uid=0
auid=502 subj=staff_u:staff_r:staff_sudo_t:s0 msg='cwd="/home/test"
cmd=2F7573722F62696E2F61756469742E7368206C657373202F7661722F6C6F672F6D65737361676573
(terminal=pts/1 res=success)'
type=USER_AUTH msg=audit(1271345954.273:1159794): user pid=9219 uid=0
auid=502 subj=staff_u:staff_r:newrole_t:s0 msg='PAM: authentication
acct="test" : exe="/usr/bin/newrole" (hostname=?, addr=?, terminal=pts/1
res=success)'
type=USER_ACCT msg=audit(1271345954.296:1159795): user pid=9219 uid=0
auid=502 subj=staff_u:staff_r:newrole_t:s0 msg='PAM: accounting acct="test"
: exe="/usr/bin/newrole" (hostname=?, addr=?, terminal=pts/1 res=success)'
type=USER_START msg=audit(1271345954.304:1159796): user pid=9223 uid=0
auid=502 subj=staff_u:staff_r:newrole_t:s0 msg='PAM: session open
acct="test" : exe="/usr/bin/newrole" (hostname=?, addr=?, terminal=pts/1
res=success)'
type=USER_ROLE_CHANGE msg=audit(1271345954.304:1159797): user pid=9223
uid=0 auid=502 subj=staff_u:staff_r:newrole_t:s0 msg='newrole:
old-context=staff_u:staff_r:staff_t new-context=staff_u:sysadm_r:sysadm_t:
exe="/usr/bin/newrole" (hostname=?, addr=?, terminal=/dev/pts/1
res=success)'
type=USER_END msg=audit(1271345954.489:1159798): user pid=9219 uid=0
auid=502 subj=staff_u:staff_r:newrole_t:s0 msg='PAM: session close
acct="test" : exe="/usr/bin/newrole" (hostname=?, addr=?, terminal=pts/1
res=success)'


No AVCs... weird.  Also, I thought the point of having the pam_rootok.so in
/etc/pam.d/newrole was so that the user wouldn't need to enter their
password when newrole was run?



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--
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: sudo + selinux

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/13/2010 07:00 AM, James Cammarata wrote:
> 
> On Wed, 14 Apr 2010 08:35:56 -0400, Daniel J Walsh <dwalsh@redhat.com>
> wrote:
>> sudo in RHEL6 and F11 and beyond added newrole type functionality to
>> sudo.  This package will not be back ported to RHEL5.  (Sorry).
>> One option would be to add newrole to a shell script executed by sudo.
>>
>> sudo audit.sh
>>
>> cat audit.sh
>> newrole -r auditadm_r -t auditadm_t COMMAND
>>
>> Then add pam_rootok to /etc/pam.d/newrole
> 
> That's a bit of a bummer.  I had seen your discussions with the sudo devs
> that was about a year or more old, so I was hoping this had found its way
> into RHEL already.  I'll test this workaround today and see if it does what
> I want.
> 
> Thanks!
> 
> James C.
> 
We are very careful of what we backport and sudo has not come up on the
priority list.  With Shipping versions of RHEL we are hesitant to make
major modifications that could cause a regression.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkvF0YMACgkQrlYvE4MpobPGzgCfQ3u1wyKbY1WPe+fRag26LJOJ
P+cAoJn25VdzqcmshsjbF8u/cSGkQkli
=4jz7
-----END PGP SIGNATURE-----

--
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: sudo + selinux

[Larry Ross]

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

On Tue, Apr 13, 2010 at 6:53 AM, James Cammarata <jimi@sngx.net> wrote:

>
> On Wed, 14 Apr 2010 10:30:27 -0400, Daniel J Walsh <dwalsh@redhat.com>
> > We are very careful of what we backport and sudo has not come up on the
> > priority list.  With Shipping versions of RHEL we are hesitant to make
> > major modifications that could cause a regression.
>
> Understood, I'm just surprised that running SElinux in strict mode breaks
> sudo isn't more of a priority.  Are that few people using strict mode?
>


I am using SELinux with RHEL5 and the strict policy.  I am using the per
role sudo domains, and have custom policy to make it all work, but my system
if fairly tightly constrained.

  -- Larry



>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
> --
>  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: 1717 bytes --]

Re: sudo + selinux

[James Cammarata]

>> 
> Does this work in permissive mode?

Actually, no, it doesn't, but I think I found the problem.  I was assuming
all I needed at the end of newrole was --, but the man page says to use "--
-c", which does seem to be working now.  Turning enforcing back on:

[test@kvm001 ~]$ sudo /usr/bin/audit.sh echo "hi there"
Password:
hi there

So, that seems to be good, but it's still asking for the password for the
selinux user.  Is pam_rootok not doing what it's supposed to?

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--
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: sudo + selinux

[Michal Svoboda]

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

James Cammarata wrote:
> Understood, I'm just surprised that running SElinux in strict mode
> breaks sudo isn't more of a priority.  Are that few people using
> strict mode?

RHEL 5 selinux manual specifically says that strict mode is YMMV, ie.
not officially supported.

By the way, debian lenny has the same problems with sudo. Recompiling
the package from source with selinux support on did not help since the
policy to do its deeds was also missing. Maybe on RHEL5 you'd encounter
the same problem.

I simply instructed my co-admins to execute 'newrole' and 'sudo -i' in
order to gain administrative privileges (root + sysadm_r) from their
staff_r shell.


Michal Svoboda


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: sudo + selinux

[James Cammarata]

On Wed, 14 Apr 2010 11:16:56 -0500, James Cammarata <jimi@sngx.net> wrote:
>>> 
>> Does this work in permissive mode?
> 
> Actually, no, it doesn't, but I think I found the problem.  I was
assuming
> all I needed at the end of newrole was --, but the man page says to use
"--
> -c", which does seem to be working now.  Turning enforcing back on:
> 
> [test@kvm001 ~]$ sudo /usr/bin/audit.sh echo "hi there"
> Password:
> hi there
> 
> So, that seems to be good, but it's still asking for the password for the
> selinux user.  Is pam_rootok not doing what it's supposed to?

Something else weird... I added a shebang line to the top of the audit.sh
script, and now when I run it I don't get prompted for a password, but it
fails with this message:

[test@kvm001 ~]$ sudo /usr/bin/audit.sh echo hi
Could not determine enforcing mode.

Once again, there are no AVC's in the audit.log.  I did have to add this to
my custom policy though:

allow staff_sudo_t newrole_exec_t:file { execute execute_no_trans };


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--
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: sudo + selinux

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/13/2010 09:53 AM, James Cammarata wrote:
> 
> On Wed, 14 Apr 2010 10:30:27 -0400, Daniel J Walsh <dwalsh@redhat.com>
>> We are very careful of what we backport and sudo has not come up on the
>> priority list.  With Shipping versions of RHEL we are hesitant to make
>> major modifications that could cause a regression.
> 
> Understood, I'm just surprised that running SElinux in strict mode breaks
> sudo isn't more of a priority.  Are that few people using strict mode?
> 
Well it depends on your definition of broken.  The way SELinux was
originally designed was to use newrole to change your role and sudo to
change your UID.  Only in RHEL6 is sudo able to do both.  Strict policy
is not used that much.  Although MLS policy is based on Strict policy,
but those people are a lot more used to the concept.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkvF8iYACgkQrlYvE4MpobP1QACfdcivA4idxYIBcOFyyo/4pwZt
AwoAn36fyQa6gZTKxymSvQM2Xhnv1fgN
=tFRi
-----END PGP SIGNATURE-----

--
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: sudo + selinux

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/14/2010 09:46 AM, James Cammarata wrote:
> 
> So, I was playing with this yesterday and couldn't get it to work quite
> right.  I created a shell script (/usr/bin/audit.sh), which contains the
> following:
> 
> [root@kvm001 ~]# cat /usr/bin/audit.sh
> newrole -r sysadm_r -t sysadm_t -- $*
> 
> And sudoers has this:
> 
> test ALL=(ALL) NOPASSWD: /usr/bin/audit.sh
> 
> [root@kvm001 ~]# cat /etc/pam.d/newrole
> #%PAM-1.0
> auth       sufficient   pam_rootok.so
> auth       include      system-auth
> account    include      system-auth
> password   include      system-auth
> session    required     pam_namespace.so unmnt_remnt no_unmount_on_close
> 
> [root@kvm001 ~]# semanage login -l
> 
> Login Name                SELinux User              MLS/MCS Range
> 
> __default__               user_u                    s0
> root                      root                      SystemLow-SystemHigh
> system_u                  system_u                  SystemLow-SystemHigh
> test                      staff_u                   s0
> 
> Added some policy to allow staff_t to run audit.sh via sudo:
> 
> [root@kvm001 ~]# cat staffsudo.te
> module staffsudo 0.0.1;
> 
> require {
>         type bin_t;
>         type staff_t;
>         type staff_sudo_t;
>         class file { execute execute_no_trans };
>         class capability { dac_read_search dac_override };
> }
> 
> #============= staff_sudo_t ==============
> allow staff_sudo_t bin_t:file { execute execute_no_trans };
> 
> #============= staff_t ==============
> allow staff_t self:capability { dac_read_search dac_override };
> 
> 
> 
> But, when I try to run the command as the "test" user via sudo, here's all
> I get:
> 
> [test@kvm001 ~]$ sudo /usr/bin/audit.sh less /var/log/messages
> Password:
> /usr/bin/less: /usr/bin/less: cannot execute binary file
> 
> 
Does this work in permissive mode?
> And here is the audit.log output from that:
> 
> type=CRED_ACQ msg=audit(1271345951.906:1159790): user pid=9218 uid=0
> auid=502 subj=staff_u:staff_r:staff_sudo_t:s0 msg='PAM: setcred acct="root"
> : exe="/usr/bin/sudo" (hostname=kvm001.sandbox.pri, addr=1.1.1.100,
> terminal=/dev/pts/1 res=success)'
> type=USER_START msg=audit(1271345951.920:1159791): user pid=9218 uid=0
> auid=502 subj=staff_u:staff_r:staff_sudo_t:s0 msg='PAM: session open
> acct="root" : exe="/usr/bin/sudo" (hostname=kvm001.sandbox.pri,
> addr=1.1.1.100, terminal=/dev/pts/1 res=success)'
> type=USER_END msg=audit(1271345951.927:1159792): user pid=9218 uid=0
> auid=502 subj=staff_u:staff_r:staff_sudo_t:s0 msg='PAM: session close
> acct="root" : exe="/usr/bin/sudo" (hostname=kvm001.sandbox.pri,
> addr=1.1.1.100, terminal=/dev/pts/1 res=success)'
> type=USER_CMD msg=audit(1271345951.930:1159793): user pid=9218 uid=0
> auid=502 subj=staff_u:staff_r:staff_sudo_t:s0 msg='cwd="/home/test"
> cmd=2F7573722F62696E2F61756469742E7368206C657373202F7661722F6C6F672F6D65737361676573
> (terminal=pts/1 res=success)'
> type=USER_AUTH msg=audit(1271345954.273:1159794): user pid=9219 uid=0
> auid=502 subj=staff_u:staff_r:newrole_t:s0 msg='PAM: authentication
> acct="test" : exe="/usr/bin/newrole" (hostname=?, addr=?, terminal=pts/1
> res=success)'
> type=USER_ACCT msg=audit(1271345954.296:1159795): user pid=9219 uid=0
> auid=502 subj=staff_u:staff_r:newrole_t:s0 msg='PAM: accounting acct="test"
> : exe="/usr/bin/newrole" (hostname=?, addr=?, terminal=pts/1 res=success)'
> type=USER_START msg=audit(1271345954.304:1159796): user pid=9223 uid=0
> auid=502 subj=staff_u:staff_r:newrole_t:s0 msg='PAM: session open
> acct="test" : exe="/usr/bin/newrole" (hostname=?, addr=?, terminal=pts/1
> res=success)'
> type=USER_ROLE_CHANGE msg=audit(1271345954.304:1159797): user pid=9223
> uid=0 auid=502 subj=staff_u:staff_r:newrole_t:s0 msg='newrole:
> old-context=staff_u:staff_r:staff_t new-context=staff_u:sysadm_r:sysadm_t:
> exe="/usr/bin/newrole" (hostname=?, addr=?, terminal=/dev/pts/1
> res=success)'
> type=USER_END msg=audit(1271345954.489:1159798): user pid=9219 uid=0
> auid=502 subj=staff_u:staff_r:newrole_t:s0 msg='PAM: session close
> acct="test" : exe="/usr/bin/newrole" (hostname=?, addr=?, terminal=pts/1
> res=success)'
> 
> 
> No AVCs... weird.  Also, I thought the point of having the pam_rootok.so in
> /etc/pam.d/newrole was so that the user wouldn't need to enter their
> password when newrole was run?
> 
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkvHUR8ACgkQrlYvE4MpobPPfACcDu08isi68epYlJL+GRzdahun
HO0AmwfmUDEIA1/VGtqdaVQOIP4ZCpWK
=kz+m
-----END PGP SIGNATURE-----

--
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: sudo + selinux

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/14/2010 12:37 PM, James Cammarata wrote:
> 
> On Wed, 14 Apr 2010 11:16:56 -0500, James Cammarata <jimi@sngx.net> wrote:
>>>>
>>> Does this work in permissive mode?
>>
>> Actually, no, it doesn't, but I think I found the problem.  I was
> assuming
>> all I needed at the end of newrole was --, but the man page says to use
> "--
>> -c", which does seem to be working now.  Turning enforcing back on:
>>
>> [test@kvm001 ~]$ sudo /usr/bin/audit.sh echo "hi there"
>> Password:
>> hi there
>>
>> So, that seems to be good, but it's still asking for the password for the
>> selinux user.  Is pam_rootok not doing what it's supposed to?
The problem is rootok requires and SELinux priv to work also.  So this
will not work unless you add the rootok to your default userdomain.

allow staff_t self:passwd rootok;

> 
> Something else weird... I added a shebang line to the top of the audit.sh
> script, and now when I run it I don't get prompted for a password, but it
> fails with this message:
> 
> [test@kvm001 ~]$ sudo /usr/bin/audit.sh echo hi
> Could not determine enforcing mode.
> 
> Once again, there are no AVC's in the audit.log.  I did have to add this to
> my custom policy though:
> 
> allow staff_sudo_t newrole_exec_t:file { execute execute_no_trans };
> 
> 

Add an id -Z to the top of audit.sh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkvHcjEACgkQrlYvE4MpobN31ACfYdQCBQmXVWjPINEa5q3Y1/Nc
l2gAoN29FupLNXfkgWZTwceeHKSWG2/1
=o+05
-----END PGP SIGNATURE-----

--
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: sudo + selinux

[Stephen Smalley]

On Thu, 2010-04-15 at 16:08 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 04/14/2010 12:37 PM, James Cammarata wrote:
> > 
> > On Wed, 14 Apr 2010 11:16:56 -0500, James Cammarata <jimi@sngx.net> wrote:
> >>>>
> >>> Does this work in permissive mode?
> >>
> >> Actually, no, it doesn't, but I think I found the problem.  I was
> > assuming
> >> all I needed at the end of newrole was --, but the man page says to use
> > "--
> >> -c", which does seem to be working now.  Turning enforcing back on:
> >>
> >> [test@kvm001 ~]$ sudo /usr/bin/audit.sh echo "hi there"
> >> Password:
> >> hi there
> >>
> >> So, that seems to be good, but it's still asking for the password for the
> >> selinux user.  Is pam_rootok not doing what it's supposed to?
> The problem is rootok requires and SELinux priv to work also.  So this
> will not work unless you add the rootok to your default userdomain.
> 
> allow staff_t self:passwd rootok;
> 
> > 
> > Something else weird... I added a shebang line to the top of the audit.sh
> > script, and now when I run it I don't get prompted for a password, but it
> > fails with this message:
> > 
> > [test@kvm001 ~]$ sudo /usr/bin/audit.sh echo hi
> > Could not determine enforcing mode.
> > 
> > Once again, there are no AVC's in the audit.log.  I did have to add this to
> > my custom policy though:
> > 
> > allow staff_sudo_t newrole_exec_t:file { execute execute_no_trans };
> > 
> > 
> 
> Add an id -Z to the top of audit.sh

At least part of the problem is that it is staying in staff_sudo_t
rather than transitioning back to staff_t.  Only the sudo program itself
should be running in $1_sudo_t, not the programs it executes.  Doesn't
it execute sesh as a helper to transition back to the originating
domain?

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