On Sunday 01 December 2013 09:41:42 Nico Kadel-Garcia wrote:
> On Sat, Nov 30, 2013 at 3:31 AM, ToddAndMargo <[log in to unmask]> wrote:
> > Hi David,
> > 
> >   Loved the article.  I understood all about the cartoons and
> > 
> > the dogs and cats.  Perfectly done.  Unfortunately, when the
> > real world kicked in: zoom, right over my head.
> > 
> >   Who sets up these labels and how is that done?  Some GUI
> > 
> > for this?
> 
> In theory, people like David, when creating RPM packages, incorporate
> some guidelines. And in testing, one can set SELINUX to "permissive",
> and record what violations are being reported. With that in hand, and
> some system knowledge, you can tune the SELinux settings, update the
> package installers, and go another round.
> 
> In practice? Few developers are willing to help write good packages,
> and many completely ignore the File System Hierarchy, so they wind up
> putting stuff in all *sorts* of places. And it winds up the RPM
> authors'  problem to straighten out any SELinux conflicts. Our friends
> upstream at Fedora and Red Hat are pretty good about it. But when
> developing home or buisiness layouts with personnel who've not dealt
> with it, it's usually easier to just turn SELinux off or set
> permissive, and try to clean up if and when you have cycles.

Authors with good ideas and no understanding of the system they are writing 
for are the bane of Fedora packagers. (In Fedora there are all these rules and 
things...) That said, audit2allow goes a long way to letting a user painlessly 
generate a custom policy from the audit logs generated in permissive mode. 
Understanding how to do this requires a bit of reading, though -- I'm not sure 
if that functionality has all made it to the GUI. Speaking of which, I'm not 
sure that the GUI bits are in SL, but I know they are in Fedora (and probably 
EPEL?).

On really huge software systems audit2allow is insufficient and a unique 
domain/policy needs to be deliberately created. In large systems the 
occurrence of critical activities might be so rare (once a month or perhaps 
just randomly based on an event/condition) that not everything that needs to 
be allowed can be captured in the audit logs in a reasonable amount of time. 
Complex, long-running server-side stuff like Apache (or even desktop packages 
like certain browsers that think they are window managers themselves) can fall 
into this category, and in those cases its a big deal to have packagers and 
developers talking. In most cases, though, audit2allow is entierly sufficient 
and easy to use once you understand it.

That is assuming, of course, that you care about locking things down on your 
system -- there is strong historical evidence to support the view that most 
consumers couldn't care less about security, privacy or their own property 
rights so long as the digital haze they experience is sufficiently 
distracting. Hence the developers' conundrum: users prefer insecure systems 
with lock icons on everything to systems that are even partially secure.