Problem getting newrole working in centos54

Leif Thuresson leif.thuresson at gmail.com
Thu Jan 28 20:28:24 UTC 2010


On Thu, Jan 28, 2010 at 5:21 PM, Stephen Smalley <sds at tycho.nsa.gov> wrote:

> 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.
>
Well I can settle for only a users secondary role being confined but I not
sure
if that work either. This is what I wanted to test.

> 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).
>
> It is not mentioned in the man page, but it accepted the options without
complaints
and something apparently happened. Thanks for the explanation of the
setroubleshootd
behavior. I'll look a bit closer at the log messages and see if I can find
the missing AVCs

> --
> Stephen Smalley
> National Security Agency
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/selinux/attachments/20100128/319f305f/attachment.html 


More information about the selinux mailing list