Problem getting newrole working in centos54

Daniel J Walsh dwalsh at redhat.com
Thu Jan 28 16:32:17 UTC 2010


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

>   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.
> - 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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux



More information about the selinux mailing list