On 01/28/2010 03:20 PM, Leif Thuresson wrote:
> On Thu, Jan 28, 2010 at 5:32 PM, Daniel J Walsh <dwalsh@redhat.com> wrote:
>
>> On 01/28/2010 09:53 AM, Leif Thuresson wrote:
>>> Hi,
>>> I have been experimenting with confined users in centos54 to create my
>> own
>>> staff and admin roles.
>>> I have only been meddling with policies for services before so creating
>> user
>>> domains is
>>> new territory for me.
>>> For the test I used userdom_unpriv_user_template() and
>>> userdom_admin_user_template()
>>> interfaces to create the an unprivileged login role and an admin role.
>>> The first test policy module looked like the one below but without the
>> call
>>> auth_run_chk_passwd()
>>> interface.
>>>
>>> In permissive mode I could login and verify with id -Z that I had the
>>> correct login role and type.
>>> I could use newrole to switch to the admin role and again verify that I
>>> received the correct
>>> role and type. I did not get any AVC denials when doing this.
>>>
>>> Now when I switched to enforcing mode I could login to the login role as
>>> before
>>> but when I ran newrole to switch to the admin role, newrole said
>>> 'incorrect password' and failed'
>>> but still no AVC denials.
>>> I traced newrole with strace and I could see that it failed trying to
>> open
>>> /etc/shadow
>>>
>> newrole is not allowed to read /etc/shadow (dontaudited), It expects the
>> use the pam_unix module in Fedora/RHEL which execs a helper app to read the
>> shadow file.
>>
> Hmm... strange that this did not work in my test environment, What is the
> name of the helper app?
>
>>
>>> When comparing centos54 interface for newrole in selinuxutil.if with
>>> corresponding
>>> interface in fedora12 (where I got a similar test working) I saw that the
>>> newrole interface in
>>> fedora12 called interfaces in authlogin.if  so I added similar calls in
>> my
>>> module
>>> and then I got it working in enforcing mode too !
>>> Although I think the newrole interface in centos54 is kind of useless
>> when
>>> it does not
>>> handle the authentication permissions internally :-(
>>>
>>> Now before I proceed with this project I would like to clear up my
>>> understanding of
>>> user domains so if anyone of you can answer these questions it would be
>> much
>>> appreciated.
>>> The ultimate target environment for my project is a RedHat5 based server
>>> farm.
>>>
>> If you want to use confined users in RHEL5 you need to install the strict
>> policy.   Targeted policy does not support confined users in RHEL5.  It does
>> support them in RHEL6.
>>> - First of all is this the right way to do this kind of thing or am I
>>> completely on the wrong track?
>>>   Is the user domain support mature enough in redhat5 to be used in a
>>> production environment?
>> Depends on what you are trying to do.  If this is a server machine it will
>> probably work ok,  if you want to have confined desktops, you will probably
>> run into problems.
>>
>
> What I want to do is to create admin roles with permissions to administer
> only a sub-system or service
> without the full power of root.
> I do realize that the natural way to do this would be to start with the
> strict policy, but it is my understanding that the strict policy is not
> fully supported by RedHat and that disqualifies it from
> being used in my target environment.
> My intension was to see if I could do something to gain a little bit of the
> confined user security improvements even with the targeted policy while
> waiting for the release of RedHat 6.
> The sub-system administrators can have a login role that is unconfined, but
> when executing admin commands via sudo or similar they will transfer into an
> admin role within a confined domain while the command is executing under
> uid=0
> So I must have my own unconfined login domain for sub-administrators so that
> I can separate them from default unconfined domain.
> Does this make sense? I realize that RedHat support for this environment
> might be questionable, but ideally I would only have to support my own
> additional policy modules myself instead of taking on the support for the
> full strict policy.
>
>>
>>>   If not I guess I have to wait for redhat6.
>>>
>> redhat6 should work well better with confined users.
>>> - Does anyone know how the feature transfer from Fedora to RedHat work?
>>>   How much of the selinux functionality existing in Fedora12 can we
>> expect
>>> to appear in
>>>   RedHat 6 when it arrives?
>>>
>> All of it.
>>
> Great! my problems will be solved then :-)
>
>>> - A assume that the reason my first test failed in enforcing mode without
>>> any AVC denials was
>>>   because of some hidden don't audit rules in the interfaces I called.
>>>   Is there some way to turn off don't audit rules globally to trace these
>>> problems ?
>>>   (I tried semodule -DB although it is not listed as a valid option on
>>> centos54 semodule man
>>>    page, but the only effect it had was that it got the setroubleshootd
>>> constantly crashing)
>>>
>> semodule -DB does not exist in RHEL5.
>>> Thanks,
>>> /leif
>>>
>>>
>>> Policy used in test below:
>>>
>>> policy_module(myadm, 1.0.0)
>>>
>>> require {
>>>         type unconfined_t;
>>>         type newrole_t;
>>>         type user_home_t;
>>>         type devpts_t;
>>>         type system_chkpwd_t;
>>> }
>>>
>>> # Create mystaff_r and mystaff_t
>>> userdom_unpriv_user_template(mystaff)
>>> allow mystaff_t user_home_t: file read;
>>> allow mystaff_t devpts_t:chr_file { read write ioctl };
>>>
>>> # Allow login daemon (sshd) to transition to mystaff_t
>>> allow unconfined_t mystaff_t:process transition;
>>>
>>> # Add "mystaff_r:mystaff_t" to /etc/selinux/targeted/
>>> contexts/default_type
>>>
>>> seutil_run_newrole(mystaff_t, mystaff_r, devpts_t)
>>>
>>> # There is a typo in the auth_run_chk_passwd() interface so we can't use
>> it.
>>> # Lets do the work inline instead
>>> # Implement auth_run_chk_passwd(newrole_t, mystaff_r, devpts_t) inline:
>>> auth_domtrans_chk_passwd(newrole_t)
>>> role mystaff_r types system_chkpwd_t;
>>> allow system_chkpwd_t devpts_t:chr_file rw_file_perms;
>>> auth_run_upd_passwd(newrole_t, mystaff_r, devpts_t)
>>>
>>> # Create myadm_r and myadm_t
>>> userdom_admin_user_template(myadm)
>>>
>>> # Add "myadm_r:myadm_t" to /etc/selinux/targeted/contexts/default_type
>>>
>>> domain_transition_pattern(newrole_t, shell_exec_t, myadm_t)
>>> userdom_role_change_template(mystaff, myadm)
>>>
>>> # Create mystaff_u
>>> gen_user(mystaff_u, mystaff, mystaff_r myadm_r, s0, s0 - mls_systemhigh,
>>> mcs_allcats)
>>>
>>>
>>>
>>>
>>> --
>>> selinux mailing list
>>> selinux@lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>>
>>
>
>
>
> --
> selinux mailing list
> selinux@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux

You could write a domain for commands that sudo executes and build a transition from unconfined_t -> confined_admin_exec_t -> confined_admin_t

Which should work in RHEL5 and 6.

If you want one unconfined user to execute these and another not, then you could have a problem, and might want to create a new unconfined user.

Or just do not execute the script.


For example.

You could label a shell as being confined_shell_exec_t /bin/confinedsh
Then any "confined admin" would have to run confinedsh from sudo, while the unconfined admin would run /bin/bash.

As long as the unconfined admin does not run /bin/confinedsh he would stay unconfined.