[DSE-User] Newbie question: getting rid of all those messages

[Erich Schubert]

Hello Kevin,
> So here is my questions: if I create a policy (or follow some tip in the
> wiki) for everything, would all of those 'denied' message stop? And as a
> way to chart the progress of the process, I would assume that every time
> I see less 'denied' messages, some policy is working and thus not
> producing those 'denied' messages.

Well, it's not the policy producing the denied messages.
It's the lack of policy producing them. SELinux is deny-by-default.
Yes, you can take the number of "denied" messages as a measure on how
fit your policy is. Less messages means some behaviour of your system
was accepted by the policy (may it be due to bugs in the application
being fixed or due to policy allowing this 'new' behaviour).
Note that every now and then applications start behaving differently.
For example sysvinit in Debian will now mount some /lib/init/rw ramdisk.

> And, is there any HOWTO to use the 'denied' message to create a policy
> from them, if that is possible.

There is a tool, audit2allow, that can do such transformations.
But that approach is broken by design.
You want to understand "why" the application is doing something, not
"how".

Thats why we don't just write lots and lots of
allow foobar_t gnarf_t:file write;
- that becomes a totally unreadable mess. Thousands of lines, with no
logic sorting among them. Unmaintainable.

You need to understand first why the application is causing the audit
error.
Then you can decide on whether to:
- ignore it ("dontaudit"), e.g. ioctl by awk() on regular files...
- allow it
- add new types, type transitions and allow the access only by the new
types.

The last option is often the proper way to do it, but can't be automated
very well. Also the decision between the first two can't be automated.

> Also, I did try to turn on the policy in my grub menu.lst and of course
> it couldn't get past init, but you knew that already x-).

Yep. Enforcing doesn't work too well yet, especially with recent changes
to init scripts...

> Any way, keep up the good work and hoping SELinux can get into etch (or
> maybe just the basic tools and policy).

I don't think we'll have out-of-the-box SELinux support in etch, unless
someone
writes policy for the new init behaviour (that is the new ramdisk), for
fsck init scripts (that need to be able to save their logs, approach #3
above should be taken here; this will also require changes to the
scripts) ...

> ps. I use exim so that is not going to get a working policy in the near
> future, oh well.

... and exim, of course. Someone with experience in writing SELinux
policy should be able to do a preliminary exim policy in 1-2 hours. If
he knows how exim works, to pick reasonable types, path names etc.

best regards,
Erich Schubert
-- 
    erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C    (o_
       To be trusted is a greater complement than to be loved.       //\
  Gute Freunde sind wie Sterne in der Nacht. Auch wenn sie manchmal  V_/_
       hinter den Wolken sind, weißt Du, sie sind für dich da.