SELinux constrain policy for escalated root user

[Anamitra Dutta Majumdar (anmajumd)]

Hi Daniel,

We still need tomcat to be able to run useradd and semanage command.

Tomcat context is
 uid=502(tomcat) gid=502(tomcat)
  groups=500(sftpuser),501(platform),502(tomcat),505(informix),
  506(ccmbase),509(ccmsyslog),575(download)
  context=system_u:system_r:tomcatd_t:SystemLow-SystemHigh


However we do not want this capability for a "tomcat escalated root" user.

So we need to differentiate between a "tomcat escalated root" and the
"tomcat" users here.
We do not want the "tomcat escalated root user" to execute useradd and
semanage commands but the tomcat "user"
Still needs that capability.

Is this doable through type enforcements.

Thanks,
Anamitra

On 9/3/13 5:18 AM, "Daniel J Walsh" <dwalsh at redhat.com> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 09/03/2013 02:28 AM, Anamitra Dutta Majumdar (anmajumd) wrote:
>> We need to constrain a tomcat escalated root user from executing
>>"useradd"
>> and "semanage" commands on RHEL6.
>> 
>> Can we add a SELinux constraint policy to achieve  the same?
>> 
>> A tomcat escalated root user (I.e when a "tomcat" user escalates to the
>> "root" user on the system) has the following security context
>> 
>> uid=0(*root*) gid=0(root)
>> groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
>> context=system_u:system_r:*tomcatd_t*:SystemLow-SystemHigh
>> 
>> The logic of this constraint should be be as follows..
>> 
>> If id="root" and source type="tomcatd_t"
>> 
>> Then disallow domain transition to both "useradd_/exec_t" as well as
>> "semanage_/exec_t"
>> 
>> 1. Is this something doable through an SELinux constrain policy. 2. If
>>so
>> what should be the syntax of the policy.
>> 
>> 
>> -- selinux mailing list selinux at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>> 
>This is a type enforcement issue not a constraint issue. tomcatd can be
>prevented from running useradd_t regardless of its UID, and more
>importantly
>should not be allowed to write /etc/passwd (etc_t) or /etc/shadow
>(shadow_t).
>
>No constraint needed to do this.  Just don't allow t to write etc_t and
>shadow_t.
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.14 (GNU/Linux)
>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
>iEYEARECAAYFAlIl04QACgkQrlYvE4MpobPlFACfQLOx5tnOBAyVCgvocPUuzkgE
>viEAn1q6SZ9AWu+BtMEkIhKbpfNODg9W
>=X9Ks
>-----END PGP SIGNATURE-----