General interface question

[Dominick Grift]

On Wed, Dec 23, 2009 at 11:40:02AM +0000, Moray Henderson wrote:
> Dominick Grift wrote:
> >On Tue, Dec 22, 2009 at 04:44:40PM +0000, Moray Henderson wrote:
> >> How do you find out what module interfaces are available for you to
> >> use in your own policies?
> >
> >you can also fetch and prep the source rpm for selinux-policy and use
> the
> >enclosed makefile to run make html, which will generate a html page
> with
> >all interfaces, and their descriptions and info about how they can be
> used.
> >an example of the output of make html can be found here:
> >http://oss.tresys.com/docs/refpolicy/api/
> >
> >plus you can also use eclipse-slide which is a slide plugin for selinux
> >policy development.
> >
> >But the most easy way is to just grep -r
> /usr/share/selinux/devel/include
> >and see the interface file for its contents.
> 
> Thanks for your replies - they were helpful.  I'm slowly getting the
> hang of how refpolicy fits together.  So far I have only needed to use 8
> of the reserved words of SELinux policy language, so I must confess I
> find it a bit daunting to discover there are 5,419 available interfaces
> spread across 247 files in 5 subdirectories.  I suppose the trick is to
> know what you're looking for, so that you can find the one bit you need
> without having to understand the whole lot.

Indeed. Knowing the structuring and style rules helps. These are actually important if you want to be able to maintain your policy.

A bit of experience is sometimes helpful but the structure also tries to help
for example the layers (the dirs in /usr/share/selinux/devel/include)

If the target of the interaction is owned by a system service, you can look in the services layer.
if it is owned by a userapp; apps. if user domain; roles and system. etc.

Also the interface names should be prepended with the name of the module that provides it. This is also helpful if you want to determine in which module a interface is defined. Everything is carefully structured and grouped.

This grouping and structuring is done for two reasons (atleast)
- to keep source policy modules as small as possible. If you can group two lines or raw policy into one interface it saves one line of policy. With the amount of rules SELinux policy has this quickly saves much date for humans to sift throught.

- to centralize policy. Instead of scathering similar policy pieces all over the place. define it in a central place. This means if policy changes, we only have to edit it in a single place and it gets automatically propagated across. Instead of having to edit policy all over the place for a minor change.

any "macro" not specific to a target type can be found in /usr/share/selinux/devel/include/support. macros that group permissions (permission sets). Patterns: which are often used to define policy where the target type in a interaction is defined (declared) locally.

> 
> 
> Moray.
> "To err is human.  To purr, feline"
> 
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-selinux-list/attachments/20091223/56c9ea79/attachment.sig>