[refpolicy] new svn refpolicy difficuties:

[refpolicy] new svn refpolicy difficuties:

[Justin P. Mattock]

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


-- 
Justin P. Mattock <justinmattock@gmail.com>

[refpolicy] new svn refpolicy difficuties:

[Christopher J. PeBenito]

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?

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] new svn refpolicy difficuties:

[Justin P. Mattock]

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

As for the post I'll have to read that and see if
it is what I was going through.

regards;
-- 
Justin P. Mattock <justinmattock@gmail.com>

[refpolicy] new svn refpolicy difficuties:

[Christopher J. PeBenito]

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?

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] new svn refpolicy difficuties:

[Justin P. Mattock]

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.


-- 
Justin P. Mattock <justinmattock@gmail.com>

[refpolicy] new svn refpolicy difficuties:

[Christopher J. PeBenito]

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

[refpolicy] new svn refpolicy difficuties:

[Justin Mattock]

On Wed, Dec 3, 2008 at 5:22 AM, Christopher J. PeBenito
<cpebenito@tresys.com> 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

[refpolicy] new svn refpolicy difficuties:

[Christopher J. PeBenito]

On Wed, 2008-12-03 at 08:49 -0800, Justin Mattock wrote:
> 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!!

I fixed a mistake in the role change constraint.  svn up and it should
work again.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] new svn refpolicy difficuties:

[Justin Mattock]

On Wed, Dec 3, 2008 at 12:30 PM, Christopher J. PeBenito
<cpebenito@tresys.com> wrote:
> On Wed, 2008-12-03 at 08:49 -0800, Justin Mattock wrote:
>> 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!!
>
> I fixed a mistake in the role change constraint.  svn up and it should
> work again.
>
> --
> Chris PeBenito
> Tresys Technology, LLC
> (410) 290-1411 x150
>
>

Cool thanks for looking into this,
unfortunately I can't get this thing to compile
to get to the point of changing roles.
unless you're talking about:
git clone http://oss.tresys.com/git/selinux.git
then I can go ahead and do a git-pull
and see If I get that annoying
newrole *_t process transition thing..
(In any case my head hurts,
I need a beer) ;^)

-- 
Justin P. Mattock

[refpolicy] new svn refpolicy difficuties:

[Justin Mattock]

On Wed, Dec 3, 2008 at 1:06 PM, Justin Mattock <justinmattock@gmail.com> wrote:
> On Wed, Dec 3, 2008 at 12:30 PM, Christopher J. PeBenito
> <cpebenito@tresys.com> wrote:
>> On Wed, 2008-12-03 at 08:49 -0800, Justin Mattock wrote:
>>> 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!!
>>
>> I fixed a mistake in the role change constraint.  svn up and it should
>> work again.
>>
>> --
>> Chris PeBenito
>> Tresys Technology, LLC
>> (410) 290-1411 x150
>>
>>
>
> Cool thanks for looking into this,
> unfortunately I can't get this thing to compile
> to get to the point of changing roles.
> unless you're talking about:
> git clone http://oss.tresys.com/git/selinux.git
> then I can go ahead and do a git-pull
> and see If I get that annoying
> newrole *_t process transition thing..
> (In any case my head hurts,
> I need a beer) ;^)
>
> --
> Justin P. Mattock
>

O.K.
two things here:(or three)

A) I really don't know what I'm doing,
but am willing to try.

B) Thank you very much for the help,
and patience.

C) I finally figured it out,

The policy doesn't like sudo, or su
i.g. starting a terminal with nubuntu,
under .fluxbox/init I see
aterm -e sudo su
reason for the error when compiling.

If I start aterm, (normally)
the policy will compile, if I use
newrole -r user_r -- -c /usr/bin/firefox
in aterm I can change roles and use firefox.
(in full enforced mode)

wpa_supplicant seems a bit interesting
since I need to be root to run...
(probably need to have this run during boot)

the radio(bmpx)
seems to create sysadm_dbus_t
which tells me another sudo or su
scenario.

Is there a command to run an application
as root(i.g. wpa_supplicant, and dhclient)?

Anyways thanks again,


-- 
Justin P. Mattock

[refpolicy] new svn refpolicy difficuties:

[Justin Mattock]

On Tue, Dec 2, 2008 at 10:53 AM, Christopher J. PeBenito
<cpebenito@tresys.com> 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?
>
> --
> Chris PeBenito
> Tresys Technology, LLC
> (410) 290-1411 x150
>
>

