SELinux last straw

[Andrew Kelly]

On Wed, 2007-10-17 at 14:46 -0500, Arthur Pemberton wrote:
> On 10/17/07, Les Mikesell <lesmikesell at gmail.com> wrote:
> > Arthur Pemberton wrote:
> >
> > >> If I asked how to determine whether or not some particular access would
> > >> be permitted or denied by the traditional unix mechanism you wouldn't
> > >> have any trouble describing how to verify it in terms of permissions
> > >> down the file path.  I'm asking the same question about SELinux.
> > >
> > > 1) familiarize ones self with the rules , as one has to do with
> > > traditional secuirty
> >
> > But the traditional unix rules are extremely simple, and being able to
> > understand and verify them is one of their biggest virtues.
> >
> > > 2) or just try it and see if it is allowed or not
> >
> > When something applies only to a particular process, how can you try it
> > without running that process - which may have destructive side effects
> > if it fails?
> >
> > >> How, for example, would you determine if some change will make it
> > >> necessary to relabel?   How, other than running something and letting it
> > >> fail to get the log message, do you positively determine that some
> > >> specific access will be permitted or denied?
> > >
> > > perms can be viewed with `ls` and there is some command that provides
> > > the current settings.
> > >
> > > How would you do it with traditional tools?
> > >
> > The shortcut test is to su to the user in question and try to access the
> > file/device.  The only slightly more complicated way is to walk down the
> > path looking at the permissions for user/group/other on the file and the
> > directories above.
> 
> Well, these "traditional" methods didn't work for your friend Karl,
> since he was hacked with them.

What good is a bullet-proof vest when you're going to stick the gun in
your mouth anyway?