Sudo Changes for SELinux

Sudo Changes for SELinux

[Daniel J Walsh]

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

I have a working demonstration of  My version of RBAC in Rawhide/FC8.
In my view of the world, users have two roles.  User Role and Admin Role.

So I might login as a staff_t user and be able to transition to
webadm_r:webadm_r.

In Rawhide right now staff_t can only run sudo to become root.
Staff_t is not allowed to execute su.  staff_t users should not know the
root password. I have hacked up a script /usr/bin/webadm which executes
newrole -r webadm_r -t webadm_t and newrole's pam has pam_rootok.

Now I edit the /etc/sudoers and allow

dwalsh ALL=(ALL) /usr/bin/webadm

This allows me to use sudo to become webadm_t as root.  (Policy
obviously has to be correct.  But this is very cumbersome for the
administrator and does not scale.

I think we need to add SELinux support to sudo, so the administrator
could easily add something to /etc/sodoers like

dwalsh ALL=(ALL) ROLE=webadm_r TYPE=webadm_t /bin/sh

then sudo would execute the code that newrole does to very the
transition and

setexeccon(dwalsh:webadm_t:webadm_t)
exec(/bin/sh)

I was told that you are the upstream maintainer of sudo, so I wanted
your input/help on making sudo selinux aware.

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

iEYEARECAAYFAkeE7+cACgkQrlYvE4MpobMFuACghnhJJpGMkCN5nZE5vlb/O+2H
auIAoOXNJ0rWvALJAt8Y8kLPBwkVQD8f
=OnRG
-----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 Changes for SELinux

[Todd Miller]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I have a working demonstration of  My version of RBAC in Rawhide/FC8.
> In my view of the world, users have two roles.  User Role and Admin
> Role. 
> 
> So I might login as a staff_t user and be able to transition to
> webadm_r:webadm_r.
> 
> In Rawhide right now staff_t can only run sudo to become root.
> Staff_t is not allowed to execute su.  staff_t users should not know
> the root password. I have hacked up a script /usr/bin/webadm which
> executes newrole -r webadm_r -t webadm_t and newrole's pam has
> pam_rootok. 
> 
> Now I edit the /etc/sudoers and allow
> 
> dwalsh ALL=(ALL) /usr/bin/webadm
> 
> This allows me to use sudo to become webadm_t as root.  (Policy
> obviously has to be correct.  But this is very cumbersome for the
> administrator and does not scale.
> 
> I think we need to add SELinux support to sudo, so the administrator
> could easily add something to /etc/sodoers like
> 
> dwalsh ALL=(ALL) ROLE=webadm_r TYPE=webadm_t /bin/sh
> 
> then sudo would execute the code that newrole does to very the
> transition and
> 
> setexeccon(dwalsh:webadm_t:webadm_t)
> exec(/bin/sh)
> 
> I was told that you are the upstream maintainer of sudo, so I wanted
> your input/help on making sudo selinux aware.

I suppose it depends on what you really want to be able to do.  Do you

a) wish to be able to run arbitrary commands via sudo but be able to
   specify a role and type ala newrole via -r and -t flags?

or

b) want to be able to force a command run by sudo to use a role and type
   that is specified in the sudoers file?

Doing a) is probably easier than b) though the two are not mutually
exclusive.

 - todd


--
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 Changes for SELinux

[Stephen Smalley]

On Wed, 2008-01-09 at 12:51 -0500, Todd Miller wrote:
> Daniel J Walsh wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > I have a working demonstration of  My version of RBAC in Rawhide/FC8.
> > In my view of the world, users have two roles.  User Role and Admin
> > Role. 
> > 
> > So I might login as a staff_t user and be able to transition to
> > webadm_r:webadm_r.
> > 
> > In Rawhide right now staff_t can only run sudo to become root.
> > Staff_t is not allowed to execute su.  staff_t users should not know
> > the root password. I have hacked up a script /usr/bin/webadm which
> > executes newrole -r webadm_r -t webadm_t and newrole's pam has
> > pam_rootok. 
> > 
> > Now I edit the /etc/sudoers and allow
> > 
> > dwalsh ALL=(ALL) /usr/bin/webadm
> > 
> > This allows me to use sudo to become webadm_t as root.  (Policy
> > obviously has to be correct.  But this is very cumbersome for the
> > administrator and does not scale.
> > 
> > I think we need to add SELinux support to sudo, so the administrator
> > could easily add something to /etc/sodoers like
> > 
> > dwalsh ALL=(ALL) ROLE=webadm_r TYPE=webadm_t /bin/sh
> > 
> > then sudo would execute the code that newrole does to very the
> > transition and
> > 
> > setexeccon(dwalsh:webadm_t:webadm_t)
> > exec(/bin/sh)
> > 
> > I was told that you are the upstream maintainer of sudo, so I wanted
> > your input/help on making sudo selinux aware.
> 
> I suppose it depends on what you really want to be able to do.  Do you
> 
> a) wish to be able to run arbitrary commands via sudo but be able to
>    specify a role and type ala newrole via -r and -t flags?
> 
> or
> 
> b) want to be able to force a command run by sudo to use a role and type
>    that is specified in the sudoers file?
> 
> Doing a) is probably easier than b) though the two are not mutually
> exclusive.

Didn't we used to have a) in Fedora (before Fedora 5, IIRC)?  And didn't
it suffer from a number of problems?  Have to go back to the
fedora-selinux archives and/or bugzillas to recapture the history there.

Also, while integration with sudo might be useful, it seems more
pressing to integrate with policykit given its increasing adoption by
distributions, right?

-- 
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: Sudo Changes for SELinux

[Daniel J Walsh]

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

Stephen Smalley wrote:
> On Wed, 2008-01-09 at 12:51 -0500, Todd Miller wrote:
>> Daniel J Walsh wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> I have a working demonstration of  My version of RBAC in Rawhide/FC8.
>>> In my view of the world, users have two roles.  User Role and Admin
>>> Role. 
>>>
>>> So I might login as a staff_t user and be able to transition to
>>> webadm_r:webadm_r.
>>>
>>> In Rawhide right now staff_t can only run sudo to become root.
>>> Staff_t is not allowed to execute su.  staff_t users should not know
>>> the root password. I have hacked up a script /usr/bin/webadm which
>>> executes newrole -r webadm_r -t webadm_t and newrole's pam has
>>> pam_rootok. 
>>>
>>> Now I edit the /etc/sudoers and allow
>>>
>>> dwalsh ALL=(ALL) /usr/bin/webadm
>>>
>>> This allows me to use sudo to become webadm_t as root.  (Policy
>>> obviously has to be correct.  But this is very cumbersome for the
>>> administrator and does not scale.
>>>
>>> I think we need to add SELinux support to sudo, so the administrator
>>> could easily add something to /etc/sodoers like
>>>
>>> dwalsh ALL=(ALL) ROLE=webadm_r TYPE=webadm_t /bin/sh
>>>
>>> then sudo would execute the code that newrole does to very the
>>> transition and
>>>
>>> setexeccon(dwalsh:webadm_t:webadm_t)
>>> exec(/bin/sh)
>>>
>>> I was told that you are the upstream maintainer of sudo, so I wanted
>>> your input/help on making sudo selinux aware.
>> I suppose it depends on what you really want to be able to do.  Do you
>>
>> a) wish to be able to run arbitrary commands via sudo but be able to
>>    specify a role and type ala newrole via -r and -t flags?
>>
>> or
>>
>> b) want to be able to force a command run by sudo to use a role and type
>>    that is specified in the sudoers file?
>>
I don't want the user to even know about webadm_r:webadm_t or care.  He
will just know that when he is UID 0 he can only use certain directories.

Allowing someone to specfify

sudo -r webadm_r -t webadmin_t /bin/sh

Is not important.

Having them say

sudo /bin/sh

and ending up with staff_u:webadm_r:webadm_t is important.

>> Doing a) is probably easier than b) though the two are not mutually
>> exclusive.
> 
> Didn't we used to have a) in Fedora (before Fedora 5, IIRC)?  And didn't
> it suffer from a number of problems?  Have to go back to the
> fedora-selinux archives and/or bugzillas to recapture the history there.
> 
> Also, while integration with sudo might be useful, it seems more
> pressing to integrate with policykit given its increasing adoption by
> distributions, right?
> 
No sudo and policykit serve two different problems.  I am looking for
sudo as a tool for use by actual administrators.  You need to get
something configured as the root user.  Currently you use su to do this.
And give out the root password.  With SELinux we can confine the user to
the particular files/processes that they can effect while running as the
root user.  The beauty of using SELinux in this manner is I can allow
the administrator to configure the system with tools like
vi/emacs/grep/cat/sed ...  While controlling which files he can modify
and which processes he can transition to (initscripts).

policykit needs policy to confine apps that are doing things on behalf
of the user.  So the user wants to change the clock.  Some how the user
authenticates himself the PolicyKit and the PolicyKit/Dbus executes
commands as root on behalf of the user.  The big caviat here is that we
need to make sure the tools ONLY do the things for the user that they
are defined to do.  So if the user is allowed to change the Time on his
machine, the script that runs on his behalf had better only be able to
change the time.

Whether or not SELinux gets involved in the authorization is up for debate.


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

iEYEARECAAYFAkeGcKgACgkQrlYvE4MpobP4BgCgw9H0QT/+1MkpIeDNPwrX1ITI
QWgAoOMR9omLPgmCkNP86Rt+wh0+F1fJ
=kCk7
-----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 Changes for SELinux

[Stefan Schulze Frielinghaus]

On Thu, 2008-01-10 at 14:23 -0500, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stephen Smalley wrote:
> > On Wed, 2008-01-09 at 12:51 -0500, Todd Miller wrote:
> >> Daniel J Walsh wrote:
> >>> -----BEGIN PGP SIGNED MESSAGE-----
> >>> Hash: SHA1
> >>>
> >>> I have a working demonstration of  My version of RBAC in Rawhide/FC8.
> >>> In my view of the world, users have two roles.  User Role and Admin
> >>> Role. 
> >>>
> >>> So I might login as a staff_t user and be able to transition to
> >>> webadm_r:webadm_r.
> >>>
> >>> In Rawhide right now staff_t can only run sudo to become root.
> >>> Staff_t is not allowed to execute su.  staff_t users should not know
> >>> the root password. I have hacked up a script /usr/bin/webadm which
> >>> executes newrole -r webadm_r -t webadm_t and newrole's pam has
> >>> pam_rootok. 
> >>>
> >>> Now I edit the /etc/sudoers and allow
> >>>
> >>> dwalsh ALL=(ALL) /usr/bin/webadm
> >>>
> >>> This allows me to use sudo to become webadm_t as root.  (Policy
> >>> obviously has to be correct.  But this is very cumbersome for the
> >>> administrator and does not scale.
> >>>
> >>> I think we need to add SELinux support to sudo, so the administrator
> >>> could easily add something to /etc/sodoers like
> >>>
> >>> dwalsh ALL=(ALL) ROLE=webadm_r TYPE=webadm_t /bin/sh
> >>>
> >>> then sudo would execute the code that newrole does to very the
> >>> transition and
> >>>
> >>> setexeccon(dwalsh:webadm_t:webadm_t)
> >>> exec(/bin/sh)
> >>>
> >>> I was told that you are the upstream maintainer of sudo, so I wanted
> >>> your input/help on making sudo selinux aware.
> >> I suppose it depends on what you really want to be able to do.  Do you
> >>
> >> a) wish to be able to run arbitrary commands via sudo but be able to
> >>    specify a role and type ala newrole via -r and -t flags?
> >>
> >> or
> >>
> >> b) want to be able to force a command run by sudo to use a role and type
> >>    that is specified in the sudoers file?
> >>
> I don't want the user to even know about webadm_r:webadm_t or care.  He
> will just know that when he is UID 0 he can only use certain directories.
> 
> Allowing someone to specfify
> 
> sudo -r webadm_r -t webadmin_t /bin/sh
> 
> Is not important.
> 
> Having them say
> 
> sudo /bin/sh
> 
> and ending up with staff_u:webadm_r:webadm_t is important.

The idea with specifying the role and type at the sudo level is quiet
good and important I think. Just imagine a scenario where you have one
admin who takes care about the web-server and email-server. So you would
have a webadmin_t and mailadmin_t type. If the admin wants to execute
something like "sudo vim" (e.g. to change the config files) he would
only have on role/type e.g. the webadmin_t but could _not_ change to
mailadmin_t. You could easily fix this while creating a secondary Linux
user to get around this but I think this wouldn't be nice and could
possibly end up with dozens/hundreds/... of Linux user accounts (which
are hard to manage, keep clean and isn't user friendly ...).

> 
> >> Doing a) is probably easier than b) though the two are not mutually
> >> exclusive.
> > 
> > Didn't we used to have a) in Fedora (before Fedora 5, IIRC)?  And didn't
> > it suffer from a number of problems?  Have to go back to the
> > fedora-selinux archives and/or bugzillas to recapture the history there.
> > 
> > Also, while integration with sudo might be useful, it seems more
> > pressing to integrate with policykit given its increasing adoption by
> > distributions, right?
> > 
> No sudo and policykit serve two different problems.  I am looking for
> sudo as a tool for use by actual administrators.  You need to get
> something configured as the root user.  Currently you use su to do this.
> And give out the root password.  With SELinux we can confine the user to
> the particular files/processes that they can effect while running as the
> root user.  The beauty of using SELinux in this manner is I can allow
> the administrator to configure the system with tools like
> vi/emacs/grep/cat/sed ...  While controlling which files he can modify
> and which processes he can transition to (initscripts).
> 
> policykit needs policy to confine apps that are doing things on behalf
> of the user.  So the user wants to change the clock.  Some how the user
> authenticates himself the PolicyKit and the PolicyKit/Dbus executes
> commands as root on behalf of the user.  The big caviat here is that we
> need to make sure the tools ONLY do the things for the user that they
> are defined to do.  So if the user is allowed to change the Time on his
> machine, the script that runs on his behalf had better only be able to
> change the time.
> 
> Whether or not SELinux gets involved in the authorization is up for debate.

I would really appreciate something like this. It makes it very easy to
allow only certain people to access/admin the stuff they need to. It is
always good to know that an webserver-admin can only damage the
webserver and not the whole system ;-)


--
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 Changes for SELinux

[Daniel J Walsh]

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