O.K. well, after throwing away the
intrepid system, and loading hardy
it seems the problem is still
there.  If you have any ideas I'm up
to listening, or trying any paches.
until then I'm just going to use the stable
release.(was hoping to tackle this since,
but seems to be too intricate for me.);

regards;



-- 
Justin P. Mattock

[refpolicy] new svn refpolicy difficuties:

[Justin P. Mattock]

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

Attached you will find the allow rules
that I added to the policy.
hopefully it gives you a better idea of what
I'm seeing.
regards;

-- 
Justin P. Mattock <justinmattock@gmail.com>
-------------- next part --------------
#  monolithic policy compile, simple start system
#  open a aterm and use audit2allow -d to collect 
#  allow rules.



allow NetworkManager_t initrc_var_run_t:dir search;
allow NetworkManager_t initrc_var_run_t:sock_file write;
allow NetworkManager_t tmpfs_t:dir { write search add_name };
allow NetworkManager_t tmpfs_t:file { write create };
allow NetworkManager_t tmpfs_t:sock_file write;
allow avahi_t initrc_var_run_t:dir search;
allow avahi_t initrc_var_run_t:sock_file write;
allow avahi_t tmpfs_t:dir { write search setattr create getattr add_name };
allow avahi_t tmpfs_t:file { read write create lock };
allow avahi_t tmpfs_t:sock_file { write create };
allow bluetooth_t tmpfs_t:dir search;
allow crond_t tmpfs_t:dir { write search add_name };
allow crond_t tmpfs_t:file { read write create getattr lock };
allow crond_t tmpfs_t:sock_file write;
allow dmesg_t file_t:chr_file { read write };
allow fsadm_t file_t:chr_file { read write ioctl };
allow getty_t tmpfs_t:dir search;
allow hald_t initrc_var_run_t:dir { write remove_name add_name };
allow hald_t initrc_var_run_t:file { rename create unlink };
allow hald_t initrc_var_run_t:sock_file write;
allow hald_t tmpfs_t:sock_file write;
allow hald_t var_lib_t:file { read getattr };
allow hostname_t file_t:chr_file { read write };
allow insmod_t file_t:chr_file getattr;
allow insmod_t tty_device_t:chr_file { read write };
allow iptables_t file_t:chr_file { read write };
allow iptables_t var_lib_t:file { read getattr };
allow klogd_t initrc_var_run_t:dir { write search add_name };
allow klogd_t initrc_var_run_t:fifo_file read;
allow klogd_t initrc_var_run_t:file { read write create getattr lock };
allow klogd_t src_t:dir search;
allow klogd_t tmpfs_t:dir search;
allow klogd_t tmpfs_t:sock_file write;
allow loadkeys_t file_t:chr_file { read write ioctl getattr };
allow loadkeys_t file_t:dir search;
allow mount_t etc_t:file { write append };
allow mount_t file_t:chr_file { read write };
allow mount_t lib_t:dir mounton;
allow restorecond_t file_t:chr_file { read write ioctl };
allow restorecond_t tmpfs_t:dir { write add_name };
allow restorecond_t tmpfs_t:file { write create };
allow restorecond_t tmpfs_t:sock_file write;
allow setfiles_t file_t:chr_file { read write };
allow syslogd_t self:capability { setuid setgid };
allow syslogd_t tmpfs_t:dir { write search add_name };
allow syslogd_t tmpfs_t:file { read write create getattr lock };
allow syslogd_t tmpfs_t:sock_file { create setattr };
allow udev_t hald_t:unix_dgram_socket { read write };
allow udev_t tmpfs_t:dir { write remove_name search getattr add_name };
allow udev_t xserver_tmpfs_t:dir { write getattr search add_name };
allow xauth_t user_tmp_t:file { write unlink };
allow sysadm_t self:process { execstack execmem };
allow apmd_t hald_t:dbus send_msg;
allow hald_t apmd_t:dbus send_msg;
allow hwclock_t file_t:chr_file { read write };
allow ifconfig_t file_t:chr_file { read write };
allow initrc_t sysadm_t:dbus send_msg;
allow loadkeys_t tmpfs_t:dir search;
allow mount_t etc_t:dir mounton;
allow mount_t initrc_var_run_t:dir mounton;
allow sysadm_t initrc_t:dbus send_msg;
allow udev_t xserver_tmpfs_t:chr_file { relabelfrom getattr };
allow insmod_t tmpfs_t:chr_file { read write getattr };
allow udev_t file_t:chr_file { read write };
allow udev_t tmpfs_t:chr_file { read write };
allow udev_t tmpfs_t:file { write getattr };
allow udev_t alsa_var_lib_t:dir { getattr search };
allow udev_t alsa_var_lib_t:file getattr;
allow udev_t initrc_var_run_t:dir search;
allow udev_t tmpfs_t:chr_file { relabelfrom getattr };
allow alsa_t tmpfs_t:dir search;
allow hwclock_t tmpfs_t:dir search;
allow insmod_t file_t:chr_file { read write };




