Re: sudo + selinux

[Daniel J Walsh <dwalsh@redhat.com>]

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