From: justinmattock@gmail.com (Justin Mattock) Date: Wed, 3 Dec 2008 08:49:35 -0800 Subject: [refpolicy] new svn refpolicy difficuties: In-Reply-To: <1228310523.9691.387.camel@gorn> References: <1228112352.3841.13.camel@unix> <1228223603.9691.19.camel@gorn> <1228233441.2973.17.camel@unix> <1228244012.9691.22.camel@gorn> <1228246875.2928.1.camel@unix> <1228310523.9691.387.camel@gorn> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Wed, Dec 3, 2008 at 5:22 AM, Christopher J. PeBenito wrote: > On Tue, 2008-12-02 at 11:41 -0800, Justin P. Mattock wrote: >> On Tue, 2008-12-02 at 13:53 -0500, Christopher J. PeBenito wrote: >> > On Tue, 2008-12-02 at 07:57 -0800, Justin P. Mattock wrote: >> > > On Tue, 2008-12-02 at 08:13 -0500, Christopher J. PeBenito wrote: >> > > > On Sun, 2008-11-30 at 22:19 -0800, Justin P. Mattock wrote: >> > > > > With the latest refpolicy, I'm >> > > > > able to have all of the allow rules >> > > > > during the boot process applied to the policy, >> > > > > but as soon as I add any of the allow rules >> > > > > after startx, with any role I'm denied >> > > > > with building the policy i.g. >> > > > > >> > > > > :ERROR 'type staff_dbusd_t is not within scope' at token ';' on line >> > > > > 2581459: >> > > > > >> > > > > I think this has to do with my policy/users >> > > > > file.(where can I find info on setting a prefix?) >> > > > >> > > > I suspect it is actually related to this: >> > > > >> > > > http://marc.info/?l=selinux&m=122477138927253&w=2 >> > > > >> > > > What changes have you made (if any) to the policy? Also the >> > > > policy/modules.conf and build.conf? >> > > > >> > > >> > > This is the same issue from a few weeks ago >> > > (just never got around to working it); >> > > as for changes to the modules.conf, I sent >> > > you that a few weeks ago, which basically has nothing modified >> > > (my goal is to keep the policy as generic as possible >> > > no tweaking of any kind); I do modify the build.conf >> > > and policy/users. >> > > as for the users I set >> > > gen_user(user,system_u, sysadm_r staff_r user_r, s0, s0 -mls_systemhigh, >> > > mcs_allcats) >> > > >> > > and the build.conf I change the policy number setting >> > > debian, monolithic=y deny unkown=y not much stuff.. >> > > >> > > Overall, >> > > I'm not sure but after reading the users file it say's >> > > >> > > Note: Identities without a prefix wil not be listed >> > > in the users_extra file used by genhomedircon. >> > > (BTW there a typo in there "will") >> > > >> > > This here tells me that If I don't have this set >> > > correctly(prefix), I won't be able to build the policy >> > > accordingly with my user name and roles? hence the always >> > > an error during compiling when I add something like >> > > staff_dbus_t. >> > > If I have this correct will >> > > staff_dbus_t change to staff_t? or something to satisfy >> > > the compiling of the policy... >> > >> > No. This is error is not related to this. The users_extra content is >> > used for genhomedircon, and is in fact no longer used now that there is >> > UBAC. It has to do with issues with scoping in the compiler. I can't >> > reproduce this, where did you put the rules? >> > >> >> To make things easy I just put them in >> policy/modules/services/xserver.te >> (at the bottom) >> probably not the right way, >> but for testing purposes >> make things run faster for me. > > I think the toolchain fixes that I mentioned in the link above will fix > this. To work around it, you would have to put the rules in the (dbus| > ssh|sudo)role template. > > -- > Chris PeBenito > Tresys Technology, LLC > (410) 290-1411 x150 > > I'll see what I can come up with, my problem is it my be too much for me(but what the heck); A change of subject, with the newrole mechanism, If I log in as sysadm_r, then change roles to user_r, I see the: allow newrole user_r process transition (but can never be put into the policy?) With the older policies I would initialialy login as syadm_r, then login to staff_t for starting the internet, then user_r for entertainment needs but with this new mechanism, seems to be something different!! Anyways my main goal right now is to get this thing to compiled, before thinking about hiding different applications in different roles.. regards; -- Justin P. Mattock