Problem getting newrole working in centos54

[Leif Thuresson]

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

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.

- 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?
  If not I guess I have to wait for redhat6.

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

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

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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/selinux/attachments/20100128/d8563140/attachment.html