# system_dbus_t has no issues, only somerole_dbus_t etc..


allow system_dbusd_t NetworkManager_exec_t:file { read execute execute_no_trans };
allow system_dbusd_t NetworkManager_log_t:file { getattr append };
allow system_dbusd_t NetworkManager_t:dbus send_msg;
allow system_dbusd_t hald_t:dbus send_msg;
allow system_dbusd_t initrc_var_run_t:dir { write search add_name };
allow system_dbusd_t initrc_var_run_t:file { write create getattr };
allow system_dbusd_t initrc_var_run_t:sock_file { write create setattr };
allow system_dbusd_t inotifyfs_t:dir getattr;
allow system_dbusd_t lib_t:file execute_no_trans;
allow system_dbusd_t proc_net_t:file read;
allow system_dbusd_t self:capability { net_admin net_raw };
allow system_dbusd_t self:netlink_route_socket nlmsg_write;
allow system_dbusd_t self:packet_socket { bind create ioctl };
allow system_dbusd_t tmpfs_t:dir search;
allow system_dbusd_t tmpfs_t:sock_file write;
allow system_dbusd_t var_lib_t:file read;
allow system_dbusd_t var_log_t:dir search;




#  These below seem to give an error while compiling the policy
#  with checkpolicy.
#
#  :ERROR 'type sysadm_dbusd_t is not within scope' at token ';' on line 2581450:
#
#  allow sysadm_dbusd_t gconf_etc_t:dir { read search getattr };
#  checkpolicy:  error(s) encountered while parsing configuration
#  
#  if I comment out the first error, checkpolicy moves down to the next
#  and gives the same error.




allow sysadm_dbusd_t gconf_etc_t:dir { read search getattr };
allow sysadm_dbusd_t gconf_etc_t:file { read getattr };
allow sysadm_dbusd_t gconf_home_t:dir { write search read remove_name getattr add_name };
allow sysadm_dbusd_t gconf_home_t:file { write getattr read create unlink append };
allow sysadm_dbusd_t initrc_var_run_t:dir search;
allow sysadm_dbusd_t initrc_var_run_t:sock_file write;
allow sysadm_dbusd_t lib_t:file execute_no_trans;
allow sysadm_dbusd_t self:process getsched;
allow sysadm_dbusd_t self:unix_stream_socket connectto;
allow sysadm_dbusd_t session_dbusd_tmp_t:sock_file { write create };
allow sysadm_dbusd_t sysadm_t:dbus send_msg;
allow sysadm_dbusd_t sysadm_t:unix_stream_socket connectto;
allow sysadm_dbusd_t system_dbusd_t:dbus send_msg;
allow sysadm_dbusd_t system_dbusd_t:unix_stream_socket connectto;
allow sysadm_dbusd_t tmpfs_t:dir search;
allow sysadm_dbusd_t tmpfs_t:sock_file write;
allow sysadm_dbusd_t user_home_t:file append;
allow sysadm_dbusd_t user_tty_device_t:chr_file { read write };
allow sysadm_dbusd_t var_lib_t:file { read getattr };
allow sysadm_ssh_agent_t tmpfs_t:dir search;
allow sysadm_ssh_agent_t user_home_t:file append;
allow sysadm_sudo_t security_t:security compute_av;
allow sysadm_sudo_t su_exec_t:file { read execute execute_no_trans };
allow sysadm_sudo_t tmpfs_t:dir { write search create add_name };
allow sysadm_sudo_t tmpfs_t:file { write create };
allow sysadm_sudo_t tmpfs_t:sock_file write;
allow sysadm_sudo_t user_home_dir_t:dir search;