RFC - SELinux module documentation

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC - SELinux module documentation

Sven Vermeulen-3
Hi all,

One of the "difficulties" of working with SELinux is that the policy that is
pushed by default is tailored towards a default installation using
unmodified locations and such.

The moment users start configuring their system (different PORTDIR for
Portage, other DocumentRoot for Apache, etc.) which, with Gentoo, is
considered common practice, people need to start configuring and tweaking
SELinux as well.

I've been thinking about how to proceed on this and came up with the idea of
having module information. An example for Apache can be found at
http://xrl.us/bkqkkp (image at http://xrl.us/bkqkk5 since g.o.g.o doesn't
use the regular location syntax for embedded files), another one is
available for Portage too (http://xrl.us/bkqkk7). Images are created through
docs.google.com and created to SVG (also in git), but converted to PNG for
rendering purposes (only <img .../> tag is supported).

Such a module information gives a general overview of the module structure
(picture with allowed domain transitions plus overview of the domains and
files) and then talks about hwo to use the module to suit your needs (file
contexts, booleans, semanage commands where needed, ...)

I have chosen separate guides for each module due to the large amount of
information. Another option was to create a huge book, but I think this is
easier as it will provide a simple URL syntax
(http://www.gentoo.org/proj/en/selinux/modules/MODULENAME.xml) instead of
the handbook one.

Comments, feedback, ... always appreciated.

Wkr,
        Sven Vermeulen

Reply | Threaded
Open this post in threaded view
|

Re: RFC - SELinux module documentation

pva0xd
Hi, Sven.

В Чтв, 02/06/2011 в 18:52 +0200, Sven Vermeulen пишет:
> I've been thinking about how to proceed on this and came up with the idea of
> having module information.

I'm not using Selinux, but if I understood idea correctly it looks good
for me. What I'd like to suggest is to discuss this idea on selinux
development list.

As for project page updates it really looks better with some milestones
and dates. May be it's good idea to add bug for each target and track
required changes (or absense of changes) in bugzilla.

As for support matrices. I'm not expert here, but afaik amd64 and x86
support Grsecurity/PAX for sure.

--
Peter.