Stefan Schulze Frielinghaus wrote:
> On Thu, 2008-01-10 at 14:23 -0500, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Stephen Smalley wrote:
>>> On Wed, 2008-01-09 at 12:51 -0500, Todd Miller wrote:
>>>> Daniel J Walsh wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> I have a working demonstration of  My version of RBAC in Rawhide/FC8.
>>>>> In my view of the world, users have two roles.  User Role and Admin
>>>>> Role. 
>>>>>
>>>>> So I might login as a staff_t user and be able to transition to
>>>>> webadm_r:webadm_r.
>>>>>
>>>>> In Rawhide right now staff_t can only run sudo to become root.
>>>>> Staff_t is not allowed to execute su.  staff_t users should not know
>>>>> the root password. I have hacked up a script /usr/bin/webadm which
>>>>> executes newrole -r webadm_r -t webadm_t and newrole's pam has
>>>>> pam_rootok. 
>>>>>
>>>>> Now I edit the /etc/sudoers and allow
>>>>>
>>>>> dwalsh ALL=(ALL) /usr/bin/webadm
>>>>>
>>>>> This allows me to use sudo to become webadm_t as root.  (Policy
>>>>> obviously has to be correct.  But this is very cumbersome for the
>>>>> administrator and does not scale.
>>>>>
>>>>> I think we need to add SELinux support to sudo, so the administrator
>>>>> could easily add something to /etc/sodoers like
>>>>>
>>>>> dwalsh ALL=(ALL) ROLE=webadm_r TYPE=webadm_t /bin/sh
>>>>>
>>>>> then sudo would execute the code that newrole does to very the
>>>>> transition and
>>>>>
>>>>> setexeccon(dwalsh:webadm_t:webadm_t)
>>>>> exec(/bin/sh)
>>>>>
>>>>> I was told that you are the upstream maintainer of sudo, so I wanted
>>>>> your input/help on making sudo selinux aware.
>>>> I suppose it depends on what you really want to be able to do.  Do you
>>>>
>>>> a) wish to be able to run arbitrary commands via sudo but be able to
>>>>    specify a role and type ala newrole via -r and -t flags?
>>>>
>>>> or
>>>>
>>>> b) want to be able to force a command run by sudo to use a role and type
>>>>    that is specified in the sudoers file?
>>>>
>> I don't want the user to even know about webadm_r:webadm_t or care.  He
>> will just know that when he is UID 0 he can only use certain directories.
>>
>> Allowing someone to specfify
>>
>> sudo -r webadm_r -t webadmin_t /bin/sh
>>
>> Is not important.
>>
>> Having them say
>>
>> sudo /bin/sh
>>
>> and ending up with staff_u:webadm_r:webadm_t is important.
> 
> The idea with specifying the role and type at the sudo level is quiet
> good and important I think. Just imagine a scenario where you have one
> admin who takes care about the web-server and email-server. So you would
> have a webadmin_t and mailadmin_t type. If the admin wants to execute
> something like "sudo vim" (e.g. to change the config files) he would
> only have on role/type e.g. the webadmin_t but could _not_ change to
> mailadmin_t. You could easily fix this while creating a secondary Linux
> user to get around this but I think this wouldn't be nice and could
> possibly end up with dozens/hundreds/... of Linux user accounts (which
> are hard to manage, keep clean and isn't user friendly ...).
> 
Well this is actually what I would like to avoid.  I would prefer one
domain that allows the administrator to admin both the httpd and mailman

I am adding to Fedora policy admin interfaces so you can easily creat an
administrator policy that looks something like.

userdom_base_user_template(myadm)
apache_admin(myadm_t)
mailman_admin(myadm_t)
mysql_admin(myadm_t)
gen_require(`
        type staff_t;
')
allow staff_t webadm_t:process transition;

You load this policy module and create a staff user with the myadm_r,
and now use sudo to get a shell that can manage mysql, mailman, and
apache.  The user then does not need to think about, I am administrating
the apache so I need to execute some bizare commands to become root, and
then later that shell is no good for managing mailman or mysql.


>>>> Doing a) is probably easier than b) though the two are not mutually
>>>> exclusive.
>>> Didn't we used to have a) in Fedora (before Fedora 5, IIRC)?  And didn't
>>> it suffer from a number of problems?  Have to go back to the
>>> fedora-selinux archives and/or bugzillas to recapture the history there.
>>>
>>> Also, while integration with sudo might be useful, it seems more
>>> pressing to integrate with policykit given its increasing adoption by
>>> distributions, right?
>>>
>> No sudo and policykit serve two different problems.  I am looking for
>> sudo as a tool for use by actual administrators.  You need to get
>> something configured as the root user.  Currently you use su to do this.
>> And give out the root password.  With SELinux we can confine the user to
>> the particular files/processes that they can effect while running as the
>> root user.  The beauty of using SELinux in this manner is I can allow
>> the administrator to configure the system with tools like
>> vi/emacs/grep/cat/sed ...  While controlling which files he can modify
>> and which processes he can transition to (initscripts).
>>
>> policykit needs policy to confine apps that are doing things on behalf
>> of the user.  So the user wants to change the clock.  Some how the user
>> authenticates himself the PolicyKit and the PolicyKit/Dbus executes
>> commands as root on behalf of the user.  The big caviat here is that we
>> need to make sure the tools ONLY do the things for the user that they
>> are defined to do.  So if the user is allowed to change the Time on his
>> machine, the script that runs on his behalf had better only be able to
>> change the time.
>>
>> Whether or not SELinux gets involved in the authorization is up for debate.
> 
> I would really appreciate something like this. It makes it very easy to
> allow only certain people to access/admin the stuff they need to. It is
> always good to know that an webserver-admin can only damage the
> webserver and not the whole system ;-)
> 

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

iEYEARECAAYFAkeHf0IACgkQrlYvE4MpobP+ngCeIRm8RXbGvfFcidWMB8g0kZDG
dKIAn1/aiMefqyzoeUhQQOvGrBtwXS4T
=oljc
-----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 Changes for SELinux

[Stephen Smalley]

On Fri, 2008-01-11 at 09:37 -0500, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stefan Schulze Frielinghaus wrote:
> > On Thu, 2008-01-10 at 14:23 -0500, Daniel J Walsh wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Stephen Smalley wrote:
> >>> On Wed, 2008-01-09 at 12:51 -0500, Todd Miller wrote:
> >>>> Daniel J Walsh wrote:
> >>>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>>> Hash: SHA1
> >>>>>
> >>>>> I have a working demonstration of  My version of RBAC in Rawhide/FC8.
> >>>>> In my view of the world, users have two roles.  User Role and Admin
> >>>>> Role. 
> >>>>>
> >>>>> So I might login as a staff_t user and be able to transition to
> >>>>> webadm_r:webadm_r.
> >>>>>
> >>>>> In Rawhide right now staff_t can only run sudo to become root.
> >>>>> Staff_t is not allowed to execute su.  staff_t users should not know
> >>>>> the root password. I have hacked up a script /usr/bin/webadm which
> >>>>> executes newrole -r webadm_r -t webadm_t and newrole's pam has
> >>>>> pam_rootok. 
> >>>>>
> >>>>> Now I edit the /etc/sudoers and allow
> >>>>>
> >>>>> dwalsh ALL=(ALL) /usr/bin/webadm
> >>>>>
> >>>>> This allows me to use sudo to become webadm_t as root.  (Policy
> >>>>> obviously has to be correct.  But this is very cumbersome for the
> >>>>> administrator and does not scale.
> >>>>>
> >>>>> I think we need to add SELinux support to sudo, so the administrator
> >>>>> could easily add something to /etc/sodoers like
> >>>>>
> >>>>> dwalsh ALL=(ALL) ROLE=webadm_r TYPE=webadm_t /bin/sh
> >>>>>
> >>>>> then sudo would execute the code that newrole does to very the
> >>>>> transition and
> >>>>>
> >>>>> setexeccon(dwalsh:webadm_t:webadm_t)
> >>>>> exec(/bin/sh)
> >>>>>
> >>>>> I was told that you are the upstream maintainer of sudo, so I wanted
> >>>>> your input/help on making sudo selinux aware.
> >>>> I suppose it depends on what you really want to be able to do.  Do you
> >>>>
> >>>> a) wish to be able to run arbitrary commands via sudo but be able to
> >>>>    specify a role and type ala newrole via -r and -t flags?
> >>>>
> >>>> or
> >>>>
> >>>> b) want to be able to force a command run by sudo to use a role and type
> >>>>    that is specified in the sudoers file?
> >>>>
> >> I don't want the user to even know about webadm_r:webadm_t or care.  He
> >> will just know that when he is UID 0 he can only use certain directories.
> >>
> >> Allowing someone to specfify
> >>
> >> sudo -r webadm_r -t webadmin_t /bin/sh
> >>
> >> Is not important.
> >>
> >> Having them say
> >>
> >> sudo /bin/sh
> >>
> >> and ending up with staff_u:webadm_r:webadm_t is important.
> > 
> > The idea with specifying the role and type at the sudo level is quiet
> > good and important I think. Just imagine a scenario where you have one
> > admin who takes care about the web-server and email-server. So you would
> > have a webadmin_t and mailadmin_t type. If the admin wants to execute
> > something like "sudo vim" (e.g. to change the config files) he would
> > only have on role/type e.g. the webadmin_t but could _not_ change to
> > mailadmin_t. You could easily fix this while creating a secondary Linux
> > user to get around this but I think this wouldn't be nice and could
> > possibly end up with dozens/hundreds/... of Linux user accounts (which
> > are hard to manage, keep clean and isn't user friendly ...).
> > 
> Well this is actually what I would like to avoid.  I would prefer one
> domain that allows the administrator to admin both the httpd and mailman
> 
> I am adding to Fedora policy admin interfaces so you can easily creat an
> administrator policy that looks something like.
> 
> userdom_base_user_template(myadm)
> apache_admin(myadm_t)
> mailman_admin(myadm_t)
> mysql_admin(myadm_t)
> gen_require(`
>         type staff_t;
> ')
> allow staff_t webadm_t:process transition;

You don't want staff_t to directly transition to webadm_t.  It should
have to go through an intermediary, like newrole_t or sudo_t.

> 
> You load this policy module and create a staff user with the myadm_r,
> and now use sudo to get a shell that can manage mysql, mailman, and
> apache.  The user then does not need to think about, I am administrating
> the apache so I need to execute some bizare commands to become root, and
> then later that shell is no good for managing mailman or mysql.
> 
> 
> >>>> Doing a) is probably easier than b) though the two are not mutually
> >>>> exclusive.
> >>> Didn't we used to have a) in Fedora (before Fedora 5, IIRC)?  And didn't
> >>> it suffer from a number of problems?  Have to go back to the
> >>> fedora-selinux archives and/or bugzillas to recapture the history there.
> >>>
> >>> Also, while integration with sudo might be useful, it seems more
> >>> pressing to integrate with policykit given its increasing adoption by
> >>> distributions, right?
> >>>
> >> No sudo and policykit serve two different problems.  I am looking for
> >> sudo as a tool for use by actual administrators.  You need to get
> >> something configured as the root user.  Currently you use su to do this.
> >> And give out the root password.  With SELinux we can confine the user to
> >> the particular files/processes that they can effect while running as the
> >> root user.  The beauty of using SELinux in this manner is I can allow
> >> the administrator to configure the system with tools like
> >> vi/emacs/grep/cat/sed ...  While controlling which files he can modify
> >> and which processes he can transition to (initscripts).
> >>
> >> policykit needs policy to confine apps that are doing things on behalf
> >> of the user.  So the user wants to change the clock.  Some how the user
> >> authenticates himself the PolicyKit and the PolicyKit/Dbus executes
> >> commands as root on behalf of the user.  The big caviat here is that we
> >> need to make sure the tools ONLY do the things for the user that they
> >> are defined to do.  So if the user is allowed to change the Time on his
> >> machine, the script that runs on his behalf had better only be able to
> >> change the time.
> >>
> >> Whether or not SELinux gets involved in the authorization is up for debate.
> > 
> > I would really appreciate something like this. It makes it very easy to
> > allow only certain people to access/admin the stuff they need to. It is
> > always good to know that an webserver-admin can only damage the
> > webserver and not the whole system ;-)
> > 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkeHf0IACgkQrlYvE4MpobP+ngCeIRm8RXbGvfFcidWMB8g0kZDG
> dKIAn1/aiMefqyzoeUhQQOvGrBtwXS4T
> =oljc
> -----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.
-- 
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: Sudo Changes for SELinux

[Stephen Smalley]

