[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1176825641.5946.41.camel@localhost.localdomain>
Date: Tue, 17 Apr 2007 12:00:41 -0400
From: Karl MacMillan <kmacmill@...hat.com>
To: David Safford <safford@...son.ibm.com>
Cc: James Morris <jmorris@...ei.org>,
John Johansen <jjohansen@...e.de>,
linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org,
linux-fsdevel@...r.kernel.org
Subject: Re: AppArmor FAQ
On Tue, 2007-04-17 at 11:03 -0400, David Safford wrote:
> On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
> > On Mon, 16 Apr 2007, John Johansen wrote:
> >
> Actually, this is pretty much how z/OS/RACF works. Labels and pathnames
> for all files are stored in one database. There are advantages and
> disadvantages to this design, but is does work, and does have an EAL4+
> certification on a Labeled Security Protection Profile.
>
> > And you can still use pathnames under SELinux to locate an object to
> > label, just as you do with DAC. You just don't put a security label on
> > the path itself.
>
> SELinux _has_ to use pathnames to fix some ugly cases where new files
> are created with the wrong label. It uses restorecond to fix the labels
> for files such as resolv.conf, mtab, utab, and wtab, when they are
> created. The restorecond policy file is textual, and separate from the
> SELinux labels, which is somewhat inelegant.
>
No - the real fix is to change the applications or to run under a policy
that confines all applications. Most of the problems with resolv.conf,
mtab, etc. stem from admin processes (e.g., editors or shell scripts)
all running under the same unconfined domain.
In some cases applications need modification as only the application has
enough information to determine the correct label. Usually this means
preserving labels from input files or separating the output into
distinct directories so type transitions or label inheritance will work.
restorecond is just a hack not a requirement or a sign that something is
wrong with the model. That is why it is a userspace application and not
integrated into the kernel mechanism.
Karl
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists