11:46 a.m.
On 12/01/2009 09:47 AM, Dominick Grift wrote:
On 12/01/2009 03:44 PM, Chris Richards wrote:
> First, my apologies if I'm in the wrong place or this has been asked
> before (I'm sure it has, but I haven't turned up anything with Google).
>
> I'm running a Gentoo system. This is a fresh build, so not everything
> is installed yet. Basically, I've got the stage 3 tarball, the Selinux
> stuff, syslog-ng and vixie-cron, and that's about it.
>
> When I boot my sysem, I'm getting the following messages in my kernel
> log:
> * Mounting /dev
> /etc/init.d/udev-mount: line 63: /dev/null: Permission denied
> /etc/init.d/udev: line 69: /dev/null: Permission denied
> * Starting udevd
> * Populating /dev with existing devices through uevents ...
> # Waiting for uevents to be processed ...
> error sending message: Permission denied
> error sending message: Permission denied
> udevadm[601]: errorsending message: Permission denied
>
> Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.208:3):
> avc: denied { read } for pid=1 comm="init" name="ld.so.cache"
dev=sda3
> ino=737384 scontext=system_u:system_r:init_t
> tcontext=system_u:object_r:file_t tclass=file
> Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.215:4):
> avc: denied { getattr } for pid=1 comm="init"
path="/etc/ld.so.cache"
> dev=sda3 ino=737384 scontext=system_u:system_r:init_t
> tcontext=system_u:object_r:file_t tclass=file
looks like the file is mislabeled. what does matchpathcon
/etc/ld.so.cache say?
make sure that your file system labeling is correct.
I've relabled like 15 times with rlpkg -a -r. LOL
matchpathcon /etc/ld.so.cache
/etc/ld.so.cache system_u:object_r:ld_so_cache_t
ls -Z /etc/ld.so.cache
root:object_r:ld_so_cache_t
Based on the above, I did
chcon -u system_u /etc/ld.so.cache
That seems to have resolved the issues that were plaguing me there.
> The pattern of denials above repeats for a number of comm=
types,
> including consoletype, dmesg, hwclock, hostname, ifconfig
>
> Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.221:5):
> avc: denied { read } for pid=1 comm="init" name="urandom"
dev=sda3
> ino=140683 scontext=system_u:system_r:init_t
> tcontext=system_u:object_r:urandom_device_t tclass=chr_file
>
> As above, I get a number of denials on different comm= types.
>
>
> I'm also seeing a buttload of these in my avc.log:
> Dec 1 13:48:41 aoaforums kernel: type=1400
> audit(1259675321.237:1614490880): avc: denied { read } for pid=477
> comm="udevd" path="anon_inode:[signalfd]" dev=anon_inodefs ino=9
> scontext=system_u:system_r:udev_t
> tcontext=system_u:object_r:anon_inodefs_t tclass=file
> This one in particular is bad: my log is full to overflowing with this
> one, and when I'm in enforcing mode udevd is pulling 100% cpu.
If the types in this interaction are correct. Run the avc denial through
audit2why. If audit2why says "missing TE rule"; then consider adding
policy to allow it using audit2allow and semodule.
That's exactly what it says.
When I do the following:
# grep udev /var/log/avc.log > local
# audit2allow -m local > local.te
# checkmodule -M -m -o local.mod local.te
checkmodule: loading policy configuration from local.te
checkmodule: policy configuration loaded
checkmodule: writing binary representation (version 8) to local.mod
# semodule_package -o local.pp -m local.mod
# semodule -i ./local.pp
Everything goes fine up to the semodule -i command, and then I get:
libsepol.link_modules: Tried to link in an MLS module with a non-MLS base.
libsemanage.semanage_link_sandbox: Link packages failed
semodule: Failed!
Based on all the weird problems and heartburn I've had, I'm really
starting to wonder if ANYONE in recent history has gotten a strict
Selinux profile running in enforcing mode on hardened-gentoo according
to the instructions in the Gentoo Selinux Handbook. Getting even to
this point has been frustrating beyond belief.
And before I give anyone the wrong impression, I really do appreciate
the hard work that has gone into this; I'm just suffering from a steep
learning curve, and documentation that I not only don't understand, but
doesn't seem to correspond to my system when I DO understand it.
> Finally, a related question:
> Gentoo is currently running what is labeled as
> "selinux-base-policy-20080525".
That policy is old. See if you can implement some newer policy.
That's default gentoo-hardened policy. V2 policy horridly breaks a
hardened gentoo system at this stage from what I understand (as in, it
won't even boot).
> This seems to bear little resemblance to the policy and tools
that I see
> discussed here:
> http://oss.tresys.com/projects/refpolicy/wiki/GettingStarted
>
> In particular, a lot of the booleans don't exist. As near as I can
> tell, this is pretty much the policy that was used in RHEL 4. However,
> I can find precious little in the way of documentation on the older
> policy setup. Can anyone provide any guidance on resources to look at
> for this? Referring me to the current base policy and tools really
> doesn't help me in understanding what my system is doing.....
>
> Many thanks in advance for any guidance you can offer.
Overall it is good to appreciate that SELinux is a framework and that
policy is configuration. The framework allows you to define policy.
The process of adding policy is always on going. In my view no policy
will ever be perfect. There are simply to many variables.
Learn how to implement policy, make security decisions and solve
interaction problems.
Theres a few things to consider:
1. are the types in an interaction the expected types. (mislabeled
objects?)
2. is there some tunable policy available to allow an interaction that
is currently denied? (audit2why)
3. is a denial caused by misconfiguration of one of the parties in an
interaction? (check config of app)
4. is a denial signalling an intrusion. (break in?)
5. is a denials signalling a bug in one of the parties in an
interaction? (bug in app)
6. is it a bug in selinux-policy( are rules to allow it missing?)
Thanks for your response and help.
Later,
Chris
12:36 p.m.
New subject: AVC Denials on UDEV
On Wed, Dec 02, 2009 at 11:46:15AM -0600, Chris Richards wrote:
On 12/01/2009 09:47 AM, Dominick Grift wrote:
>On 12/01/2009 03:44 PM, Chris Richards wrote:
>>First, my apologies if I'm in the wrong place or this has been asked
>>before (I'm sure it has, but I haven't turned up anything with Google).
>>
>>I'm running a Gentoo system. This is a fresh build, so not everything
>>is installed yet. Basically, I've got the stage 3 tarball, the Selinux
>>stuff, syslog-ng and vixie-cron, and that's about it.
>>
>>When I boot my sysem, I'm getting the following messages in my
>>kernel log:
>>* Mounting /dev
>>/etc/init.d/udev-mount: line 63: /dev/null: Permission denied
>>/etc/init.d/udev: line 69: /dev/null: Permission denied
>>* Starting udevd
>>* Populating /dev with existing devices through uevents ...
>># Waiting for uevents to be processed ...
>>error sending message: Permission denied
>>error sending message: Permission denied
>>udevadm[601]: errorsending message: Permission denied
>>
>>Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.208:3):
>>avc: denied { read } for pid=1 comm="init"
name="ld.so.cache" dev=sda3
>>ino=737384 scontext=system_u:system_r:init_t
>>tcontext=system_u:object_r:file_t tclass=file
>>Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.215:4):
>>avc: denied { getattr } for pid=1 comm="init"
path="/etc/ld.so.cache"
>>dev=sda3 ino=737384 scontext=system_u:system_r:init_t
>>tcontext=system_u:object_r:file_t tclass=file
>looks like the file is mislabeled. what does matchpathcon
>/etc/ld.so.cache say?
>
>make sure that your file system labeling is correct.
>
I've relabled like 15 times with rlpkg -a -r. LOL
matchpathcon /etc/ld.so.cache
/etc/ld.so.cache system_u:object_r:ld_so_cache_t
ls -Z /etc/ld.so.cache
root:object_r:ld_so_cache_t
Based on the above, I did
chcon -u system_u /etc/ld.so.cache
The -u system_u isnt responsible for the denial. In the avc denials above the type for the
file was etc_t. That was mislabeled because matchpatchcon said it should have been
ld_so_cache_t. So i think restoration (relabeling) fixed it.
That seems to have resolved the issues that were plaguing me there.
>>The pattern of denials above repeats for a number of comm= types,
>>including consoletype, dmesg, hwclock, hostname, ifconfig
>>
>>Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.221:5):
>>avc: denied { read } for pid=1 comm="init" name="urandom"
dev=sda3
>>ino=140683 scontext=system_u:system_r:init_t
>>tcontext=system_u:object_r:urandom_device_t tclass=chr_file
>>
>>As above, I get a number of denials on different comm= types.
>>
>>
>>I'm also seeing a buttload of these in my avc.log:
>>Dec 1 13:48:41 aoaforums kernel: type=1400
>>audit(1259675321.237:1614490880): avc: denied { read } for pid=477
>>comm="udevd" path="anon_inode:[signalfd]" dev=anon_inodefs
ino=9
>>scontext=system_u:system_r:udev_t
>>tcontext=system_u:object_r:anon_inodefs_t tclass=file
>>This one in particular is bad: my log is full to overflowing with this
>>one, and when I'm in enforcing mode udevd is pulling 100% cpu.
>If the types in this interaction are correct. Run the avc denial through
>audit2why. If audit2why says "missing TE rule"; then consider adding
>policy to allow it using audit2allow and semodule.
>
That's exactly what it says.
When I do the following:
# grep udev /var/log/avc.log > local
# audit2allow -m local > local.te
# checkmodule -M -m -o local.mod local.te
checkmodule: loading policy configuration from local.te
checkmodule: policy configuration loaded
checkmodule: writing binary representation (version 8) to local.mod
# semodule_package -o local.pp -m local.mod
# semodule -i ./local.pp
Everything goes fine up to the semodule -i command, and then I get:
The checkmodule command has some bugs i think.
in fedora we use the make file:
make -f /usr/share/selinux/devel/Makefile myudevfix.pp
semodule -i myudevfix.pp
libsepol.link_modules: Tried to link in an MLS module with a non-MLS base.
libsemanage.semanage_link_sandbox: Link packages failed
semodule: Failed!
Based on all the weird problems and heartburn I've had, I'm really
starting to wonder if ANYONE in recent history has gotten a strict
Selinux profile running in enforcing mode on hardened-gentoo
according to the instructions in the Gentoo Selinux Handbook.
Getting even to this point has been frustrating beyond belief.
Well i have seen some people who have it in the #selinux irc chan, but i think they used
newer policy.
And before I give anyone the wrong impression, I really do
appreciate the hard work that has gone into this; I'm just suffering
from a steep learning curve, and documentation that I not only don't
understand, but doesn't seem to correspond to my system when I DO
understand it.
Well there are certainly some basics one needs to be familair with , with regard to
policy, but when you have that its pretty easy.
SELinux is a framework that lets one define types and assign these types to subjects and
objects in a system. The framework also lets on define policy that governs how types can
interact with eashother. To make this possible, the kernel provides classes and
permission. if you put that together you get something like this:
allow subjecttype_t objecttype_t:objectclass permissions;
then theres the concept of (subject and object) type transitions. ( go from one type to
another type )
Those are the basics of type enforcement. Then youll alsoo need to get familair with how
policy is structured upstream (they have some guidelines that make maintenance easier)
Then get to know the tools, and youre halfway there.
>>Finally, a related question:
>>Gentoo is currently running what is labeled as
>>"selinux-base-policy-20080525".
>That policy is old. See if you can implement some newer policy.
>
That's default gentoo-hardened policy. V2 policy horridly breaks a
hardened gentoo system at this stage from what I understand (as in,
it won't even boot).
>>This seems to bear little resemblance to the policy and tools that I see
>>discussed here:
>>http://oss.tresys.com/projects/refpolicy/wiki/GettingStarted
>>
>>In particular, a lot of the booleans don't exist. As near as I can
>>tell, this is pretty much the policy that was used in RHEL 4. However,
>>I can find precious little in the way of documentation on the older
>>policy setup. Can anyone provide any guidance on resources to look at
>>for this? Referring me to the current base policy and tools really
>>doesn't help me in understanding what my system is doing.....
>>
>>Many thanks in advance for any guidance you can offer.
>Overall it is good to appreciate that SELinux is a framework and that
>policy is configuration. The framework allows you to define policy.
>
>The process of adding policy is always on going. In my view no policy
>will ever be perfect. There are simply to many variables.
>
>Learn how to implement policy, make security decisions and solve
>interaction problems.
>
>Theres a few things to consider:
>
>1. are the types in an interaction the expected types. (mislabeled
>objects?)
>2. is there some tunable policy available to allow an interaction that
>is currently denied? (audit2why)
>3. is a denial caused by misconfiguration of one of the parties in an
>interaction? (check config of app)
>4. is a denial signalling an intrusion. (break in?)
>5. is a denials signalling a bug in one of the parties in an
>interaction? (bug in app)
>6. is it a bug in selinux-policy( are rules to allow it missing?)
>
Thanks for your response and help.
Later,
Chris
--
fedora-selinux-list mailing list
fedora-selinux-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
5:13 p.m.
New subject: AVC Denials on UDEV
On 12/02/2009 12:36 PM, Dominick Grift wrote:
>>> Nov 29 23:55:30 aoaforums kernel: type=1400
audit(1259538915.208:3):
>>> avc: denied { read } for pid=1 comm="init"
name="ld.so.cache" dev=sda3
>>> ino=737384 scontext=system_u:system_r:init_t
>>> tcontext=system_u:object_r:file_t tclass=file
>>> Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.215:4):
>>> avc: denied { getattr } for pid=1 comm="init"
path="/etc/ld.so.cache"
>>> dev=sda3 ino=737384 scontext=system_u:system_r:init_t
>>> tcontext=system_u:object_r:file_t tclass=file
>>>
>> looks like the file is mislabeled. what does matchpathcon
>> /etc/ld.so.cache say?
>>
>> make sure that your file system labeling is correct.
>>
>>
> I've relabled like 15 times with rlpkg -a -r. LOL
>
> matchpathcon /etc/ld.so.cache
> /etc/ld.so.cache system_u:object_r:ld_so_cache_t
>
> ls -Z /etc/ld.so.cache
> root:object_r:ld_so_cache_t
>
> Based on the above, I did
> chcon -u system_u /etc/ld.so.cache
>
The -u system_u isnt responsible for the denial. In the avc denials above the type for
the file was etc_t. That was mislabeled because matchpatchcon said it should have been
ld_so_cache_t. So i think restoration (relabeling) fixed it.
Eh? I'm not understanding something: I thought the source context was
init_t and that target was file_t? Now I'm really confused again.
In any case, I didn't relabel, all I did for that one was the chcon
mentioned above, and the error no longer exists. Again, I'm really
confused.
> When I do the following:
> # grep udev /var/log/avc.log> local
> # audit2allow -m local> local.te
> # checkmodule -M -m -o local.mod local.te
> checkmodule: loading policy configuration from local.te
> checkmodule: policy configuration loaded
> checkmodule: writing binary representation (version 8) to local.mod
> # semodule_package -o local.pp -m local.mod
> # semodule -i ./local.pp
>
> Everything goes fine up to the semodule -i command, and then I get:
>
The checkmodule command has some bugs i think.
in fedora we use the make file:
make -f /usr/share/selinux/devel/Makefile myudevfix.pp
semodule -i myudevfix.pp
That would be wonderful, except that I don't have the make file. I
don't even have the source files. Gentoo policy is distributed as
binaries only, to the best of my knowledge.
> libsepol.link_modules: Tried to link in an MLS module with a
non-MLS base.
> libsemanage.semanage_link_sandbox: Link packages failed
> semodule: Failed!
>
> Based on all the weird problems and heartburn I've had, I'm really
> starting to wonder if ANYONE in recent history has gotten a strict
> Selinux profile running in enforcing mode on hardened-gentoo
> according to the instructions in the Gentoo Selinux Handbook.
> Getting even to this point has been frustrating beyond belief.
>
Well i have seen some people who have it in the #selinux irc chan, but i think they used
newer policy.
> And before I give anyone the wrong impression, I really do
> appreciate the hard work that has gone into this; I'm just suffering
> from a steep learning curve, and documentation that I not only don't
> understand, but doesn't seem to correspond to my system when I DO
> understand it.
>
Well there are certainly some basics one needs to be familair with , with regard to
policy, but when you have that its pretty easy.
That's possible. There's a v2refpolicy profile in the Portage tree,
but
the Gentoo Selinux Handbook specifically says to ONLY use the Portage
profile I'm using right now. Perhaps I need to see if I can pick
Christopher PeBenito's brain, as I gather he has some involvement both
in the SELinux community and the Gentoo community.
SELinux is a framework that lets one define types and assign these
types to subjects and objects in a system. The framework also lets on define policy that
governs how types can interact with eashother. To make this possible, the kernel provides
classes and permission. if you put that together you get something like this:
allow subjecttype_t objecttype_t:objectclass permissions;
then theres the concept of (subject and object) type transitions. ( go from one type to
another type )
Those are the basics of type enforcement. Then youll alsoo need to get familair with how
policy is structured upstream (they have some guidelines that make maintenance easier)
Then get to know the tools, and youre halfway there.
Ah, but therein seems to lie the rub for me: near as I can tell, there
were some major changes made in how the policy is written somewhere
around the late May/early June timeframe. All of the documentation that
I can find refers to the new framework, whereas the policy I'm using
appears to be based on the old framework. As a consequence, just about
the time I think I'm starting to get a handle on what works how, I run
into something that doesn't correspond to what the SELinux docs are
telling me.
A good is example is refpolicy itself: the policy explained at the
tresys site:
http://oss.tresys.com/projects/refpolicy/wiki/UseRefpolicy
Seems to be rather well thought ought, and reasonably logical and
orthoginal. It also seems to bear little resemblance to what I'm
using. The instructions for the tools that I come across seem to mostly
reference things that don't even exist for me, or if they did exist
would be absolutely useless to me because they are GUI tools, and my
systems don't even have X installed.
I realize that a good deal of this is almost certainly due to the fact
that I'm on Gentoo. I'd much rather be part of the solution than part
of the problem, so I want to get to where I can start helping with
Gentoo's SELinux implementation, but I'm so blasted confused I don't
even rightly know how to start.
As I've said previously, Gentoo SEEMS to be using policy and tools from
RHEL 4's incarnation of SELinux. That's all well and good, EXCEPT that
the documentation describing the policies and tools seems to have gone
wandering, so those of use poor schmucks stuck schlepping through the
muck of the previous generation's tools have no clue where we are or
where we are going, and since I don't even have the source for the
policies that I AM using, I'm stuck with my finger up my nose going "Whuh?"
And now, I think I've done enough whining for one day. ;)
Once again, thanks for your time.
Later,
Chris
5:21 p.m.
New subject: AVC Denials on UDEV
On Wed, Dec 02, 2009 at 05:13:41PM -0600, Chris Richards wrote:
On 12/02/2009 12:36 PM, Dominick Grift wrote:
>>>>Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.208:3):
>>>>avc: denied { read } for pid=1 comm="init"
name="ld.so.cache" dev=sda3
>>>>ino=737384 scontext=system_u:system_r:init_t
>>>>tcontext=system_u:object_r:file_t tclass=file
>>>>Nov 29 23:55:30 aoaforums kernel: type=1400 audit(1259538915.215:4):
>>>>avc: denied { getattr } for pid=1 comm="init"
path="/etc/ld.so.cache"
>>>>dev=sda3 ino=737384 scontext=system_u:system_r:init_t
>>>>tcontext=system_u:object_r:file_t tclass=file
>>>looks like the file is mislabeled. what does matchpathcon
>>>/etc/ld.so.cache say?
>>>
>>>make sure that your file system labeling is correct.
>>>
>>I've relabled like 15 times with rlpkg -a -r. LOL
>>
>>matchpathcon /etc/ld.so.cache
>>/etc/ld.so.cache system_u:object_r:ld_so_cache_t
>>
>>ls -Z /etc/ld.so.cache
>>root:object_r:ld_so_cache_t
>>
>>Based on the above, I did
>>chcon -u system_u /etc/ld.so.cache
>The -u system_u isnt responsible for the denial. In the avc denials above the type
for the file was etc_t. That was mislabeled because matchpatchcon said it should have been
ld_so_cache_t. So i think restoration (relabeling) fixed it.
Eh? I'm not understanding something: I thought the source context
was init_t and that target was file_t? Now I'm really confused
again.
Yes sorry i meant to say file_t.
In any case, I didn't relabel, all I did for that one was the chcon
mentioned above, and the error no longer exists. Again, I'm really
confused.
whatever happend the type changed and thats what counts.
>>When I do the following:
>># grep udev /var/log/avc.log> local
>># audit2allow -m local> local.te
>># checkmodule -M -m -o local.mod local.te
>>checkmodule: loading policy configuration from local.te
>>checkmodule: policy configuration loaded
>>checkmodule: writing binary representation (version 8) to local.mod
>># semodule_package -o local.pp -m local.mod
>># semodule -i ./local.pp
>>
>>Everything goes fine up to the semodule -i command, and then I get:
>The checkmodule command has some bugs i think.
>in fedora we use the make file:
>
>make -f /usr/share/selinux/devel/Makefile myudevfix.pp
>semodule -i myudevfix.pp
That would be wonderful, except that I don't have the make file. I
don't even have the source files. Gentoo policy is distributed as
binaries only, to the best of my knowledge.
>>libsepol.link_modules: Tried to link in an MLS module with a non-MLS base.
>>libsemanage.semanage_link_sandbox: Link packages failed
>>semodule: Failed!
>>
>>Based on all the weird problems and heartburn I've had, I'm really
>>starting to wonder if ANYONE in recent history has gotten a strict
>>Selinux profile running in enforcing mode on hardened-gentoo
>>according to the instructions in the Gentoo Selinux Handbook.
>>Getting even to this point has been frustrating beyond belief.
>Well i have seen some people who have it in the #selinux irc chan, but i think they
used newer policy.
>
>>And before I give anyone the wrong impression, I really do
>>appreciate the hard work that has gone into this; I'm just suffering
>>from a steep learning curve, and documentation that I not only don't
>>understand, but doesn't seem to correspond to my system when I DO
>>understand it.
>Well there are certainly some basics one needs to be familair with , with regard to
policy, but when you have that its pretty easy.
>
That's possible. There's a v2refpolicy profile in the Portage tree,
but the Gentoo Selinux Handbook specifically says to ONLY use the
Portage profile I'm using right now. Perhaps I need to see if I can
pick Christopher PeBenito's brain, as I gather he has some
involvement both in the SELinux community and the Gentoo community.
Yes he is both
maintainer for gentoo selinux policy as well as upstream tresys refpolicy
>SELinux is a framework that lets one define types and assign these types to subjects
and objects in a system. The framework also lets on define policy that governs how types
can interact with eashother. To make this possible, the kernel provides classes and
permission. if you put that together you get something like this:
>
>allow subjecttype_t objecttype_t:objectclass permissions;
>
>then theres the concept of (subject and object) type transitions. ( go from one type
to another type )
>
>Those are the basics of type enforcement. Then youll alsoo need to get familair with
how policy is structured upstream (they have some guidelines that make maintenance
easier)
>
>Then get to know the tools, and youre halfway there.
Ah, but therein seems to lie the rub for me: near as I can tell,
there were some major changes made in how the policy is written
somewhere around the late May/early June timeframe. All of the
documentation that I can find refers to the new framework, whereas
the policy I'm using appears to be based on the old framework. As a
consequence, just about the time I think I'm starting to get a
handle on what works how, I run into something that doesn't
correspond to what the SELinux docs are telling me.
A good is example is refpolicy itself: the policy explained at the
tresys site:
http://oss.tresys.com/projects/refpolicy/wiki/UseRefpolicy
Seems to be rather well thought ought, and reasonably logical and
orthoginal. It also seems to bear little resemblance to what I'm
using. The instructions for the tools that I come across seem to
mostly reference things that don't even exist for me, or if they did
exist would be absolutely useless to me because they are GUI tools,
and my systems don't even have X installed.
As far is a know the structure is pretty much the same
I realize that a good deal of this is almost certainly due to the
fact that I'm on Gentoo. I'd much rather be part of the solution
than part of the problem, so I want to get to where I can start
helping with Gentoo's SELinux implementation, but I'm so blasted
confused I don't even rightly know how to start.
As I've said previously, Gentoo SEEMS to be using policy and tools
from RHEL 4's incarnation of SELinux. That's all well and good,
EXCEPT that the documentation describing the policies and tools
seems to have gone wandering, so those of use poor schmucks stuck
schlepping through the muck of the previous generation's tools have
no clue where we are or where we are going, and since I don't even
have the source for the policies that I AM using, I'm stuck with my
finger up my nose going "Whuh?"
Well i am not sure but it is unlikely like El4. Any open source project should make the
source available so it should be somewhere..
And now, I think I've done enough whining for one day. ;)
Once again, thanks for your time.
Later,
Chris
--
fedora-selinux-list mailing list
fedora-selinux-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
4:38 p.m.
New subject: AVC Denials on UDEV
On 12/02/2009 05:21 PM, Dominick Grift wrote:
> Ah, but therein seems to lie the rub for me: near as I can tell,
> there were some major changes made in how the policy is written
> somewhere around the late May/early June timeframe. All of the
> documentation that I can find refers to the new framework, whereas
> the policy I'm using appears to be based on the old framework. As a
> consequence, just about the time I think I'm starting to get a
> handle on what works how, I run into something that doesn't
> correspond to what the SELinux docs are telling me.
>
> A good is example is refpolicy itself: the policy explained at the
> tresys site:
>
> http://oss.tresys.com/projects/refpolicy/wiki/UseRefpolicy
>
> Seems to be rather well thought ought, and reasonably logical and
> orthoginal. It also seems to bear little resemblance to what I'm
> using. The instructions for the tools that I come across seem to
> mostly reference things that don't even exist for me, or if they did
> exist would be absolutely useless to me because they are GUI tools,
> and my systems don't even have X installed.
>
As far is a know the structure is pretty much the same
There are a good many types, transitions, and helper macros that don't
seem to exist in the Gentoo policy.
> I realize that a good deal of this is almost certainly due to
the
> fact that I'm on Gentoo. I'd much rather be part of the solution
> than part of the problem, so I want to get to where I can start
> helping with Gentoo's SELinux implementation, but I'm so blasted
> confused I don't even rightly know how to start.
>
> As I've said previously, Gentoo SEEMS to be using policy and tools
> from RHEL 4's incarnation of SELinux. That's all well and good,
> EXCEPT that the documentation describing the policies and tools
> seems to have gone wandering, so those of use poor schmucks stuck
> schlepping through the muck of the previous generation's tools have
> no clue where we are or where we are going, and since I don't even
> have the source for the policies that I AM using, I'm stuck with my
> finger up my nose going "Whuh?"
>
Well i am not sure but it is unlikely like El4. Any open source project should make the
source available so it should be somewhere..
Good point. And pursuing that angle, I have in fact found the source
for the Gentoo policy. I'm digging through it now. Fortunately, the M4
macro language is pretty simple. ;)
Later,
Chris
5257
days inactive
5259
days old
selinux@lists.fedoraproject.org
4 comments
2 participants
participants (2)
-
Chris Richards -
Dominick Grift