Problem getting newrole working in centos54

[Stephen Smalley]

On Thu, 2010-01-28 at 15:53 +0100, 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
> 
> 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
> 

Don't take this as an authoritative answer, as I don't speak for Red
Hat. However:
1) I was under the impression that user domains in RHEL5 only work if
you switch to the -strict policy first, as RHEL5 preceded the merging of
targeted and strict policies.  If you can in fact set up confined user
roles under -targeted in RHEL5, that would be a good thing, but I didn't
think it worked.
2) I'd expect RHEL6 SELinux support to be more-or-less identical to
Fedora 12, possibly with some Fedora 13 bits included.
3) setroubleshootd will typically shut down when it sees an audit
message for itself to avoid an endless cycle, and semodule -DB can
certainly cause that to happen.  But you should still get audit data
in /var/log/audit/audit.log and/or /var/log/messages that you can use.
setroubleshootd is just a consumer of it.  I didn't know though that
RHEL5 supported semodule -DB; I thought you had to semodule
-b /usr/share/selinux/targeted/enableaudit.pp instead and then semodule
-b /usr/share/selinux/targeted/base.pp to revert (the old way before
semodule -DB existed).

-- 
Stephen Smalley
National Security Agency