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