when making the latest refpolicy
from svn I keep receiving a checkpolicy error
with anything having to do with dbus:
allow sysadm_dbusd_t gconf_etc_t:dir { read search getattr };
allow sysadm_dbusd_t gconf_etc_t:file { read getattr };
changing these roles to staff_r still produces
and error, when commenting these out in my .te file
the error will continue to the next *_dbusd_t *
rule for some reason. is there a new setting with dbus
that I'm missing?
the system is ubuntu intrepid(unstable, or my own hacked version);
regards;
--
Justin P. Mattock
On Tue, 2008-11-11 at 07:32 -0800, Justin Mattock wrote:
> when making the latest refpolicy
> from svn I keep receiving a checkpolicy error
> with anything having to do with dbus:
> allow sysadm_dbusd_t gconf_etc_t:dir { read search getattr };
> allow sysadm_dbusd_t gconf_etc_t:file { read getattr };
> changing these roles to staff_r still produces
> and error, when commenting these out in my .te file
> the error will continue to the next *_dbusd_t *
> rule for some reason. is there a new setting with dbus
> that I'm missing?
> the system is ubuntu intrepid(unstable, or my own hacked version);
I don't see any problems. Can you post your modules.conf so I can try
to reproduce?
BTW its not necessary to cross-post an email like this; it defeats one
of the purposes of having a separate refpolicy list.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
On Tue, Nov 11, 2008 at 8:54 AM, Christopher J. PeBenito
<[email protected]> wrote:
> On Tue, 2008-11-11 at 07:32 -0800, Justin Mattock wrote:
>> when making the latest refpolicy
>> from svn I keep receiving a checkpolicy error
>> with anything having to do with dbus:
>> allow sysadm_dbusd_t gconf_etc_t:dir { read search getattr };
>> allow sysadm_dbusd_t gconf_etc_t:file { read getattr };
>> changing these roles to staff_r still produces
>> and error, when commenting these out in my .te file
>> the error will continue to the next *_dbusd_t *
>> rule for some reason. is there a new setting with dbus
>> that I'm missing?
>> the system is ubuntu intrepid(unstable, or my own hacked version);
>
> I don't see any problems. Can you post your modules.conf so I can try
> to reproduce?
>
> BTW its not necessary to cross-post an email like this; it defeats one
> of the purposes of having a separate refpolicy list.
>
> --
> Chris PeBenito
> Tresys Technology, LLC
> (410) 290-1411 x150
>
>
Alright, give me a few to see If I can reproduce this.
As for modules.conf, I did nothing to that file kept
everything as is. just commented out the capability
that was giving me the warning.
--
Justin P. Mattock
On Tue, Nov 11, 2008 at 9:49 AM, Justin Mattock <[email protected]> wrote:
> On Tue, Nov 11, 2008 at 8:54 AM, Christopher J. PeBenito
> <[email protected]> wrote:
>> On Tue, 2008-11-11 at 07:32 -0800, Justin Mattock wrote:
>>> when making the latest refpolicy
>>> from svn I keep receiving a checkpolicy error
>>> with anything having to do with dbus:
>>> allow sysadm_dbusd_t gconf_etc_t:dir { read search getattr };
>>> allow sysadm_dbusd_t gconf_etc_t:file { read getattr };
>>> changing these roles to staff_r still produces
>>> and error, when commenting these out in my .te file
>>> the error will continue to the next *_dbusd_t *
>>> rule for some reason. is there a new setting with dbus
>>> that I'm missing?
>>> the system is ubuntu intrepid(unstable, or my own hacked version);
>>
>> I don't see any problems. Can you post your modules.conf so I can try
>> to reproduce?
>>
>> BTW its not necessary to cross-post an email like this; it defeats one
>> of the purposes of having a separate refpolicy list.
>>
>> --
>> Chris PeBenito
>> Tresys Technology, LLC
>> (410) 290-1411 x150
>>
>>
>
> Alright, give me a few to see If I can reproduce this.
> As for modules.conf, I did nothing to that file kept
> everything as is. just commented out the capability
> that was giving me the warning.
>
> --
> Justin P. Mattock
>
O.K. its been a few...
here is what I see when making refpolicy:(svn)
(keep in mind the policy is monolithic, and I'm too lazy to individually
place the allow rules in the right location, just for now I stick them in
xserver.te at the bottom).
/usr/bin/checkpolicy -c 23 -U deny policy.conf -o policy.23
/usr/bin/checkpolicy: loading policy configuration from policy.conf
policy/modules/services/xserver.te":1028:ERROR 'type sysadm_dbusd_t is
not within scope' at token ';' on line 2543089:
allow setfiles_t file_t:chr_file { read write };
allow sysadm_dbusd_t gconf_etc_t:dir { read search getattr };
checkpolicy: error(s) encountered while parsing configuration
make: *** [policy.23] Error 1
As for changing the policy I added myself to policy/users
(like with the other policies)
modified: policy/policy_capabilities
commented out:
#policycap open_perms;
and uncommented:
policycap network_peer_controls;
then after everything was loaded used
audit2allow -d > file (to gather allow rules.)
running the stable refpolicy there is no issue except:
allow system_dbusd_t self:capability { sys_module sys_admin };
(which is from ath9k and network-manager).
here are the packages:(when issuing selinux in synaptic)
checkpolicy 2.0.16-1ubuntu1
libselinux1 2.0.65-2
libselinux1-dev 2.0.65-2
libsemanage1 2.0.25-1
libsemanage1-dev 2.0.25-1
libsepol1 2.0.30-2
libsepol1-dev 2.0.30-2
libsetools-tcl 3.3.5.ds-3
lsb-base 3.2-14ubuntu2
lsb-release 3.2-14ubuntu2
polgen 1.3-5
policycoreutils 2.0.49-6
python-selinux 2.0.65-2
python-semanage 2.0.25-1
python-sepolgen 1.0.11-4ubuntu1
selinux-utils 2.0.65-2
maybe I should change the kernel to not use a policy
number. but then again it could be something different.
hope this helps.
regards;
--
Justin P. Mattock
-------------- next part --------------
A non-text attachment was scrubbed...
Name: modules.conf
Type: application/octet-stream
Size: 25994 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20081111/10cdffd8/attachment-0001.obj