On Fri, 2008-01-11 at 10:32 -0500, Stephen Smalley wrote:
> On Fri, 2008-01-11 at 09:37 -0500, Daniel J Walsh wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Stefan Schulze Frielinghaus wrote:
> > > On Thu, 2008-01-10 at 14:23 -0500, Daniel J Walsh wrote:
> > >> -----BEGIN PGP SIGNED MESSAGE-----
> > >> Hash: SHA1
> > >>
> > >> Stephen Smalley wrote:
> > >>> On Wed, 2008-01-09 at 12:51 -0500, Todd Miller wrote:
> > >>>> Daniel J Walsh wrote:
> > >>>>> -----BEGIN PGP SIGNED MESSAGE-----
> > >>>>> Hash: SHA1
> > >>>>>
> > >>>>> I have a working demonstration of  My version of RBAC in Rawhide/FC8.
> > >>>>> In my view of the world, users have two roles.  User Role and Admin
> > >>>>> Role. 
> > >>>>>
> > >>>>> So I might login as a staff_t user and be able to transition to
> > >>>>> webadm_r:webadm_r.
> > >>>>>
> > >>>>> In Rawhide right now staff_t can only run sudo to become root.
> > >>>>> Staff_t is not allowed to execute su.  staff_t users should not know
> > >>>>> the root password. I have hacked up a script /usr/bin/webadm which
> > >>>>> executes newrole -r webadm_r -t webadm_t and newrole's pam has
> > >>>>> pam_rootok. 
> > >>>>>
> > >>>>> Now I edit the /etc/sudoers and allow
> > >>>>>
> > >>>>> dwalsh ALL=(ALL) /usr/bin/webadm
> > >>>>>
> > >>>>> This allows me to use sudo to become webadm_t as root.  (Policy
> > >>>>> obviously has to be correct.  But this is very cumbersome for the
> > >>>>> administrator and does not scale.
> > >>>>>
> > >>>>> I think we need to add SELinux support to sudo, so the administrator
> > >>>>> could easily add something to /etc/sodoers like
> > >>>>>
> > >>>>> dwalsh ALL=(ALL) ROLE=webadm_r TYPE=webadm_t /bin/sh
> > >>>>>
> > >>>>> then sudo would execute the code that newrole does to very the
> > >>>>> transition and
> > >>>>>
> > >>>>> setexeccon(dwalsh:webadm_t:webadm_t)
> > >>>>> exec(/bin/sh)
> > >>>>>
> > >>>>> I was told that you are the upstream maintainer of sudo, so I wanted
> > >>>>> your input/help on making sudo selinux aware.
> > >>>> I suppose it depends on what you really want to be able to do.  Do you
> > >>>>
> > >>>> a) wish to be able to run arbitrary commands via sudo but be able to
> > >>>>    specify a role and type ala newrole via -r and -t flags?
> > >>>>
> > >>>> or
> > >>>>
> > >>>> b) want to be able to force a command run by sudo to use a role and type
> > >>>>    that is specified in the sudoers file?
> > >>>>
> > >> I don't want the user to even know about webadm_r:webadm_t or care.  He
> > >> will just know that when he is UID 0 he can only use certain directories.
> > >>
> > >> Allowing someone to specfify
> > >>
> > >> sudo -r webadm_r -t webadmin_t /bin/sh
> > >>
> > >> Is not important.
> > >>
> > >> Having them say
> > >>
> > >> sudo /bin/sh
> > >>
> > >> and ending up with staff_u:webadm_r:webadm_t is important.
> > > 
> > > The idea with specifying the role and type at the sudo level is quiet
> > > good and important I think. Just imagine a scenario where you have one
> > > admin who takes care about the web-server and email-server. So you would
> > > have a webadmin_t and mailadmin_t type. If the admin wants to execute
> > > something like "sudo vim" (e.g. to change the config files) he would
> > > only have on role/type e.g. the webadmin_t but could _not_ change to
> > > mailadmin_t. You could easily fix this while creating a secondary Linux
> > > user to get around this but I think this wouldn't be nice and could
> > > possibly end up with dozens/hundreds/... of Linux user accounts (which
> > > are hard to manage, keep clean and isn't user friendly ...).
> > > 
> > Well this is actually what I would like to avoid.  I would prefer one
> > domain that allows the administrator to admin both the httpd and mailman
> > 
> > I am adding to Fedora policy admin interfaces so you can easily creat an
> > administrator policy that looks something like.
> > 
> > userdom_base_user_template(myadm)
> > apache_admin(myadm_t)
> > mailman_admin(myadm_t)
> > mysql_admin(myadm_t)
> > gen_require(`
> >         type staff_t;
> > ')
> > allow staff_t webadm_t:process transition;
> 
> You don't want staff_t to directly transition to webadm_t.  It should
> have to go through an intermediary, like newrole_t or sudo_t.

Also, how are you handling the tty/pty and fd relationships (usually
addressed by newrole by relabeling the tty/pty and re-opening the fds
into its own type)?  That was a major problem with the old sudo selinux
patch.

> > 
> > You load this policy module and create a staff user with the myadm_r,
> > and now use sudo to get a shell that can manage mysql, mailman, and
> > apache.  The user then does not need to think about, I am administrating
> > the apache so I need to execute some bizare commands to become root, and
> > then later that shell is no good for managing mailman or mysql.
> > 
> > 
> > >>>> Doing a) is probably easier than b) though the two are not mutually
> > >>>> exclusive.
> > >>> Didn't we used to have a) in Fedora (before Fedora 5, IIRC)?  And didn't
> > >>> it suffer from a number of problems?  Have to go back to the
> > >>> fedora-selinux archives and/or bugzillas to recapture the history there.
> > >>>
> > >>> Also, while integration with sudo might be useful, it seems more
> > >>> pressing to integrate with policykit given its increasing adoption by
> > >>> distributions, right?
> > >>>
> > >> No sudo and policykit serve two different problems.  I am looking for
> > >> sudo as a tool for use by actual administrators.  You need to get
> > >> something configured as the root user.  Currently you use su to do this.
> > >> And give out the root password.  With SELinux we can confine the user to
> > >> the particular files/processes that they can effect while running as the
> > >> root user.  The beauty of using SELinux in this manner is I can allow
> > >> the administrator to configure the system with tools like
> > >> vi/emacs/grep/cat/sed ...  While controlling which files he can modify
> > >> and which processes he can transition to (initscripts).
> > >>
> > >> policykit needs policy to confine apps that are doing things on behalf
> > >> of the user.  So the user wants to change the clock.  Some how the user
> > >> authenticates himself the PolicyKit and the PolicyKit/Dbus executes
> > >> commands as root on behalf of the user.  The big caviat here is that we
> > >> need to make sure the tools ONLY do the things for the user that they
> > >> are defined to do.  So if the user is allowed to change the Time on his
> > >> machine, the script that runs on his behalf had better only be able to
> > >> change the time.
> > >>
> > >> Whether or not SELinux gets involved in the authorization is up for debate.
> > > 
> > > I would really appreciate something like this. It makes it very easy to
> > > allow only certain people to access/admin the stuff they need to. It is
> > > always good to know that an webserver-admin can only damage the
> > > webserver and not the whole system ;-)
> > > 
> > 
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.8 (GNU/Linux)
> > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> > 
> > iEYEARECAAYFAkeHf0IACgkQrlYvE4MpobP+ngCeIRm8RXbGvfFcidWMB8g0kZDG
> > dKIAn1/aiMefqyzoeUhQQOvGrBtwXS4T
> > =oljc
> > -----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.
-- 
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: Sudo Changes for SELinux

[Daniel J Walsh]

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

Stephen Smalley wrote:
> On Fri, 2008-01-11 at 10:32 -0500, Stephen Smalley wrote:
>> On Fri, 2008-01-11 at 09:37 -0500, Daniel J Walsh wrote:
> Stefan Schulze Frielinghaus wrote:
>>>>> On Thu, 2008-01-10 at 14:23 -0500, Daniel J Walsh wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> Stephen Smalley wrote:
>>>>>>> On Wed, 2008-01-09 at 12:51 -0500, Todd Miller wrote:
>>>>>>>> Daniel J Walsh wrote:
>>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>>> Hash: SHA1
>>>>>>>>>
>>>>>>>>> I have a working demonstration of  My version of RBAC in Rawhide/FC8.
>>>>>>>>> In my view of the world, users have two roles.  User Role and Admin
>>>>>>>>> Role. 
>>>>>>>>>
>>>>>>>>> So I might login as a staff_t user and be able to transition to
>>>>>>>>> webadm_r:webadm_r.
>>>>>>>>>
>>>>>>>>> In Rawhide right now staff_t can only run sudo to become root.
>>>>>>>>> Staff_t is not allowed to execute su.  staff_t users should not know
>>>>>>>>> the root password. I have hacked up a script /usr/bin/webadm which
>>>>>>>>> executes newrole -r webadm_r -t webadm_t and newrole's pam has
>>>>>>>>> pam_rootok. 
>>>>>>>>>
>>>>>>>>> Now I edit the /etc/sudoers and allow
>>>>>>>>>
>>>>>>>>> dwalsh ALL=(ALL) /usr/bin/webadm
>>>>>>>>>
>>>>>>>>> This allows me to use sudo to become webadm_t as root.  (Policy
>>>>>>>>> obviously has to be correct.  But this is very cumbersome for the
>>>>>>>>> administrator and does not scale.
>>>>>>>>>
>>>>>>>>> I think we need to add SELinux support to sudo, so the administrator
>>>>>>>>> could easily add something to /etc/sodoers like
>>>>>>>>>
>>>>>>>>> dwalsh ALL=(ALL) ROLE=webadm_r TYPE=webadm_t /bin/sh
>>>>>>>>>
>>>>>>>>> then sudo would execute the code that newrole does to very the
>>>>>>>>> transition and
>>>>>>>>>
>>>>>>>>> setexeccon(dwalsh:webadm_t:webadm_t)
>>>>>>>>> exec(/bin/sh)
>>>>>>>>>
>>>>>>>>> I was told that you are the upstream maintainer of sudo, so I wanted
>>>>>>>>> your input/help on making sudo selinux aware.
>>>>>>>> I suppose it depends on what you really want to be able to do.  Do you
>>>>>>>>
>>>>>>>> a) wish to be able to run arbitrary commands via sudo but be able to
>>>>>>>>    specify a role and type ala newrole via -r and -t flags?
>>>>>>>>
>>>>>>>> or
>>>>>>>>
>>>>>>>> b) want to be able to force a command run by sudo to use a role and type
>>>>>>>>    that is specified in the sudoers file?
>>>>>>>>
>>>>>> I don't want the user to even know about webadm_r:webadm_t or care.  He
>>>>>> will just know that when he is UID 0 he can only use certain directories.
>>>>>>
>>>>>> Allowing someone to specfify
>>>>>>
>>>>>> sudo -r webadm_r -t webadmin_t /bin/sh
>>>>>>
>>>>>> Is not important.
>>>>>>
>>>>>> Having them say
>>>>>>
>>>>>> sudo /bin/sh
>>>>>>
>>>>>> and ending up with staff_u:webadm_r:webadm_t is important.
>>>>> The idea with specifying the role and type at the sudo level is quiet
>>>>> good and important I think. Just imagine a scenario where you have one
>>>>> admin who takes care about the web-server and email-server. So you would
>>>>> have a webadmin_t and mailadmin_t type. If the admin wants to execute
>>>>> something like "sudo vim" (e.g. to change the config files) he would
>>>>> only have on role/type e.g. the webadmin_t but could _not_ change to
>>>>> mailadmin_t. You could easily fix this while creating a secondary Linux
>>>>> user to get around this but I think this wouldn't be nice and could
>>>>> possibly end up with dozens/hundreds/... of Linux user accounts (which
>>>>> are hard to manage, keep clean and isn't user friendly ...).
>>>>>
> Well this is actually what I would like to avoid.  I would prefer one
> domain that allows the administrator to admin both the httpd and mailman
> 
> I am adding to Fedora policy admin interfaces so you can easily creat an
> administrator policy that looks something like.
> 
> userdom_base_user_template(myadm)
> apache_admin(myadm_t)
> mailman_admin(myadm_t)
> mysql_admin(myadm_t)
> gen_require(`
>         type staff_t;
> ')
> allow staff_t webadm_t:process transition;
>>> You don't want staff_t to directly transition to webadm_t.  It should
>>> have to go through an intermediary, like newrole_t or sudo_t.
> 
>> Also, how are you handling the tty/pty and fd relationships (usually
>> addressed by newrole by relabeling the tty/pty and re-opening the fds
>> into its own type)?  That was a major problem with the old sudo selinux
>> patch.
I don't, Currently I am executing newrole in the shell script described
above.  I want to sudo to a handle all the transition/relabeling stuff.
The demo I have right now the user has to execute

sudo /usr/bin/webadm
/usr/bin/webadm looks like

#!/bin/sh
newrole -r webadm_r -t webadm_t

And I have to add pam_rootok to newroles pam or the user has to
continuously authenticate.
> 
> You load this policy module and create a staff user with the myadm_r,
> and now use sudo to get a shell that can manage mysql, mailman, and
> apache.  The user then does not need to think about, I am administrating
> the apache so I need to execute some bizare commands to become root, and
> then later that shell is no good for managing mailman or mysql.
> 
> 
>>>>>>>> Doing a) is probably easier than b) though the two are not mutually
>>>>>>>> exclusive.
>>>>>>> Didn't we used to have a) in Fedora (before Fedora 5, IIRC)?  And didn't
>>>>>>> it suffer from a number of problems?  Have to go back to the
>>>>>>> fedora-selinux archives and/or bugzillas to recapture the history there.
>>>>>>>
>>>>>>> Also, while integration with sudo might be useful, it seems more
>>>>>>> pressing to integrate with policykit given its increasing adoption by
>>>>>>> distributions, right?
>>>>>>>
>>>>>> No sudo and policykit serve two different problems.  I am looking for
>>>>>> sudo as a tool for use by actual administrators.  You need to get
>>>>>> something configured as the root user.  Currently you use su to do this.
>>>>>> And give out the root password.  With SELinux we can confine the user to
>>>>>> the particular files/processes that they can effect while running as the
>>>>>> root user.  The beauty of using SELinux in this manner is I can allow
>>>>>> the administrator to configure the system with tools like
>>>>>> vi/emacs/grep/cat/sed ...  While controlling which files he can modify
>>>>>> and which processes he can transition to (initscripts).
>>>>>>
>>>>>> policykit needs policy to confine apps that are doing things on behalf
>>>>>> of the user.  So the user wants to change the clock.  Some how the user
>>>>>> authenticates himself the PolicyKit and the PolicyKit/Dbus executes
>>>>>> commands as root on behalf of the user.  The big caviat here is that we
>>>>>> need to make sure the tools ONLY do the things for the user that they
>>>>>> are defined to do.  So if the user is allowed to change the Time on his
>>>>>> machine, the script that runs on his behalf had better only be able to
>>>>>> change the time.
>>>>>>
>>>>>> Whether or not SELinux gets involved in the authorization is up for debate.
>>>>> I would really appreciate something like this. It makes it very easy to
>>>>> allow only certain people to access/admin the stuff they need to. It is
>>>>> always good to know that an webserver-admin can only damage the
>>>>> webserver and not the whole system ;-)
>>>>>
>>>
- --
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.

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

iEYEARECAAYFAkeHnTkACgkQrlYvE4MpobOYHACg3d6EByKukZDtfn063OG4aXVT
JzwAoJQCyFi7M/KjmhOu3ID6iJanFiQh
=cfP1
-----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 Changes for SELinux

[Daniel J Walsh]

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

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

Here is the old patch to Sudo for SELinux FC4
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkeHvx4ACgkQrlYvE4MpobNrDQCfSGWfpxqCks32in1mYtNtCE3I
tPUAoJmCxmT86d9r3Rb85GMHJlt8/ZI2
=un/s
-----END PGP SIGNATURE-----

