[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: SELinux Understanding



On Tue, Oct 16, 2007 at 08:59:36 -0400,
  Claude Jones <cjones levitjames com> wrote:
> On Mon October 15 2007, Bruno Wolff III wrote:
> > On Mon, Oct 15, 2007 at 13:57:11 -0400,
> >
> >   Claude Jones <cjones levitjames com> wrote:
> > > On Monday October 15 2007 1:35:17 pm Nigel Henry wrote:
> > > > but as
> > > > re-enabling SELinux, in either permissive, or enforcing mode
> > > > results in the relabelling process being run, it's almost
> > > > impossible to know if the relabelling has resolved a genuine
> > > > problem or not.
> > >
> > > This is where you're mistaken. It's perfectly possible to set
> > > permissive and enforcing modes, without relabeling - relabeling
> > > is only forced after some updates, and that not very often -
> > > perhaps, this is something that should be addressed. Perhaps a
> > > warning message when you turn on enforcing, with instructions to
> > > relabel if you've run in permissive mode for some period of
> > > time...
> >
> > If you have run with selinux disabled, when you reenable it you are going
> > to need to check file labels. Any files created while selinux was disabled
> > are not going to be properly labelled.
> >
> > Even rebooting a machine can fix a problem, since that will effectively
> > relabel processes. So if an update didn't happen correctly, a reboot may
> > fix the problem and getting back to the preupdate state may take some
> > work.
> 
> Are you objecting to what I said? I'm not sure, really. All I'm saying is that 
> re-enabling SELinux doesn't automagically run the relabelling process as 
> Nigel seems to be asserting - there are several ways to trigger a relabel on 
> next reboot, but one has to issue a command to make that happen, or at least 
> that's the way it used to work - I keep SELinux on, and have for a couple of 
> years, now, so things may have changed since I last had it disabled. 

In the context of testing I am suggesting there are some of reasons that
you might not get back to the same conditions you had previously which
might make it harder to reproduce a problem then was suggested by your
commentary.

You are correct that normally when updating or when switching back and forth
between permissive and enforcing you aren't supposed to need to do a relabel.
And that a mass relabel is not done automatically. (Updates may relabel some
files or processes as part of doing the update.)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]