[-- Attachment #2: sudo-1.6.8p8-selinux.patch --]
[-- Type: text/plain, Size: 15033 bytes --]

--- /dev/null	2005-03-07 11:59:46.679193192 +0100
+++ sudo-1.6.8p8/sesh.c	2005-04-12 12:53:01.000000000 +0200
@@ -0,0 +1,46 @@
+#include <stdio.h>
+#include <unistd.h>
+#include <limits.h>
+#include <sys/types.h>
+#include <sys/wait.h>
+#include <errno.h>
+
+main (int argc, char **argv) {
+  char buf[PATH_MAX];
+  pid_t pid;
+  if ( argc < 2 ) {
+    fprintf(stderr,"%s: Requires at least one argument\n", argv[0]);
+    exit(-1);
+  }
+
+  if ((pid = fork()) < 0) {
+    snprintf(buf, sizeof(buf), "%s: Couldn't fork",argv[0]);
+    perror(buf);
+    exit(-1);
+  } else if (pid > 0) {
+    /* Parent */
+    int status;
+    int ret;
+
+    do {
+      if ((ret = waitpid(pid, &status, 0)) < 0 && errno == EINTR)
+        continue;
+      else if (ret < 0) {
+        perror("waitpid failed");
+        exit(1);
+      }
+    } while (0);
+
+    if (WIFEXITED(status))
+      exit(WEXITSTATUS(status));
+    else
+      exit(1);
+  } else {
+    /* Child */
+    execv(argv[1], &argv[1]);
+
+    snprintf(buf, sizeof(buf), "%s: Error execing %s", argv[0], argv[1]);
+    perror(buf);
+    exit(-1);
+  }
+}
--- sudo-1.6.8p8/sudo.c.selinux	2005-03-25 02:56:41.000000000 +0100
+++ sudo-1.6.8p8/sudo.c	2005-04-12 14:04:01.765372148 +0200
@@ -92,6 +92,17 @@
 #include "interfaces.h"
 #include "version.h"
 
+#ifdef WITH_SELINUX
+#include <selinux/flask.h>             /* for SECCLASS_CHR_FILE */
+#include <selinux/selinux.h>           /* for is_selinux_enabled() */
+#include <selinux/context.h>           /* for context-mangling functions */
+#include <selinux/get_default_type.h>
+char *role_s = NULL;                  /* role spec'd by user in argv[] */
+char *type_s = NULL;                  /* type spec'd by user in argv[] */
+security_context_t new_tty_context=NULL; /* security context to change to while running command*/
+security_context_t tty_context=NULL;  /* current security context of tty */
+#endif
+
 #ifndef lint
 static const char rcsid[] = "$Sudo: sudo.c,v 1.370 2004/08/24 18:01:13 millert Exp $";
 #endif /* lint */
@@ -141,7 +152,151 @@
 sigaction_t saved_sa_int, saved_sa_quit, saved_sa_tstp, saved_sa_chld;
 void (*set_perms) __P((int));
 
+#ifdef WITH_SELINUX
+security_context_t setup_tty_context(int fd, char *ttyn, security_context_t new_context) {
+  security_context_t tty_context=NULL;  /* current sid of tty */
+
+  tty_context = NULL;
+  if (fgetfilecon(fd,&tty_context) <0 ) 
+    fprintf(stderr, "Warning!  Could not get current context for %s, not relabeling.\n", ttyn);
+  
+#ifdef CANTSPELLGDB
+  if (tty_context)
+    printf("Your tty %s was labeled with context %s\n", ttyn, tty_context);
+#endif
+  
+  new_tty_context = NULL;
+  if (tty_context && security_compute_relabel(new_context,tty_context,SECCLASS_CHR_FILE,&new_tty_context) < 0)
+    fprintf(stderr, "Warning!  Could not get new context for %s, not relabeling.\n", ttyn);
+  
+#ifdef CANTSPELLGDB
+  if (new_tty_context)
+    printf("Relabeling tty %s to context %s\n", ttyn, new_tty_context);
+#endif
+  
+  if (new_tty_context) {
+    if( fsetfilecon(fd,new_tty_context)!=0 ) {
+      fprintf(stderr,"sudo: error: setfilecon on %s to %s",ttyn,new_tty_context);
+    }
+  }
+  return tty_context;
+}
+security_context_t get_exec_context(char *role_s, char *type_s) {
+
+  security_context_t old_context=NULL;	/* our original securiy ID ("old_context") */
+  security_context_t new_context=NULL;  /* our target security ID ("sid") */
+
+  /*
+   *	
+   * Step 1:  Handle command-line arguments.
+   *
+   */
+  
+  security_context_t context_s;      /* our security context as a string */
+  int context_length;
+  context_t context;                 /* manipulatable form of context_s */
+  
+  
+  /*
+   * Get the SID and context of the caller, and extract
+   * the username from the context.  Don't rely on the Linux
+   * uid information - it isn't trustworthy.
+   */
+  
+  /* Put the caller's SID into `old_context'. */
+  if( 0!=(getprevcon(&old_context)) ) {
+    fprintf(stderr,"failed to get old_context.\n");
+    exit(-1);
+  }
+  
+#ifdef CANTSPELLGDB
+  printf( "Your old context was %s\n", old_context );
+#endif
+  /* 
+   * Create a context structure so that we extract and modify 
+   * components easily. 
+   */
+  context=context_new(old_context);
+  
+  /*
+   *
+   * Step 3:  Construct a new SID based on our old SID and the
+   *          arguments specified on the command line.
+   *
+   */
+  
+  /* The first step in constructing a new SID for the new shell we  *
+   * plan to exec is to take our old context in `context' as a   *
+   * starting point, and modify it according to the options the user *
+   * specified on the command line.                                  */
+
+  /* Set the SELinux user identity to root */
+  context_user_set(context, "root");
+  
+  /* If the user specified a new role on the command line (if `role_s'   *
+   * is set), then replace the old role in `context' with this new role. */
+  if( role_s ) {
+    if( !type_s ) {
+      if( get_default_type(role_s,&type_s) )
+	{
+	  fprintf(stderr,"Couldn't get default type.\n");
+	  exit(-1);
+	}
+#ifdef CANTSPELLGDB
+      printf( "Your type will be %s.\n", type_s );
+#endif  
+    }
+    
+    if( context_role_set(context,role_s)) {
+      fprintf(stderr,"failed to set new role %s\n",role_s);
+      exit(-1);
+    }
+#ifdef CANTSPELLGDB
+    printf("Your new role is %s\n",context_role_get(context));
+#endif
+    
+    /* If the user specified a new type on the command line (if `type_s'   *
+     * is set), then replace the old type in `context' with this new type. */
+    if( type_s ) {
+      if( context_type_set(context,type_s)) {
+	fprintf(stderr,"failed to set new type %s\n",type_s);
+	exit(-1);
+      }
+#ifdef CANTSPELLGDB
+      printf("Your new type is %s\n",context_type_get(context));
+#endif
+    } /* if user specified new type */
+    
+    /* The second step in creating the new SID is to convert our modified *
+     * `context' structure back to a context string and then to a SID.    */
+    
+    /* Make `context_s' point to a string version of the new `context'.  */
+    if( !(new_context=strdup(context_str(context)))) {
+      fprintf(stderr,"failed to convert new context to string\n" );
+      exit(-1);
+    }
+    
+  } /* if user specified new role */
+  else {
+    if (get_default_context(context_user_get(context),
+			    NULL,
+			    &new_context)) {
+      fprintf(stderr,"failed to get default context\n" );
+      exit(-1);
+    }
+  }
+  context_free(context);
+  freecon(old_context);
+
+  if (security_check_context(new_context) < 0) {
+    fprintf(stderr, "%s is not a valid context\n", new_context);
+    exit(-1);
+  }
+
+  return new_context;
+}
 
+#endif
 int
 main(argc, argv, envp)
     int argc;
@@ -149,10 +304,10 @@
     char **envp;
 {
     int validated;
-    int fd;
     int cmnd_status;
     int sudo_mode;
     int pwflag;
+    int fd;
     char **new_environ;
     sigaction_t sa;
     extern int printmatches;
@@ -203,9 +358,6 @@
     /* Setup defaults data structures. */
     init_defaults();
 
-    /* Load the list of local ip addresses and netmasks.  */
-    load_interfaces();
-
     pwflag = 0;
     if (ISSET(sudo_mode, MODE_SHELL))
 	user_cmnd = "shell";
@@ -219,6 +371,8 @@
 		    putchar('\n');
 		    dump_auth_methods();
 		    dump_defaults();
+		    /* Load the list of local ip addresses and netmasks.  */
+		    load_interfaces();
 		    dump_interfaces();
 		}
 		exit(0);
@@ -445,8 +599,44 @@
 #ifndef PROFILING
 	if (ISSET(sudo_mode, MODE_BACKGROUND) && fork() > 0)
 	    exit(0);
-	else
-	    EXECV(safe_cmnd, NewArgv);	/* run the command */
+#ifdef WITH_SELINUX
+	if( is_selinux_enabled() >0) {
+	  int fd;
+	  char *ttyn   = NULL;	                /* tty path */
+	  security_context_t new_context=NULL;  /* our target security ID ("sid") */
+	  security_context_t chk_tty_context= NULL;
+
+	  new_context=get_exec_context(role_s,type_s);
+#ifdef CANTSPELLGDB
+	  printf("Your new context is %s\n",new_context);
+#endif
+
+	  if (setexeccon(new_context) < 0) {
+	    fprintf(stderr, "Could not set exec context to %s.\n", new_context);
+	    exit(-1);
+	  }
+	  freecon(new_context);
+	  {
+	    /* 
+	       SELinux will only not transition properly with the following
+	       code.  Basically if the user chooses to use a different security
+	       context.  We need to start the selinux shell, before executing 
+	       the command.  This way the process transition will happen 
+	       correctly. For example if they user wants to run rpm from 
+	       sysadm_r.  Sudo will exec the /usr/sbin/sesh followed by the 
+	       specified command.*/
+	    char **dst, **src = NewArgv+1;
+	    NewArgv = (char **) emalloc2((++NewArgc + 1), sizeof(char *));
+	    NewArgv[0] = estrdup("/usr/sbin/sesh");
+	    NewArgv[1] = safe_cmnd;
+	    safe_cmnd = estrdup("/usr/sbin/sesh");
+	    /* copy the args from Argv */
+	    for (dst = NewArgv + 2; (*dst = *src) != NULL; ++src, ++dst)
+	      ;
+	  }
+	}
+#endif
+	EXECV(safe_cmnd, NewArgv);	/* run the command */
 #else
 	exit(0);
 #endif /* PROFILING */
@@ -734,6 +924,30 @@
 		NewArgv++;
 		break;
 #endif
+#ifdef WITH_SELINUX
+	    case 'r':
+		/* Must have an associated SELinux role. */
+		if (NewArgv[1] == NULL)
+		    usage(1);
+
+		role_s = NewArgv[1];
+
+		/* Shift Argv over and adjust Argc. */
+		NewArgc--;
+		NewArgv++;
+		break;
+	    case 't':
+		/* Must have an associated SELinux type. */
+		if (NewArgv[1] == NULL)
+		    usage(1);
+
+		type_s = NewArgv[1];
+
+		/* Shift Argv over and adjust Argc. */
+		NewArgc--;
+		NewArgv++;
+		break;
+#endif
 #ifdef HAVE_LOGIN_CAP_H
 	    case 'c':
 		/* Must have an associated login class. */
@@ -1119,6 +1333,9 @@
 #ifdef HAVE_BSD_AUTH_H
 	" [-a auth_type]",
 #endif
+#ifdef WITH_SELINUX
+	" [-r role] [-t type] ",
+#endif
 #ifdef HAVE_LOGIN_CAP_H
 	" [-c class|-]",
 #endif
--- sudo-1.6.8p8/configure.selinux	2004-11-26 21:04:30.000000000 +0100
+++ sudo-1.6.8p8/configure	2005-04-12 12:53:01.000000000 +0200
@@ -1608,7 +1608,7 @@
 insults=off
 root_sudo=on
 INSTALL_NOEXEC=
-PROGS="sudo visudo"
+PROGS="sudo visudo sesh"
 test -n "$MANTYPE" || MANTYPE="man"
 test -n "$mansrcdir" || mansrcdir="."
 test -n "$SUDOERS_MODE" || SUDOERS_MODE=0440
--- sudo-1.6.8p8/configure.in.selinux	2004-11-25 18:31:20.000000000 +0100
+++ sudo-1.6.8p8/configure.in	2005-04-12 12:53:01.000000000 +0200
@@ -98,7 +98,7 @@
 dnl Initial values for Makefile variables listed above
 dnl May be overridden by environment variables..
 dnl
-PROGS="sudo visudo"
+PROGS="sudo visudo sesh"
 test -n "$MANTYPE" || MANTYPE="man"
 test -n "$mansrcdir" || mansrcdir="."
 test -n "$SUDOERS_MODE" || SUDOERS_MODE=0440
--- sudo-1.6.8p8/sudo.man.in.selinux	2005-03-11 20:11:31.000000000 +0100
+++ sudo-1.6.8p8/sudo.man.in	2005-04-12 12:53:01.000000000 +0200
@@ -157,6 +157,7 @@
 \&\fBsudo\fR \fB\-K\fR | \fB\-L\fR | \fB\-V\fR | \fB\-h\fR | \fB\-k\fR | \fB\-l\fR | \fB\-v\fR
 .PP
 \&\fBsudo\fR [\fB\-HPSb\fR] [\fB\-a\fR\ \fIauth_type\fR] [\fB\-c\fR\ \fIclass\fR|\fI\-\fR]
+[\fB\-r\fR \fIrole\fR ] [\fB\-t\fR \fItype\fR ]
 [\fB\-p\fR\ \fIprompt\fR] [\fB\-u\fR\ \fIusername\fR|\fI#uid\fR]
 {\fB\-e\fR\ file\ [...]\ |\ \fB\-i\fR\ |\ \fB\-s\fR\ |\ \fIcommand\fR}
 .PP
@@ -235,6 +236,16 @@
 \&\fBsudo\fR will initialize the group vector to the list of groups the
 target user is in.  The real and effective group IDs, however, are
 still set to match the target user.
+.IP "\-r" 4
+.IX Item "-r"
+The \fB\-r\fR (\fRrole\fR) option causes the new (SELinux) security context to have the role specified by
+\fIROLE\fR.
+.IP "\-t" 4
+.IX Item "-t" 
+The \fB\-t\fR (\fRtype\fR) option causes the new (SELinux) security context to have the have the type (domain)
+specified by
+\fITYPE\fR.
+If no type is specified, the default type is derived from the specified role.
 .IP "\-S" 4
 .IX Item "-S"
 The \fB\-S\fR (\fIstdin\fR) option causes \fBsudo\fR to read the password from
--- sudo-1.6.8p8/Makefile.in.selinux	2005-03-11 20:08:52.000000000 +0100
+++ sudo-1.6.8p8/Makefile.in	2005-04-12 12:53:01.000000000 +0200
@@ -43,7 +43,8 @@
 # Libraries
 LIBS = @LIBS@
 NET_LIBS = @NET_LIBS@
-SUDO_LIBS = @SUDO_LIBS@ @AFS_LIBS@ $(LIBS) $(NET_LIBS)
+SELINUX_LIBS = -lselinux 
+SUDO_LIBS = @SUDO_LIBS@ @AFS_LIBS@ $(LIBS) $(NET_LIBS) $(SELINUX_LIBS)
 
 # C preprocessor flags
 CPPFLAGS = -I. -I$(srcdir) @CPPFLAGS@
@@ -90,7 +91,7 @@
 sudoers_mode = @SUDOERS_MODE@
 
 # Pass in paths and uid/gid + OS dependent defined
-DEFS = @OSDEFS@ -D_PATH_SUDOERS=\"$(sudoersdir)/sudoers\" -D_PATH_SUDOERS_TMP=\"$(sudoersdir)/sudoers.tmp\" -DSUDOERS_UID=$(sudoers_uid) -DSUDOERS_GID=$(sudoers_gid) -DSUDOERS_MODE=$(sudoers_mode)
+DEFS = @OSDEFS@ -D_PATH_SUDOERS=\"$(sudoersdir)/sudoers\" -D_PATH_SUDOERS_TMP=\"$(sudoersdir)/sudoers.tmp\" -DSUDOERS_UID=$(sudoers_uid) -DSUDOERS_GID=$(sudoers_gid) -DSUDOERS_MODE=$(sudoers_mode) -DWITH_SELINUX
 
 #### End of system configuration section. ####
 
@@ -104,7 +105,7 @@
        parse.c parse.lex parse.yacc set_perms.c sigaction.c snprintf.c \
        strcasecmp.c strerror.c strlcat.c strlcpy.c sudo.c sudo_noexec.c \
        sudo.tab.c sudo_edit.c testsudoers.c tgetpass.c utimes.c visudo.c \
-       zero_bytes.c $(AUTH_SRCS)
+       zero_bytes.c $(AUTH_SRCS) sesh.c
 
 AUTH_SRCS = auth/afs.c auth/aix_auth.c auth/bsdauth.c auth/dce.c auth/fwtk.c \
 	    auth/kerb4.c auth/kerb5.c auth/pam.c auth/passwd.c auth/rfc1938.c \
@@ -126,6 +127,8 @@
 
 VISUDOBJS = visudo.o fileops.o gettime.o goodpath.o find_path.o $(PARSEOBJS)
 
+SESH_OBJS = sesh.o
+
 TESTOBJS = interfaces.o testsudoers.o $(PARSEOBJS)
 
 LIBOBJS = @LIBOBJS@ @ALLOCA@
@@ -145,7 +148,7 @@
 BINFILES= BUGS CHANGES HISTORY LICENSE README TODO TROUBLESHOOTING \
 	  UPGRADE install-sh mkinstalldirs sample.syslog.conf sample.sudoers \
 	  sudo sudo.cat sudo.man sudo.pod sudoers sudoers.cat sudoers.man \
-	  sudoers.pod visudo visudo.cat visudo.man visudo.pod
+	  sudoers.pod visudo visudo.cat visudo.man visudo.pod sesh
 
 BINSPECIAL= INSTALL.binary Makefile.binary libtool
 
@@ -177,6 +180,9 @@
 visudo: $(VISUDOBJS) $(LIBOBJS)
 	$(CC) -o $@ $(VISUDOBJS) $(LIBOBJS) $(LDFLAGS) $(LIBS) $(NET_LIBS)
 
+sesh: $(SESH_OBJS) 
+	$(CC) -o $@ $(SESH_OBJS) $(LDFLAGS) $(LIBS)
+
 testsudoers: $(TESTOBJS) $(LIBOBJS)
 	$(CC) -o $@ $(TESTOBJS) $(LIBOBJS) $(LDFLAGS) $(LIBS) $(NET_LIBS)
 
@@ -215,6 +221,7 @@
 set_perms.o: set_perms.c $(SUDODEP)
 tgetpass.o: tgetpass.c $(SUDODEP)
 visudo.o: visudo.c $(SUDODEP) version.h
+sesh.o: sesh.c 
 sudo.o: sudo.c $(SUDODEP) interfaces.h version.h
 interfaces.o: interfaces.c $(SUDODEP) interfaces.h
 testsudoers.o: testsudoers.c $(SUDODEP) parse.h interfaces.h
@@ -306,6 +313,7 @@
 	ln $(DESTDIR)$(sudodir)/sudo $(DESTDIR)$(sudodir)/sudoedit
 
 	$(INSTALL) -O $(install_uid) -G $(install_gid) -M 0111 -s visudo $(DESTDIR)$(visudodir)/visudo
+	$(INSTALL) -O $(install_uid) -G $(install_gid) -M 0111 -s sesh $(DESTDIR)$(visudodir)/sesh
 
 install-noexec: sudo_noexec.la
 	$(LIBTOOL) --mode=install $(INSTALL) sudo_noexec.la $(DESTDIR)$(noexecdir)

[-- Attachment #3: sudo-1.6.8p8-selinux.patch.sig --]
[-- Type: application/octet-stream, Size: 72 bytes --]

Resend: Sudo Changes for SELinux

[Daniel J Walsh]

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

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

Here is an update selinux patch for sudo potentially for rawhide.  I
have updated selinux policy to work with it.  A lot of it was copied
from newrole.

So now you can execute
# grep dwalsh /etc/sudoers
dwalsh	ALL=(ALL) 	ALL

$ id -Z
staff_u:staff_r:staff_t:s0
# sudo -r unconfined_r -t unconfined_t id -Z
staff_u:unconfined_r:unconfined_t:s0
# sudo -r webadm_r -t webadm_t id -Z
staff_u:webadm_r:webadm_t:s0

$ sudo -r unconfined_r -t unconfined_t sh
# /usr/sbin/semanage user -l | grep staff_u
staff_u         staff      s0         s0-s0:c0.c1023
system_r sysadm_r staff_r unconfined_r webadm_r

$ sudo -r webadm_r -t webadm_t sh
# /sbin/service httpd start
Starting httpd:                                            [  OK  ]
# ps -eZ | grep http
staff_u:system_r:httpd_t:s0     11870 ?        00:00:00 httpd
staff_u:system_r:httpd_t:s0     11872 ?        00:00:00 httpd
staff_u:system_r:httpd_t:s0     11874 ?        00:00:00 httpd
staff_u:system_r:httpd_t:s0     11875 ?        00:00:00 httpd
staff_u:system_r:httpd_t:s0     11876 ?        00:00:00 httpd
staff_u:system_r:httpd_t:s0     11877 ?        00:00:00 httpd
staff_u:system_r:httpd_t:s0     11878 ?        00:00:00 httpd
staff_u:system_r:httpd_t:s0     11879 ?        00:00:00 httpd
staff_u:system_r:httpd_t:s0     11880 ?        00:00:00 httpd

# /sbin/service ntp start
ntp: unrecognized service

# touch /dan.html
touch: cannot touch `/dan.html': Permission denied
# touch /var/www/html/dan.html
# ls
# ls -lZ /var/www/html/dan.html
- -rw-r--r--+ root root staff_u:object_r:httpd_sys_content_t:s0
/var/www/html/dan.html

With this patch and the correct selinux policy(rawhide), I can do
everything I want with sudo, for RBAC controls.  The problem is the
administrator needs to know the correct commands to enter to select the
correct roles.  I would rather put this in the sudoers file.  So what
would be the correct context to say when dwalsh runs any app the shell
he starts is running webadm_r:webadm_t?

One controversial part of the sudo patch is the addition of a new shell
/usr/sbin/sesh.  This shell is only to make sure all transitions happen
properly.  So the role/type selected apply to a shell and not to the
command entered on the sudo line.  This prevents the admin from
executing sudo -r webadm_r -t webadm_t rpm -i ...
And rpm running as webadm_t instead of doing a transition to rpm_t.
(if webadm_t has a transition to rpm_t).  We could force this to always
use /bin/bash but there could be problems there.  And not all shells
work the same way, so potentially using the login shell could cause
problems.


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

iEYEARECAAYFAkegj0MACgkQrlYvE4MpobM7XACgg1uIbEGvNaTSNzpGYEw04kMN
lIIAnjpjW3I5UtSs9HfyKdyucDCgSApT
=8aRF
-----END PGP SIGNATURE-----

[-- Attachment #2: sudo-1.6.9p4-selinux.patch --]
[-- Type: text/plain, Size: 19514 bytes --]

diff -up sudo-1.6.9p4/configure.in.selinux sudo-1.6.9p4/configure.in
--- sudo-1.6.9p4/configure.in.selinux	2008-01-29 15:25:02.000000000 -0500
+++ sudo-1.6.9p4/configure.in	2008-01-29 15:25:02.000000000 -0500
@@ -101,7 +101,7 @@ dnl
 dnl Initial values for Makefile variables listed above
 dnl May be overridden by environment variables..
 dnl
-PROGS="sudo visudo"
+PROGS="sudo visudo sesh"
 : ${MANTYPE='man'}
 : ${mansrcdir='.'}
 : ${SUDOERS_MODE='0440'}
diff -up /dev/null sudo-1.6.9p4/selinux.c
--- /dev/null	2008-01-29 07:07:11.771655674 -0500
+++ sudo-1.6.9p4/selinux.c	2008-01-29 15:34:17.000000000 -0500
@@ -0,0 +1,425 @@
+/*
+ * Copyright (c) 2008 Dan Walsh <dwalsh@redhat.com>
+ *
+ * Borrowed heavily from newrole source code
+ * Authors:
+ *      Anthony Colatrella
+ *	Tim Fraser
+ *	Steve Grubb <sgrubb@redhat.com>
+ *	Darrel Goeddel <DGoeddel@trustedcs.com>
+ *	Michael Thompson <mcthomps@us.ibm.com>
+ *	Dan Walsh <dwalsh@redhat.com>
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ *
+ */
+#ifdef WITH_SELINUX
+#include <config.h>
+#include <sys/types.h>
+#include <stdio.h>
+#ifdef STDC_HEADERS
+# include <stdlib.h>
+# include <stddef.h>
+#else
+# ifdef HAVE_STDLIB_H
+#  include <stdlib.h>
+# endif
+#endif /* STDC_HEADERS */
+#ifdef HAVE_STRING_H
+# if defined(HAVE_MEMORY_H) && !defined(STDC_HEADERS)
+#  include <memory.h>
+# endif
+# include <string.h>
+#else
+# ifdef HAVE_STRINGS_H
+#  include <strings.h>
+# endif
+#endif /* HAVE_STRING_H */
+#ifdef HAVE_UNISTD_H
+# include <unistd.h>
+#endif /* HAVE_UNISTD_H */
+#include <errno.h>
+#include <fcntl.h>
+#include <signal.h>
+
+#ifdef WITH_AUDIT
+#include <libaudit.h>
+#endif
+
+#include "sudo.h"
+
+#include <sys/wait.h>
+
+#ifdef USE_AUDIT
+#include <libaudit.h>
+#endif
+
+#include <selinux/flask.h>             /* for SECCLASS_CHR_FILE */
+#include <selinux/selinux.h>           /* for is_selinux_enabled() */
+#include <selinux/context.h>           /* for context-mangling functions */
+#include <selinux/get_default_type.h>
+#include <selinux/get_context_list.h>
+
+/**
+ * This function attempts to revert the relabeling done to the tty.
+ * fd   - referencing the opened ttyn
+ * ttyn - name of tty to restore
+ * tty_context     - original context of the tty
+ * new_tty_context - context tty was relabeled to
+ *
+ * Returns zero on success, non-zero otherwise
+ */
+static int restore_tty_label(int fd, const char *ttyn,
+			     security_context_t tty_context,
+			     security_context_t new_tty_context)
+{
+	int rc = 0;
+	security_context_t chk_tty_context = NULL;
+
+	if (!ttyn)
+		goto skip_relabel;
+
+	if (!new_tty_context)
+		goto skip_relabel;
+
+	/* Verify that the tty still has the context set by newrole. */
+	if ((rc = fgetfilecon(fd, &chk_tty_context)) < 0) {
+		fprintf(stderr, "Could not fgetfilecon %s.\n", ttyn);
+		goto skip_relabel;
+	}
+
+	if ((rc = strcmp(chk_tty_context, new_tty_context))) {
+		fprintf(stderr, "%s changed labels.\n", ttyn);
+		goto skip_relabel;
+	}
+
+	if ((rc = fsetfilecon(fd, tty_context)) < 0)
+		fprintf(stderr,
+			"Warning! Could not restore context for %s\n", ttyn);
+      skip_relabel:
+	freecon(chk_tty_context);
+	return rc;
+}
+
+/**
+ * This function attempts to relabel the tty. If this function fails, then
+ * the fd is closed, the contexts are free'd and -1 is returned. On success,
+ * a valid fd is returned and tty_context and new_tty_context are set.
+ *
+ * This function will not fail if it can not relabel the tty when selinux is
+ * in permissive mode.
+ */
+static int relabel_tty(const char *ttyn, security_context_t new_context,
+		       security_context_t * tty_context,
+		       security_context_t * new_tty_context)
+{
+	int fd;
+	int enforcing = security_getenforce();
+	security_context_t tty_con = NULL;
+	security_context_t new_tty_con = NULL;
+
+	if (!ttyn)
+		return 0;
+
+	if (enforcing < 0) {
+		fprintf(stderr, "Could not determine enforcing mode.\n");
+		return -1;
+	}
+
+	/* Re-open TTY descriptor */
+	fd = open(ttyn, O_RDWR | O_NONBLOCK);
+	if (fd < 0) {
+		fprintf(stderr, "Error!  Could not open %s.\n", ttyn);
+		return fd;
+	}
+	fcntl(fd, F_SETFL, fcntl(fd, F_GETFL, 0) & ~O_NONBLOCK);
+
+	if (fgetfilecon(fd, &tty_con) < 0) {
+		fprintf(stderr, "%s!  Could not get current context "
+				  "for %s, not relabeling tty.\n",
+			enforcing ? "Error" : "Warning", ttyn);
+		if (enforcing)
+			goto close_fd;
+	}
+
+	if (tty_con &&
+	    (security_compute_relabel(new_context, tty_con,
+				      SECCLASS_CHR_FILE, &new_tty_con) < 0)) {
+		fprintf(stderr, "%s!  Could not get new context for %s, "
+				  "not relabeling tty.\n",
+			enforcing ? "Error" : "Warning", ttyn);
+		if (enforcing)
+			goto close_fd;
+	}
+
+	if (new_tty_con)
+		if (fsetfilecon(fd, new_tty_con) < 0) {
+			fprintf(stderr,
+				"%s!  Could not set new context for %s\n",
+				enforcing ? "Error" : "Warning", ttyn);
+			freecon(new_tty_con);
+			new_tty_con = NULL;
+			if (enforcing)
+				goto close_fd;
+		}
+
+	*tty_context = tty_con;
+	*new_tty_context = new_tty_con;
+	return fd;
+
+      close_fd:
+	freecon(tty_con);
+	close(fd);
+	return -1;
+}
+
+security_context_t get_exec_context(security_context_t old_context, char *role_s, char *type_s) {
+
+  /* our target security ID ("sid") */
+  security_context_t new_context=NULL; 
+
+  /* manipulatable form of context_s */
+  context_t context;                 
+  
+  if( !role_s ) {
+    fprintf(stderr,"You must specify a role.\n");
+    return NULL;
+  }
+	  
+  
+  /*
+   * Get the SID and context of the caller, and extract
+   * the username from the context.  Don't rely on the Linux
+   * uid information - it isn't trustworthy.
+   */
+  
+  /* 
+   * Create a context structure so that we extract and modify 
+   * components easily. 
+   */
+  context=context_new(old_context);
+  
+  /*
+   *
+   * Step 3:  Construct a new SID based on our old SID and the
+   *          arguments specified on the command line.
+   *
+   */
+  
+  /* The first step in constructing a new SID for the new shell we  *
+   * plan to exec is to take our old context in `context' as a   *
+   * starting point, and modify it according to the options the user *
+   * specified on the command line.                                  */
+
+  /* If the user specified a new role on the command line (if `role_s'   *
+   * is set), then replace the old role in `context' with this new role. */
+  if( !type_s ) {
+    if( get_default_type(role_s,&type_s) )
+      {
+        fprintf(stderr,"Couldn't get default type.\n");
+	goto err;
+      }
+    }
+    
+  if( context_role_set(context,role_s)) {
+    fprintf(stderr,"failed to set new role %s\n",role_s);
+    goto err;
+  }
+    
+  /* If the user specified a new type on the command line (if `type_s'   *
+   * is set), then replace the old type in `context' with this new type. */
+  if( type_s ) {
+    if( context_type_set(context,type_s)) {
+      fprintf(stderr,"failed to set new type %s\n",type_s);
+      goto err;
+    }
+  } /* if user specified new type */
+    
+  /* The second step in creating the new SID is to convert our modified *
+   * `context' structure back to a context string and then to a SID.    */
+    
+  /* Make `context_s' point to a string version of the new `context'.  */
+  if( !(new_context=strdup(context_str(context)))) {
+    fprintf(stderr,"failed to convert new context to string\n" );
+    goto err;
+  }
+
+  if (security_check_context(new_context) < 0) {
+    fprintf(stderr, "%s is not a valid context\n", new_context);
+    goto err;
+  }
+
+#ifdef DEBUG
+  printf("Your new context is %s\n",new_context);
+#endif
+
+  context_free(context);
+  return new_context;
+
+ err:
+  context_free(context);
+  freecon(new_context);
+  return NULL;
+
+}
+
+void selinux_exec(char *role_s, char *type_s, char *safe_cmd, int NewArgc, char **NewArgv, char **environ){ 
+  pid_t childPid = 0;
+  int ttyfd = -1;
+  /* our original securiy ID ("old_context") */
+  security_context_t old_context=NULL;	
+
+  /* security context to change to while running command*/
+  security_context_t new_tty_context=NULL; 
+  /* current security context of tty */
+  security_context_t tty_context=NULL;  
+
+  char *ttyn = NULL;	/* tty path */
+  
+  /* our target security ID ("sid") */
+  security_context_t new_context=NULL;
+  /* Put the caller's SID into `old_context'. */
+  if (getprevcon(&old_context)) {
+    fprintf(stderr,"failed to get old_context.\n");
+    exit(-1);
+  }
+  
+#ifdef DEBUG
+  printf( "Your old context was %s\n", old_context );
+#endif
+  new_context=get_exec_context(old_context, role_s,type_s);
+  if (! new_context) {
+	  fprintf(stderr, "Could not set exec context to %s.\n", new_context);
+	  exit(-1);
+  }
+  
+  ttyn = ttyname(STDIN_FILENO);
+  if (!ttyn || *ttyn == '\0') {
+	  fprintf(stderr,
+		  "Warning!  Could not retrieve tty information.\n");
+  }
+  
+  ttyfd = relabel_tty(ttyn, new_context, &tty_context, &new_tty_context);
+  if (ttyfd < 0) {
+	  fprintf(stderr, "Could not setup tty context for %s.\n", new_context);
+	  exit(-1);
+  }
+
+#ifdef DEBUG
+  printf("Your old tty context is %s\n",tty_context);
+  printf("Your new tty context is %s\n",new_tty_context);
+#endif
+
+
+  childPid = fork();
+  if (childPid < 0) {
+	  /* fork failed, no child to worry about */
+	  int errsv = errno;
+	  fprintf(stderr, "newrole: failure forking: %s",
+		  strerror(errsv));
+	  if (restore_tty_label(ttyfd, ttyn, tty_context, new_tty_context))
+		  fprintf(stderr, "Unable to restore tty label...\n");
+	  if (close(ttyfd))
+		  fprintf(stderr, "Failed to close tty properly\n");
+	  goto err;
+  } else if (childPid) {
+	  /* PARENT
+	   * It doesn't make senes to exit early on errors at this point,
+	   * since we are doing cleanup which needs to be done.
+	   * We can exit with a bad rc though
+	   */
+	  pid_t pid;
+	  int exit_code = 0;
+	  int status;
+	  
+	  do {
+		  pid = wait(&status);
+	  } while (pid < 0 && errno == EINTR);
+	  
+	  /* Preserve child exit status, unless there is another error. */
+	  if (WIFEXITED(status))
+		  exit_code = WEXITSTATUS(status);
+	  
+	  if (restore_tty_label(ttyfd, ttyn, tty_context, new_tty_context)) {
+		  fprintf(stderr, "Unable to restore tty label...\n");
+		  exit_code = -1;
+	  }
+	  freecon(tty_context);
+	  freecon(new_tty_context);
+	  if (close(ttyfd)) {
+		  fprintf(stderr, "Failed to close tty properly\n");
+		  exit_code = -1;
+	  }
+	  exit(exit_code);
+  }
+  /* CHILD */
+  /* Close the tty and reopen descriptors 0 through 2 */
+  if (ttyn) {
+    if (close(ttyfd) || close(0) || close(1) || close(2)) {
+	    fprintf(stderr, "Could not close descriptors.\n");
+	    goto err;
+    }
+    ttyfd = open(ttyn, O_RDONLY | O_NONBLOCK);
+    if (ttyfd != 0)
+	    goto err;
+    fcntl(ttyfd, F_SETFL, fcntl(ttyfd, F_GETFL, 0) & ~O_NONBLOCK);
+    ttyfd = open(ttyn, O_RDWR | O_NONBLOCK);
+    if (ttyfd != 1)
+	    goto err;
+    fcntl(ttyfd, F_SETFL, fcntl(ttyfd, F_GETFL, 0) & ~O_NONBLOCK);
+    ttyfd = open(ttyn, O_RDWR | O_NONBLOCK);
+    if (ttyfd != 2)
+	    goto err;
+    fcntl(ttyfd, F_SETFL, fcntl(ttyfd, F_GETFL, 0) & ~O_NONBLOCK);
+  }
+  if (setexeccon(new_context)) {
+	  fprintf(stderr, "Could not set exec context to %s.\n",
+		  new_context);
+	  goto err;
+  }
+
+#ifdef USE_AUDIT
+  if (send_audit_message(1, old_context, new_context, ttyn)) 
+    goto err;
+#endif
+
+  {
+    /* 
+       SELinux will only not transition properly with the following
+       code.  Basically if the user chooses to use a different security
+       context.  We need to start the selinux shell, before executing 
+       the command.  This way the process transition will happen 
+       correctly. For example if they user wants to run rpm from 
+       sysadm_r.  Sudo will exec the /usr/sbin/sesh followed by the 
+       specified command.*/
+     char **dst, **src = NewArgv+1;
+     NewArgv = (char **) emalloc2((++NewArgc + 1), sizeof(char *));
+     NewArgv[0] = estrdup("/usr/sbin/sesh");
+     NewArgv[1] = safe_cmd;
+     safe_cmd = estrdup("/usr/sbin/sesh");
+     /* copy the args from Argv */
+     for (dst = NewArgv + 2; (*dst = *src) != NULL; ++src, ++dst)
+	     ;
+  }
+  freecon(old_context);
+  freecon(new_context);
+
+  execve(safe_cmd, NewArgv, environ);	/* run the command */
+  
+  perror("failed to exec shell\n");
+ err:
+  freecon(old_context);
+  freecon(new_context);
+  exit(-1);
+}
+#endif /* WITH_SELINUX */
diff -up /dev/null sudo-1.6.9p4/sesh.c
--- /dev/null	2008-01-29 07:07:11.771655674 -0500
+++ sudo-1.6.9p4/sesh.c	2008-01-29 15:25:02.000000000 -0500
@@ -0,0 +1,46 @@
+#include <stdio.h>
+#include <unistd.h>
+#include <limits.h>
+#include <sys/types.h>
+#include <sys/wait.h>
+#include <errno.h>
+
+main (int argc, char **argv) {
+  char buf[PATH_MAX];
+  pid_t pid;
+  if ( argc < 2 ) {
+    fprintf(stderr,"%s: Requires at least one argument\n", argv[0]);
+    exit(-1);
+  }
+
+  if ((pid = fork()) < 0) {
+    snprintf(buf, sizeof(buf), "%s: Couldn't fork",argv[0]);
+    perror(buf);
+    exit(-1);
+  } else if (pid > 0) {
+    /* Parent */
+    int status;
+    int ret;
+
+    do {
+      if ((ret = waitpid(pid, &status, 0)) < 0 && errno == EINTR)
+        continue;
+      else if (ret < 0) {
+        perror("waitpid failed");
+        exit(1);
+      }
+    } while (0);
+
+    if (WIFEXITED(status))
+      exit(WEXITSTATUS(status));
+    else
+      exit(1);
+  } else {
+    /* Child */
+    execv(argv[1], &argv[1]);
+
+    snprintf(buf, sizeof(buf), "%s: Error execing %s", argv[0], argv[1]);
+    perror(buf);
+    exit(-1);
+  }
+}
diff -up sudo-1.6.9p4/sudo.man.in.selinux sudo-1.6.9p4/sudo.man.in
--- sudo-1.6.9p4/sudo.man.in.selinux	2007-08-15 10:16:58.000000000 -0400
+++ sudo-1.6.9p4/sudo.man.in	2008-01-29 15:25:02.000000000 -0500
@@ -159,6 +159,7 @@ sudo, sudoedit \- execute a command as a
 .PP
 \&\fBsudo\fR [\fB\-bEHPS\fR] [\fB\-a\fR\ \fIauth_type\fR]
 [\fB\-c\fR\ \fIclass\fR|\fI\-\fR] [\fB\-p\fR\ \fIprompt\fR] [\fB\-u\fR\ \fIusername\fR|\fI#uid\fR]
+[\fB\-r\fR \fIrole\fR ] [\fB\-t\fR \fItype\fR ]
 [\fB\s-1VAR\s0\fR=\fIvalue\fR] {\fB\-i\fR\ |\ \fB\-s\fR\ |\ \fIcommand\fR}
 .PP
 \&\fBsudoedit\fR [\fB\-S\fR] [\fB\-a\fR\ \fIauth_type\fR] [\fB\-c\fR\ \fIclass\fR|\fI\-\fR]
@@ -323,6 +324,16 @@ preserve the invoking user's group vecto
 \&\fBsudo\fR will initialize the group vector to the list of groups the
 target user is in.  The real and effective group IDs, however, are
 still set to match the target user.
+.IP "\-r" 4
+.IX Item "-r"
+The \fB\-r\fR (\fRrole\fR) option causes the new (SELinux) security context to have the role specified by
+\fIROLE\fR.
+.IP "\-t" 4
+.IX Item "-t" 
+The \fB\-t\fR (\fRtype\fR) option causes the new (SELinux) security context to have the have the type (domain)
+specified by
+\fITYPE\fR.
+If no type is specified, the default type is derived from the specified role.
 .IP "\-p" 4
 .IX Item "-p"
 The \fB\-p\fR (\fIprompt\fR) option allows you to override the default
diff -up sudo-1.6.9p4/Makefile.in.selinux sudo-1.6.9p4/Makefile.in
--- sudo-1.6.9p4/Makefile.in.selinux	2008-01-29 15:25:02.000000000 -0500
+++ sudo-1.6.9p4/Makefile.in	2008-01-29 15:25:02.000000000 -0500
@@ -43,7 +43,8 @@ INSTALL = $(SHELL) $(srcdir)/install-sh 
 # Libraries
 LIBS = @LIBS@
 NET_LIBS = @NET_LIBS@
-SUDO_LIBS = @SUDO_LIBS@ @AFS_LIBS@ $(LIBS) $(NET_LIBS)
+SELINUX_LIBS = -lselinux 
+SUDO_LIBS = @SUDO_LIBS@ @AFS_LIBS@ $(LIBS) $(NET_LIBS) $(SELINUX_LIBS)
 
 # C preprocessor flags
 CPPFLAGS = -I. -I$(srcdir) @CPPFLAGS@
@@ -90,7 +91,7 @@ sudoers_gid = @SUDOERS_GID@
 sudoers_mode = @SUDOERS_MODE@
 
 # Pass in paths and uid/gid + OS dependent defined
-DEFS = @OSDEFS@ -D_PATH_SUDOERS=\"$(sudoersdir)/sudoers\" -D_PATH_SUDOERS_TMP=\"$(sudoersdir)/sudoers.tmp\" -DSUDOERS_UID=$(sudoers_uid) -DSUDOERS_GID=$(sudoers_gid) -DSUDOERS_MODE=$(sudoers_mode)
+DEFS = @OSDEFS@ -D_PATH_SUDOERS=\"$(sudoersdir)/sudoers\" -D_PATH_SUDOERS_TMP=\"$(sudoersdir)/sudoers.tmp\" -DSUDOERS_UID=$(sudoers_uid) -DSUDOERS_GID=$(sudoers_gid) -DSUDOERS_MODE=$(sudoers_mode) -DWITH_SELINUX
 
 #### End of system configuration section. ####
 
@@ -104,7 +105,7 @@ SRCS = alloc.c alloca.c check.c closefro
        logging.c memrchr.c mkstemp.c parse.c parse.lex parse.yacc set_perms.c \
        sigaction.c snprintf.c strcasecmp.c strerror.c strlcat.c strlcpy.c \
        sudo.c sudo_noexec.c sudo.tab.c sudo_edit.c testsudoers.c tgetpass.c \
-       utimes.c visudo.c zero_bytes.c $(AUTH_SRCS)
+       utimes.c visudo.c zero_bytes.c $(AUTH_SRCS) selinux.c sesh.c
 
 AUTH_SRCS = auth/afs.c auth/aix_auth.c auth/bsdauth.c auth/dce.c auth/fwtk.c \
 	    auth/kerb4.c auth/kerb5.c auth/pam.c auth/passwd.c auth/rfc1938.c \
@@ -123,11 +124,13 @@ AUDIT_OBJS = audit_help.o 
 PARSEOBJS = sudo.tab.o lex.yy.o alloc.o defaults.o
 
 SUDOBJS = check.o env.o getspwuid.o gettime.o goodpath.o fileops.o find_path.o \
-	  interfaces.o logging.o parse.o set_perms.o sudo.o sudo_edit.o \
+	  interfaces.o logging.o parse.o set_perms.o sudo.o selinux.o sudo_edit.o \
 	  tgetpass.o zero_bytes.o @SUDO_OBJS@ $(AUTH_OBJS) $(PARSEOBJS) $(AUDIT_OBJS)
 
 VISUDOBJS = visudo.o fileops.o gettime.o goodpath.o find_path.o $(PARSEOBJS)
 
+SESH_OBJS = sesh.o
+
 TESTOBJS = interfaces.o testsudoers.o $(PARSEOBJS)
 
 LIBOBJS = @LIBOBJS@ @ALLOCA@
@@ -148,7 +151,7 @@ DISTFILES = $(SRCS) $(HDRS) BUGS CHANGES
 BINFILES= BUGS CHANGES HISTORY LICENSE README TODO TROUBLESHOOTING \
 	  UPGRADE install-sh mkinstalldirs sample.syslog.conf sample.sudoers \
 	  sudo sudo.cat sudo.man sudo.pod sudoers sudoers.cat sudoers.man \
-	  sudoers.pod visudo visudo.cat visudo.man visudo.pod
+	  sudoers.pod visudo visudo.cat visudo.man visudo.pod sesh
 
 BINSPECIAL= INSTALL.binary Makefile.binary libtool
 
@@ -180,6 +183,9 @@ sudo: $(SUDOBJS) $(LIBOBJS)
 visudo: $(VISUDOBJS) $(LIBOBJS)
 	$(CC) -o $@ $(VISUDOBJS) $(LIBOBJS) $(LDFLAGS) $(LIBS) $(NET_LIBS)
 
+sesh: $(SESH_OBJS) 
+	$(CC) -o $@ $(SESH_OBJS) $(LDFLAGS) $(LIBS)
+
 testsudoers: $(TESTOBJS) $(LIBOBJS)
 	$(CC) -o $@ $(TESTOBJS) $(LIBOBJS) $(LDFLAGS) $(LIBS) $(NET_LIBS)
 
@@ -221,6 +227,7 @@ logging.o: logging.c $(SUDODEP)
 set_perms.o: set_perms.c $(SUDODEP)
 tgetpass.o: tgetpass.c $(SUDODEP)
 visudo.o: visudo.c $(SUDODEP) version.h
+sesh.o: sesh.c 
 sudo.o: sudo.c $(SUDODEP) interfaces.h version.h
 interfaces.o: interfaces.c $(SUDODEP) interfaces.h
 testsudoers.o: testsudoers.c $(SUDODEP) parse.h interfaces.h
@@ -319,6 +326,7 @@ install-binaries: $(PROGS)
 	ln $(DESTDIR)$(sudodir)/sudo $(DESTDIR)$(sudodir)/sudoedit
 
 	$(INSTALL) -O $(install_uid) -G $(install_gid) -M 0111 -s visudo $(DESTDIR)$(visudodir)/visudo
+	$(INSTALL) -O $(install_uid) -G $(install_gid) -M 0111 -s sesh $(DESTDIR)$(visudodir)/sesh
 
 install-noexec: sudo_noexec.la
 	$(LIBTOOL) --mode=install $(INSTALL) sudo_noexec.la $(DESTDIR)$(noexecdir)

[-- Attachment #3: sudo-1.6.9p4-selinux.patch.sig --]
[-- Type: application/octet-stream, Size: 72 bytes --]

Re: Accurately setting Security Context of a user when ssh-ing in

[Dave Quigley]

On Wed, 2008-01-30 at 19:35 -0500, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> What file or info in the policy determines what security context a user
> will get after ssh-ing in...?
> 
> In other words, If I have a Linux_user = Admin, which is mapped to
> SELinux_user = staff_u , SELinux_role = staff_r, how do I guarantee that
> when I ssh in as "Admin", I will ALWAYS get the security_context =
> staff_u:staff_r:staff_t 
> 
> 
> The reason I ask is as follows:
> 
> I have developed a certain collection of *strict* policies on a Fedora
> machine that achieve what I want. 
> When I ssh into this Fedora machine as "Admin", I do get the context =
> staff_u:staff_r:staff_t
> 
> So I tar up everything in the  /etc/selinux/  directory, and create a
> selinux_policies.tar  lets say.
> 
> Now, I untar selinux_policies.tar onto *another* machine (Machine B)!
> 
> Then when I ssh into Machine B, with Linux account "Admin", I get
> security_context = sysadm_u:sysadm_r:sysadm_t  ?!?
> 
> Weird thing is, If I reset Machine B, and *then*  ssh in as "Admin", I
> then get the correct security_context = staff_u:staff_r:staff_t.
> 
> So after untarring the collection of policies (the entire
> /etc/selinux/***  directory):
>    1. when I ssh in as Admin, I always get the wrong security_context
>    2. But if I reset the machine, and after machine comes up, if I then
> ssh in as Admin, I get the correct security_context.
>    3. subsequent resets, and ssh-ing in still gives me the correct
> security_context...
> 
> A. So why am I getting the wrong security_context after untarring
> /etc/selinux/***  onto a target machine B.
> B. And why is resetting the machine fixing this problem ?
> 
> Hopefully the question was not too confusing  ;-)
> 
> Thanks in advance for any help.
>     
> 
> 
> --
> 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.

The reason that you are not getting the correct user and role
information until you reboot is that the system is still using the old
policy at that point. Even though you have untarred the new policies in
place it still has the old one loaded into the kernel. You can try
executing load_policy after you have untarred it to reload the policy.
One thing to check on is that all the files under /etc/selinux are
labeled properly. I am not sure if tar is going to retain the file
labeling or not so if it doesn't you will probably have to either
restorecon the directory or relabel the filesystem on reboot.

Dave


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

Accurately setting Security Context of a user when ssh-ing in

[Hasan Rezaul-CHR010]

Hi All,

What file or info in the policy determines what security context a user
will get after ssh-ing in...?

In other words, If I have a Linux_user = Admin, which is mapped to
SELinux_user = staff_u , SELinux_role = staff_r, how do I guarantee that
when I ssh in as "Admin", I will ALWAYS get the security_context =
staff_u:staff_r:staff_t 


The reason I ask is as follows:

I have developed a certain collection of *strict* policies on a Fedora
machine that achieve what I want. 
When I ssh into this Fedora machine as "Admin", I do get the context =
staff_u:staff_r:staff_t

So I tar up everything in the  /etc/selinux/  directory, and create a
selinux_policies.tar  lets say.

Now, I untar selinux_policies.tar onto *another* machine (Machine B)!

Then when I ssh into Machine B, with Linux account "Admin", I get
security_context = sysadm_u:sysadm_r:sysadm_t  ?!?

Weird thing is, If I reset Machine B, and *then*  ssh in as "Admin", I
then get the correct security_context = staff_u:staff_r:staff_t.

So after untarring the collection of policies (the entire
/etc/selinux/***  directory):
   1. when I ssh in as Admin, I always get the wrong security_context
   2. But if I reset the machine, and after machine comes up, if I then
ssh in as Admin, I get the correct security_context.
   3. subsequent resets, and ssh-ing in still gives me the correct
security_context...

A. So why am I getting the wrong security_context after untarring
/etc/selinux/***  onto a target machine B.
B. And why is resetting the machine fixing this problem ?

Hopefully the question was not too confusing  ;-)

Thanks in advance for any help.
    


--
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: Accurately setting Security Context of a user when ssh-ing in

[Hasan Rezaul-CHR010]

Hi Dave,

I forgot to mention that, after doing the un-tarring of the policy
collection, I did run the restorecon command:

restorecon -rF /
restorecon -rF /etc/

And I did try running    /usr/sbin/load_policy

... If I ssh in as Admin, I still get the wrong user context of
staff_u:sysadm_r:sysadm_t:s0    :-(

But if I reboot the machine, and then ssh in as Admin, I get the correct
user context of  staff_u:staff_r:staff_t  !!

Is there any other hidden thing that the reboot does that helps in
setting the user contexts correctly ?

Thanks again for all the help...


-----Original Message-----
From: Dave Quigley [mailto:dpquigl@tycho.nsa.gov] 
Sent: Wednesday, January 30, 2008 6:31 PM
To: Hasan Rezaul-CHR010
Cc: Stephen Smalley; SE Linux
Subject: Re: Accurately setting Security Context of a user when ssh-ing
in


On Wed, 2008-01-30 at 19:35 -0500, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> What file or info in the policy determines what security context a
user
> will get after ssh-ing in...?
> 
> In other words, If I have a Linux_user = Admin, which is mapped to
> SELinux_user = staff_u , SELinux_role = staff_r, how do I guarantee
that
> when I ssh in as "Admin", I will ALWAYS get the security_context =
> staff_u:staff_r:staff_t 
> 
> 
> The reason I ask is as follows:
> 
> I have developed a certain collection of *strict* policies on a Fedora
> machine that achieve what I want. 
> When I ssh into this Fedora machine as "Admin", I do get the context =
> staff_u:staff_r:staff_t
> 
> So I tar up everything in the  /etc/selinux/  directory, and create a
> selinux_policies.tar  lets say.
> 
> Now, I untar selinux_policies.tar onto *another* machine (Machine B)!
> 
> Then when I ssh into Machine B, with Linux account "Admin", I get
> security_context = sysadm_u:sysadm_r:sysadm_t  ?!?
> 
> Weird thing is, If I reset Machine B, and *then*  ssh in as "Admin", I
> then get the correct security_context = staff_u:staff_r:staff_t.
> 
> So after untarring the collection of policies (the entire
> /etc/selinux/***  directory):
>    1. when I ssh in as Admin, I always get the wrong security_context
>    2. But if I reset the machine, and after machine comes up, if I
then
> ssh in as Admin, I get the correct security_context.
>    3. subsequent resets, and ssh-ing in still gives me the correct
> security_context...
> 
> A. So why am I getting the wrong security_context after untarring
> /etc/selinux/***  onto a target machine B.
> B. And why is resetting the machine fixing this problem ?
> 
> Hopefully the question was not too confusing  ;-)
> 
> Thanks in advance for any help.
>     
> 
> 
> --
> 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.

The reason that you are not getting the correct user and role
information until you reboot is that the system is still using the old
policy at that point. Even though you have untarred the new policies in
place it still has the old one loaded into the kernel. You can try
executing load_policy after you have untarred it to reload the policy.
One thing to check on is that all the files under /etc/selinux are
labeled properly. I am not sure if tar is going to retain the file
labeling or not so if it doesn't you will probably have to either
restorecon the directory or relabel the filesystem on reboot.

Dave



--
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: Accurately setting Security Context of a user when ssh-ing in

[Stephen Smalley]

On Mon, 2008-02-04 at 19:44 -0500, Hasan Rezaul-CHR010 wrote:
> Hi Dave,
> 
> I forgot to mention that, after doing the un-tarring of the policy
> collection, I did run the restorecon command:
> 
> restorecon -rF /
> restorecon -rF /etc/
> 
> And I did try running    /usr/sbin/load_policy
> 
> ... If I ssh in as Admin, I still get the wrong user context of
> staff_u:sysadm_r:sysadm_t:s0    :-(
> 
> But if I reboot the machine, and then ssh in as Admin, I get the correct
> user context of  staff_u:staff_r:staff_t  !!
> 
> Is there any other hidden thing that the reboot does that helps in
> setting the user contexts correctly ?
> 
> Thanks again for all the help...

The logic for computing the login context for users is based on the
context of the caller (e.g. the context in which the login process runs)
as well as the authorized contexts for the user.  For example, policy
might allow a user to login at the console (local_login_t) as sysadm_r
while preventing him from logging in directly into sysadm_r when logging
in via ssh (sshd_t).

Thus, if you merely untar the directory, reload policy, and relabel,
your existing processes may still be running in the wrong contexts, and
this can affect the context computed for login.  A reboot ensures that
everything transitions properly as defined by policy.

-- 
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: Resend: Sudo Changes for SELinux

[Todd Miller]

Is there any reason sesh needs to fork()?  If all you need is an
exec-time transition isn't it sufficient to just call exec()?

 - todd


--
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: Resend: Sudo Changes for SELinux

[Daniel J Walsh]

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

Todd Miller wrote:
> Is there any reason sesh needs to fork()?  If all you need is an
> exec-time transition isn't it sufficient to just call exec()?
> 
>  - todd
I don't recall, I wrote it several years ago.  I guess the simplest
thing is to try it out, without the fork.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkep0joACgkQrlYvE4MpobMkOwCffK19DmANMR/+Uy+XCXIFiyzF
j6gAn1uUUrN3mq+R6MFYeeBwL/RzGlJR
=IFrp
-----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: Accurately setting Security Context of a user when ssh-ing in

[Hasan Rezaul-CHR010]

Understood  :-)

Ques: At the end of the day when we reboot, and the machine comes back
up, its basically running a whole bunch of scripts and commands. So isnt
there some command(s) that I can manually run without doing an actual
reboot, to achieve what the reboot would otherwise do ?

Lets just say I cant afford to do a reboot, due to downtime/availability
restrictions. I have a certain collection of policies on a machine. I
need to be able to replace policy with a new set of policies with
minimal downtime. Hence, I cant afford a reboot. Is there any way
whatsoever I can run commands/scripts manually to avoid the reboot ?

By the way, what file should I play with to control what context a user
gets when login at the console VS the context a user should get after
ssh-ing in ?

Thanks as always.

-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Tuesday, February 05, 2008 7:02 AM
To: Hasan Rezaul-CHR010
Cc: Dave Quigley; SE Linux
Subject: RE: Accurately setting Security Context of a user when ssh-ing
in


On Mon, 2008-02-04 at 19:44 -0500, Hasan Rezaul-CHR010 wrote:
> Hi Dave,
> 
> I forgot to mention that, after doing the un-tarring of the policy
> collection, I did run the restorecon command:
> 
> restorecon -rF /
> restorecon -rF /etc/
> 
> And I did try running    /usr/sbin/load_policy
> 
> ... If I ssh in as Admin, I still get the wrong user context of
> staff_u:sysadm_r:sysadm_t:s0    :-(
> 
> But if I reboot the machine, and then ssh in as Admin, I get the
correct
> user context of  staff_u:staff_r:staff_t  !!
> 
> Is there any other hidden thing that the reboot does that helps in
> setting the user contexts correctly ?
> 
> Thanks again for all the help...

The logic for computing the login context for users is based on the
context of the caller (e.g. the context in which the login process runs)
as well as the authorized contexts for the user.  For example, policy
might allow a user to login at the console (local_login_t) as sysadm_r
while preventing him from logging in directly into sysadm_r when logging
in via ssh (sshd_t).

Thus, if you merely untar the directory, reload policy, and relabel,
your existing processes may still be running in the wrong contexts, and
this can affect the context computed for login.  A reboot ensures that
everything transitions properly as defined by policy.


-- 
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: Accurately setting Security Context of a user when ssh-ing in

[Stephen Smalley]

On Wed, 2008-02-06 at 23:13 -0500, Hasan Rezaul-CHR010 wrote:
> Understood  :-)
> 
> Ques: At the end of the day when we reboot, and the machine comes back
> up, its basically running a whole bunch of scripts and commands. So isnt
> there some command(s) that I can manually run without doing an actual
> reboot, to achieve what the reboot would otherwise do ?

Depends how disruptive the change in your policy is.  For common policy
changes, you don't have to reboot at all - just reload policy and
relabel any files whose labels have changed under the new policy.  You
only have to restart processes when the change in policy would lead to
the process running in a different context, and then you have to
identify and restart all processes that are running under the wrong
context.  That would just use the conventional mechanisms for restarting
the affected processes, e.g. /sbin/service sshd restart, telinit, etc.
If you are dropping in an extremely different policy or when you first
go from no-policy to a policy, then you may need to restart everything
from /sbin/init downward to get them into the right security contexts.

> Lets just say I cant afford to do a reboot, due to downtime/availability
> restrictions. I have a certain collection of policies on a machine. I
> need to be able to replace policy with a new set of policies with
> minimal downtime. Hence, I cant afford a reboot. Is there any way
> whatsoever I can run commands/scripts manually to avoid the reboot ?

Depends on the nature of the change in policy, as above.  BTW, while you
can do wholesale replacement of the entire policy tree, modular/managed
policy is oriented to letting you make selective changes via semodule
and semanage on the end system instead.  However, you still need to
relabel files whose types have changed and you still need to restart
processes that you want to run in a different context in either case.

> By the way, what file should I play with to control what context a user
> gets when login at the console VS the context a user should get after
> ssh-ing in ?

/etc/selinux/$SELINUXTYPE/contexts/default_contexts
and/or /etc/selinux/$SELINUXTYPE/contexts/users/$SEUSER.

-- 
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: Resend: Sudo Changes for SELinux

[Todd Miller]

Daniel J Walsh wrote:
> I don't recall, I wrote it several years ago.  I guess the simplest
> thing is to try it out, without the fork.

Seems to work fine without the fork.  I've made quite a few changes and
you can now specify sudoers lines like:

tmiller ALL=(ALL) ROLE=sysadm_r TYPE=sysadmin_t /bin/sh

and have it do what (I think) you want.  Note that "make install" does
not currently set the label on sesh, perhaps it should.  I'm also not
sure that /usr/sbin is the best place for sesh.  My inclination would be
to put it in /usr/libexec, though this is not a big deal.

 - todd


--
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: Resend: Sudo Changes for SELinux

[Daniel J Walsh]

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

Todd Miller wrote:
> Daniel J Walsh wrote:
>> I don't recall, I wrote it several years ago.  I guess the simplest
>> thing is to try it out, without the fork.
> 
> Seems to work fine without the fork.  I've made quite a few changes and
> you can now specify sudoers lines like:
> 
> tmiller ALL=(ALL) ROLE=sysadm_r TYPE=sysadmin_t /bin/sh
> 
> and have it do what (I think) you want.  Note that "make install" does
> not currently set the label on sesh, perhaps it should.  I'm also not
> sure that /usr/sbin is the best place for sesh.  My inclination would be
> to put it in /usr/libexec, though this is not a big deal.
> 
>  - todd
You are the boss.  Move it to /usr/libexec.  And I will fix policy to
label it correctly.  I would not put SELinux awareness into the install,
that is either "install", rpm. dpkg problem.

I look forward to testing it out.  And once it is in Rawhide, will blog
about how to use it with SELinux.


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

iEYEARECAAYFAkerPeQACgkQrlYvE4MpobM0dgCgsVNlzSmComL5m39JExgG0cjj
Z3gAoJ1GydVEoFvHUf4CNvgjNhZNoygg
=grpX
-----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: Resend: Sudo Changes for SELinux

[Todd Miller]

Daniel J Walsh wrote:
> You are the boss.  Move it to /usr/libexec.  And I will fix policy to
> label it correctly.  I would not put SELinux awareness into the
> install, that is either "install", rpm. dpkg problem.

OK, I changed the path and updated the tarball.  Glad I don't have to
worry about the label.

 - todd


--
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: Accurately setting Security Context of a user when ssh-ing in

[Hasan Rezaul-CHR010]

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

Hi Stephen,

Here are the outputs of the commands you asked for...

Before restarting sshd, while the problem is exhibited:
------------------------------------------------------------------------
------

root@hapWibbSc2:/> cat /selinux/booleans/ssh_sysadm_login 
0 0

root@hapWibbSc2:/> grep ssh
/etc/selinux/strict/contexts/default_contexts 
system_r:sshd_t:s0              user_r:user_t:s0 staff_r:staff_t:s0
sysadm_r:sysadm_t:s0


root@hapWibbSc2:/> ps -eZ | grep sshd
system_u:system_r:kernel_t:s0    1095 ?        00:00:00 sshd 



And after restarting sshd from the console, where I am
root:sysadm_r:sysadm_t:s0
------------------------------------------------------------------------
--------------------------------------------------

root@hapWibbSc2:/> cat /selinux/booleans/ssh_sysadm_login 
0 0

root@hapWibbSc2:/> grep ssh
/etc/selinux/strict/contexts/default_contexts 
system_r:sshd_t:s0              user_r:user_t:s0 staff_r:staff_t:s0
sysadm_r:sysadm_t:s0

root@hapWibbSc2:/> ps -eZ | grep sshd
root:system_r:sshd_t:s0          4819 ?        00:00:00 sshd


Just in case, under the  /etc/selinux/strict/contexts/users/ directory,
I only have one file called "root", and that contains:
------------------------------------------------------------------------
------------------------------------------------------------------------
---------------------------
system_r:local_login_t:s0  sysadm_r:sysadm_t:s0 staff_r:staff_t:s0
user_r:user_t:s0
system_r:crond_t:s0     sysadm_r:sysadm_crond_t:s0
staff_r:staff_crond_t:s0 user_r:user_crond_t:s0
staff_r:staff_su_t:s0   sysadm_r:sysadm_t:s0 staff_r:staff_t:s0
user_r:user_t:s0
sysadm_r:sysadm_su_t:s0 sysadm_r:sysadm_t:s0 staff_r:staff_t:s0
user_r:user_t:s0
user_r:user_su_t:s0     sysadm_r:sysadm_t:s0 staff_r:staff_t:s0
user_r:user_t:s0
#
# Uncomment if you want to automatically login as sysadm_r
#
#system_r:sshd_t:s0 sysadm_r:sysadm_t:s0 staff_r:staff_t:s0
user_r:user_t:s0


*** So given this info, we can see that in the problematic case, context
of sshd is   system_u:system_r:kernel_t:s0,  but restarting sshd on the
console, we get  root:system_r:sshd_t:s0. And after this, everything
works nicely...

So how can I programmatically (e.g. through a script) get sshd to start
in the right context, or force sshd to change context to sshd_t ?

Thanks again for all your help as always  :-)

- Reza.


-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Tuesday, February 12, 2008 12:58 PM
To: Hasan Rezaul-CHR010
Cc: Dave Quigley
Subject: RE: Accurately setting Security Context of a user when ssh-ing
in


On Tue, 2008-02-12 at 12:53 -0500, Hasan Rezaul-CHR010 wrote:
> Here is the full story... Apologize for dragging this on...

any reason you didn't cc the list?

> I have SELinux running on a Linux Card.
> The Card is partitioned into 2 halves! One half (the active side)
> running software and a set of SELinux policies already. 
> And another half, the inactive side, which is usually empty.
> 
> I have a software upgrade procedure, where software is first
downloaded
> and populated on the 2nd half (/inactive/ side), and then the card is
> rebooted to come up on the newly populated side. This way software
> upgrade is done with minimal downtime.
> 
> As part of the software_upgrade procedure, I place new software, and a
> collection of SELinux policies on the inactive side.
>    So basically I populate everything under the
> /inactive/etc/selinux/***  
>    as well as create and mount the selinuxfs  at  /inactive/selinux
> 
> After the /inactive  side is appropriately populated with new software
> and new policies, 'sidesel' is modified,
> and the Linux card is REBOOTED !
> 
> The card then starts coming up on the new side, kernel recognizes new
> SELinux policies, and loads the new policy !
> By the way, I removed the /.autorelabel  file, because I didn't want
> kernel to reboot the Card again !?!
> 
> So I have an init script that runs during bootup, and the script does
> "restorecon -rF /"
> 
> So after this point, when the Card is fully up, the card is running
with
> new SELinux policies, and filesystem labeled appropriately!
> 
> My login mappings at this time are defined as follows:
> 
> root@hapWibbSc2:/etc> semanage login -l
> 
> Login Name                SELinux User              MLS/MCS Range
> 
> 
> __default__               user_u                    s0
> 
> Admin                     staff_u                   s0
> 
> root                      root                      s0-s0:c0.c1023
> 
> system_u                  system_u                  s0-s0:c0.c1023

> 
> 
> At this time: 
> 
> 1. If I login as root on the console, I expect, and I do get,
> root:sysadm_r:sysadm_t:s0
> 2. If I ssh in as Admin, I expect to get   staff_u:staff_r:staff_t,
but
> instead, I get  staff_u:sysadm_r:sysadm_t  !!

What do the following commands show?
# getsebool ssh_sysadm_login
# grep ssh /etc/selinux/$SELINUXTYPE/contexts/default_contexts

> 3. Also If I ssh in as a regular user, like Reza, I should get
> user_u:user_r:user_t,  but I get   system_u:system_r:system_t  !!

Strange. 

> As you suggested in your previous mail(s), perhaps the sshd process
> wasn't started under the right contexts ???

Yep, what does ps -eZ | grep sshd show?

> So, here is the interesting part:
> 
> - While I am logged in as root on the console, and my context is
> root:sysadm_r:sysadm_t,  if I type  /sbin/service sshd restart,
>   and then try to ssh in as Admin or Reza, after that, I do get the
> correct contexts, and everything is golden :-) 

And what does ps -eZ | grep sshd show now?

> - OR another thing that works is: while I am logged in as root on the
> console (as sysadm), I execute a script that has 'service sshd
restart'
> in it. This also fixes the problem
> 
> BUT, I need to find an automatic/programmatic way to do this, because
> the software_upgrade procedure must be automatic ! It cant involve
> someone manually logging in to do something on the console.
> 
> - So in my init script that runs during bootup, where I relabel the
> filesystem, after relabelling, I put  /sbin/service sshd restart
>   but after that script ran, I still have this problem  :-(   That's
> probably because the init script is being run as "system" during
bootup,
> whereas when I manually typed on the console, I am "sysadm".
> 
> - I tried many different things, e.g. ssh-ing in as Admin or Reza,
then
> su - root, and then restarting sshd, but nothing works !!!
>   The only thing that resolves this problem, is executing  "service
sshd
> restart" at the console, where my context is root:sysadm_r:sysadm_t.
> 
> - Of course, the other thing that works, is rebooting the Card a
second
> time, which I cant afford, due to availability requirements.
> 
> 
> Do you have any suggestions of how I can restart the sshd process
> programmatically (e.g. through my init script), to achieve the same
> results as running the 'service sshd restart' manually on the console
?
> Is there a way my init script could temporarily assume sysadm, or a
way
> that my init script can be run as sysadm during bootup ?

Well, you can always force it into a certain context via runcon (if
permitted by your policy).  But I'd rather fix the real problem, and
that requires knowing what context sshd is running in initially and then
what context is it running in after the restart from the console.

> Thanks again for all your help...

-- 
Stephen Smalley
National Security Agency


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

RE: Accurately setting Security Context of a user when ssh-ing in

[Stephen Smalley]

On Tue, 2008-02-12 at 18:01 -0500, Hasan Rezaul-CHR010 wrote:
> Hi Stephen,
> 
> Here are the outputs of the commands you asked for...
> 
> Before restarting sshd, while the problem is exhibited: 
> ------------------------------------------------------------------------------
> 
> root@hapWibbSc2:/> cat /selinux/booleans/ssh_sysadm_login 
> 0 0
> 
> root@hapWibbSc2:/> grep
> ssh /etc/selinux/strict/contexts/default_contexts 
> system_r:sshd_t:s0              user_r:user_t:s0 staff_r:staff_t:s0
> sysadm_r:sysadm_t:s0
> 
> 
> root@hapWibbSc2:/> ps -eZ | grep sshd 
> system_u:system_r:kernel_t:s0    1095 ?        00:00:00 sshd

So here sshd never transitioned into its domain, likely because the
filesystem wasn't labeled at the time /sbin/init started.

> 
> 
> And after restarting sshd from the console, where I am
> root:sysadm_r:sysadm_t:s0 
> --------------------------------------------------------------------------------------------------------------------------
> 
> root@hapWibbSc2:/> cat /selinux/booleans/ssh_sysadm_login 
> 0 0
> 
> root@hapWibbSc2:/> grep
> ssh /etc/selinux/strict/contexts/default_contexts 
> system_r:sshd_t:s0              user_r:user_t:s0 staff_r:staff_t:s0
> sysadm_r:sysadm_t:s0
> 
> root@hapWibbSc2:/> ps -eZ | grep sshd 
> root:system_r:sshd_t:s0          4819 ?        00:00:00 sshd

And here it is running in the correct context, or close enough (ideally
it would be system_u).  If you restarted it with
run_init /etc/init.d/sshd restart, then that should happen.

> Just in case, under the  /etc/selinux/strict/contexts/users/
> directory, I only have one file called "root", and that contains:
> 
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> system_r:local_login_t:s0  sysadm_r:sysadm_t:s0 staff_r:staff_t:s0
> user_r:user_t:s0 
> system_r:crond_t:s0     sysadm_r:sysadm_crond_t:s0
> staff_r:staff_crond_t:s0 user_r:user_crond_t:s0 
> staff_r:staff_su_t:s0   sysadm_r:sysadm_t:s0 staff_r:staff_t:s0
> user_r:user_t:s0 
> sysadm_r:sysadm_su_t:s0 sysadm_r:sysadm_t:s0 staff_r:staff_t:s0
> user_r:user_t:s0 
> user_r:user_su_t:s0     sysadm_r:sysadm_t:s0 staff_r:staff_t:s0
> user_r:user_t:s0 
> # 
> # Uncomment if you want to automatically login as sysadm_r 
> # 
> #system_r:sshd_t:s0 sysadm_r:sysadm_t:s0 staff_r:staff_t:s0
> user_r:user_t:s0
> 
> 
> *** So given this info, we can see that in the problematic case,
> context of sshd is   system_u:system_r:kernel_t:s0,  but restarting
> sshd on the console, we get  root:system_r:sshd_t:s0. And after this,
> everything works nicely...
> 
> So how can I programmatically (e.g. through a script) get sshd to
> start in the right context, or force sshd to change context to
> sshd_t ?
> 
> Thanks again for all your help as always  :-)

Well, I suspect that not only sshd but all of your system processes are
running in the wrong domain because init never transitioned out of
kernel_t into init_t.

Ideally you'd label the filesystem before you perform that first boot of
the new system image.  Should be possible to do, modulo differences
between the file types defined by the old and new policies.  If you can
at least get most of the files labeled, then init will transition
properly and the daemons will follow course.

-- 
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: Accurately setting Security Context of a user when ssh-ing in

[Hasan Rezaul-CHR010]

Hi Stephen,

As part of my software_upgrade procedure, after populating the new
policies and selinuxfs on the  /inactive side, I did  "touch
/inactive/.autorelabel"

Then reboot my Linux Card. So now when the Card was booting up from the
new side...

kernel detected new policies, 
loaded new policies, 
kernel also detected the .autorelabel file
So it invoked automatic "Re-Label" of the filesystem
Kernel then FORCED another Automatic REBOOT
And then the Card booted up all the way.

Now when I do  "ps -eZ | grep sshd",  I get  
 
root@hapWibbSc2:/root> ps -eZ | grep sshd
system_u:system_r:init_t:s0      3971 ?        00:00:00 sshd


So this way, we've made sure that the filesystem was labeled correctly,
before the init processes were started!
You mentioned that ideally, this is the sequence we want, correct ???

*BUT*, how even after re-labeling the filesystem, and starting sshd, the
context became =  system_u:system_r:init_t  ??

Now when I ssh in as "Admin", or "Reza"  I still get the wrong context !
:-(


Things actually seem to work properly when the sshd process is running
in context =   root:system_r:sshd_t:s0

In my normal setup, I DON'T create an  /.autorelabel file, and I do the
re-labeling manually via a script using restorecon. The problem with
that approach is that, init processes like 'sshd' already get started in
the wrong context  BEFORE my script gets a chance to run.

But if I restart sshd from the console, my ssh headaches get resolved.
So how can I restart ssh in the correct context  (system_r:sshd_t)  via
a script? You mentioned something about the "runcon" command...  Can I
use 'runcon' in my script to restart sshd and force sshd to run it in
the correct context ??

You're right that other init processes may be running in the wrong
context/domain as well, but they're not bothering me as much. But I need
to at least get around this ssh problem...  Any suggestions ?... Thanks,


- Reza.


-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Wednesday, February 13, 2008 8:38 AM
To: Hasan Rezaul-CHR010
Cc: Dave Quigley; selinux
Subject: RE: Accurately setting Security Context of a user when ssh-ing
in


On Tue, 2008-02-12 at 18:01 -0500, Hasan Rezaul-CHR010 wrote:
> Hi Stephen,
> 
> Here are the outputs of the commands you asked for...
> 
> Before restarting sshd, while the problem is exhibited: 
>
------------------------------------------------------------------------
------
> 
> root@hapWibbSc2:/> cat /selinux/booleans/ssh_sysadm_login 
> 0 0
> 
> root@hapWibbSc2:/> grep
> ssh /etc/selinux/strict/contexts/default_contexts 
> system_r:sshd_t:s0              user_r:user_t:s0 staff_r:staff_t:s0
> sysadm_r:sysadm_t:s0
> 
> 
> root@hapWibbSc2:/> ps -eZ | grep sshd 
> system_u:system_r:kernel_t:s0    1095 ?        00:00:00 sshd

So here sshd never transitioned into its domain, likely because the
filesystem wasn't labeled at the time /sbin/init started.

> 
> 
> And after restarting sshd from the console, where I am
> root:sysadm_r:sysadm_t:s0 
>
------------------------------------------------------------------------
--------------------------------------------------
> 
> root@hapWibbSc2:/> cat /selinux/booleans/ssh_sysadm_login 
> 0 0
> 
> root@hapWibbSc2:/> grep
> ssh /etc/selinux/strict/contexts/default_contexts 
> system_r:sshd_t:s0              user_r:user_t:s0 staff_r:staff_t:s0
> sysadm_r:sysadm_t:s0
> 
> root@hapWibbSc2:/> ps -eZ | grep sshd 
> root:system_r:sshd_t:s0          4819 ?        00:00:00 sshd

And here it is running in the correct context, or close enough (ideally
it would be system_u).  If you restarted it with
run_init /etc/init.d/sshd restart, then that should happen.

> Just in case, under the  /etc/selinux/strict/contexts/users/
> directory, I only have one file called "root", and that contains:
> 
>
------------------------------------------------------------------------
------------------------------------------------------------------------
---------------------------
> 
> system_r:local_login_t:s0  sysadm_r:sysadm_t:s0 staff_r:staff_t:s0
> user_r:user_t:s0 
> system_r:crond_t:s0     sysadm_r:sysadm_crond_t:s0
> staff_r:staff_crond_t:s0 user_r:user_crond_t:s0 
> staff_r:staff_su_t:s0   sysadm_r:sysadm_t:s0 staff_r:staff_t:s0
> user_r:user_t:s0 
> sysadm_r:sysadm_su_t:s0 sysadm_r:sysadm_t:s0 staff_r:staff_t:s0
> user_r:user_t:s0 
> user_r:user_su_t:s0     sysadm_r:sysadm_t:s0 staff_r:staff_t:s0
> user_r:user_t:s0 
> # 
> # Uncomment if you want to automatically login as sysadm_r 
> # 
> #system_r:sshd_t:s0 sysadm_r:sysadm_t:s0 staff_r:staff_t:s0
> user_r:user_t:s0
> 
> 
> *** So given this info, we can see that in the problematic case,
> context of sshd is   system_u:system_r:kernel_t:s0,  but restarting
> sshd on the console, we get  root:system_r:sshd_t:s0. And after this,
> everything works nicely...
> 
> So how can I programmatically (e.g. through a script) get sshd to
> start in the right context, or force sshd to change context to
> sshd_t ?
> 
> Thanks again for all your help as always  :-)

Well, I suspect that not only sshd but all of your system processes are
running in the wrong domain because init never transitioned out of
kernel_t into init_t.

Ideally you'd label the filesystem before you perform that first boot of
the new system image.  Should be possible to do, modulo differences
between the file types defined by the old and new policies.  If you can
at least get most of the files labeled, then init will transition
properly and the daemons will follow course.

-- 
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: Accurately setting Security Context of a user when ssh-ing in

[Stephen Smalley]

On Wed, 2008-02-13 at 15:02 -0500, Hasan Rezaul-CHR010 wrote:
> Hi Stephen,
> 
> As part of my software_upgrade procedure, after populating the new
> policies and selinuxfs on the  /inactive side, I did  "touch
> /inactive/.autorelabel"
> 
> Then reboot my Linux Card. So now when the Card was booting up from the
> new side...
> 
> kernel detected new policies, 
> loaded new policies, 
> kernel also detected the .autorelabel file

kernel doesn't do that - it is handled by /etc/rc.sysinit (at least in
Fedora).

> So it invoked automatic "Re-Label" of the filesystem
> Kernel then FORCED another Automatic REBOOT
> And then the Card booted up all the way.
> 
> Now when I do  "ps -eZ | grep sshd",  I get  
>  
> root@hapWibbSc2:/root> ps -eZ | grep sshd
> system_u:system_r:init_t:s0      3971 ?        00:00:00 sshd

Ok, normally, /sbin/init runs in init_t, then it transitions to initrc_t
upon executing the /etc/rc.d/ and /etc/init.d scripts, and then initrc_t
transitions to sshd_t upon executing /usr/sbin/sshd.

So now your problem is that you aren't transitioning to initrc_t.
What's the label on /etc/rc.d and /etc/init.d, i.e. ls
-Z /etc/rc.d /etc/init.d?

If init directly invokes sshd in your setup, then you need a type
transition rule added for it since that isn't the usual case.

> So this way, we've made sure that the filesystem was labeled correctly,
> before the init processes were started!
> You mentioned that ideally, this is the sequence we want, correct ???

Yes.  You could also label the /inactive tree _before_ booting from it
if the file types haven't changed from the old policy, ala:
# setfiles -r /inactive /inactive/etc/selinux/$SELINUXTYPE/contexts/file_contexts /inactive
 
The -r option tells setfiles to use an alternate root path, for labeling a separate
tree like this.

> *BUT*, how even after re-labeling the filesystem, and starting sshd, the
> context became =  system_u:system_r:init_t  ??

Apparently it isn't transitioning out of init_t into initrc_t before
reaching sshd.

> Now when I ssh in as "Admin", or "Reza"  I still get the wrong context !
> :-(
> 
> 
> Things actually seem to work properly when the sshd process is running
> in context =   root:system_r:sshd_t:s0
> 
> In my normal setup, I DON'T create an  /.autorelabel file, and I do the
> re-labeling manually via a script using restorecon. The problem with
> that approach is that, init processes like 'sshd' already get started in
> the wrong context  BEFORE my script gets a chance to run.
> 
> But if I restart sshd from the console, my ssh headaches get resolved.
> So how can I restart ssh in the correct context  (system_r:sshd_t)  via
> a script? You mentioned something about the "runcon" command...  Can I
> use 'runcon' in my script to restart sshd and force sshd to run it in
> the correct context ??
> 
> You're right that other init processes may be running in the wrong
> context/domain as well, but they're not bothering me as much. But I need
> to at least get around this ssh problem...  Any suggestions ?... Thanks,

You can use runcon (if permitted by policy), but I think we can fix this
w/o doing that.

-- 
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: Accurately setting Security Context of a user when ssh-ing in

[Stephen Smalley]

On Wed, 2008-02-13 at 15:23 -0500, Stephen Smalley wrote:
> On Wed, 2008-02-13 at 15:02 -0500, Hasan Rezaul-CHR010 wrote:
> > Hi Stephen,
> > 
> > As part of my software_upgrade procedure, after populating the new
> > policies and selinuxfs on the  /inactive side, I did  "touch
> > /inactive/.autorelabel"
> > 
> > Then reboot my Linux Card. So now when the Card was booting up from the
> > new side...
> > 
> > kernel detected new policies, 
> > loaded new policies, 
> > kernel also detected the .autorelabel file
> 
> kernel doesn't do that - it is handled by /etc/rc.sysinit (at least in
> Fedora).
> 
> > So it invoked automatic "Re-Label" of the filesystem
> > Kernel then FORCED another Automatic REBOOT
> > And then the Card booted up all the way.
> > 
> > Now when I do  "ps -eZ | grep sshd",  I get  
> >  
> > root@hapWibbSc2:/root> ps -eZ | grep sshd
> > system_u:system_r:init_t:s0      3971 ?        00:00:00 sshd
> 
> Ok, normally, /sbin/init runs in init_t, then it transitions to initrc_t
> upon executing the /etc/rc.d/ and /etc/init.d scripts, and then initrc_t
> transitions to sshd_t upon executing /usr/sbin/sshd.
> 
> So now your problem is that you aren't transitioning to initrc_t.
> What's the label on /etc/rc.d and /etc/init.d, i.e. ls
> -Z /etc/rc.d /etc/init.d?
> 
> If init directly invokes sshd in your setup, then you need a type
> transition rule added for it since that isn't the usual case.
> 
> > So this way, we've made sure that the filesystem was labeled correctly,
> > before the init processes were started!
> > You mentioned that ideally, this is the sequence we want, correct ???
> 
> Yes.  You could also label the /inactive tree _before_ booting from it
> if the file types haven't changed from the old policy, ala:
> # setfiles -r /inactive /inactive/etc/selinux/$SELINUXTYPE/contexts/file_contexts /inactive
>  
> The -r option tells setfiles to use an alternate root path, for labeling a separate
> tree like this.

Just to follow up for the list - Hasan tried the above approach of using
setfiles -r to label the /inactive tree before rebooting, and that
solved his problem.

Also, just to note for others:  the above presumes that the new
file_contexts configuration doesn't include any new file types not
defined by the running policy.  To support a change where new file types
are introduced, you'd have to first load the new policy before running
setfiles, ala:
#	chroot /inactive load_policy
#	setfiles -r /inactive /inactive/etc/selinux/$SELINUXTYPE/contexts/file_contexts /inactive

And that will only work if the policies are reasonably compatible with one another.
For a major change in policy (e.g. targeted -> strict, non-mls -> mls), you'd likely
need to go for the full reboot + relabel sequence instead.

> 
> > *BUT*, how even after re-labeling the filesystem, and starting sshd, the
> > context became =  system_u:system_r:init_t  ??
> 
> Apparently it isn't transitioning out of init_t into initrc_t before
> reaching sshd.
> 
> > Now when I ssh in as "Admin", or "Reza"  I still get the wrong context !
> > :-(
> > 
> > 
> > Things actually seem to work properly when the sshd process is running
> > in context =   root:system_r:sshd_t:s0
> > 
> > In my normal setup, I DON'T create an  /.autorelabel file, and I do the
> > re-labeling manually via a script using restorecon. The problem with
> > that approach is that, init processes like 'sshd' already get started in
> > the wrong context  BEFORE my script gets a chance to run.
> > 
> > But if I restart sshd from the console, my ssh headaches get resolved.
> > So how can I restart ssh in the correct context  (system_r:sshd_t)  via
> > a script? You mentioned something about the "runcon" command...  Can I
> > use 'runcon' in my script to restart sshd and force sshd to run it in
> > the correct context ??
> > 
> > You're right that other init processes may be running in the wrong
> > context/domain as well, but they're not bothering me as much. But I need
> > to at least get around this ssh problem...  Any suggestions ?... Thanks,
> 
> You can use runcon (if permitted by policy), but I think we can fix this
> w/o doing that.
> 
-- 
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: Resend: Sudo Changes for SELinux

[Daniel J Walsh]

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

Todd Miller wrote:
> Daniel J Walsh wrote:
>> You are the boss.  Move it to /usr/libexec.  And I will fix policy to
>> label it correctly.  I would not put SELinux awareness into the
>> install, that is either "install", rpm. dpkg problem.
> 
> OK, I changed the path and updated the tarball.  Glad I don't have to
> worry about the label.
> 
>  - todd
There seems to be a bug. When I exit the shell it is not setting my tty
back.

In permissive mode.

$ ls -lZ `tty`
crw--w----  dwalsh tty staff_u:object_r:staff_devpts_t:s0 /dev/pts/2
 sudo sh
# ls -lZ `tty`
crw--w----  dwalsh tty staff_u:object_r:unconfined_devpts_t:s0 /dev/pts/2
# exit
$ ls -lZ `tty`
crw--w----  dwalsh tty staff_u:object_r:unconfined_devpts_t:s0 /dev/pts/2

In enforcing mode it kills the shell  :^(

I have it setup as staff_t and unconfined_t for root.


Other than this it looks greate.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAke7MkAACgkQrlYvE4MpobMX3ACfa/DoyI4J9NaJDsm93fX7ptZk
Ya4AnifwZsH8iLGjAhYF2n7Aaf+As0Xo
=NQhj
-----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.