[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070615170149.GA8799@kroah.com>
Date: Fri, 15 Jun 2007 10:01:49 -0700
From: Greg KH <greg@...ah.com>
To: david@...g.hm
Cc: Jack Stone <jack@...keye.stone.uk.eu.org>, agruen@...e.de,
sds@...ho.nsa.gov, jjohansen@...e.de, linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org,
linux-fsdevel@...r.kernel.org, pavel@....cz
Subject: Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation,
pathname matching
On Thu, Jun 14, 2007 at 05:18:43PM -0700, david@...g.hm wrote:
> On Thu, 14 Jun 2007, Jack Stone wrote:
>
> > david@...g.hm wrote:
> >> On Sun, 10 Jun 2007, Pavel Machek wrote:
> >>> But you have that regex in _user_ space, in a place where policy
> >>> is loaded into kernel.
> >>
> >> then the kernel is going to have to call out to userspace every time a
> >> file is created or renamed and the policy is going to be enforced
> >> incorrectly until userspace finished labeling/relabeling whatever is
> >> moved. building this sort of race condigion for security into the kernel
> >> is highly questionable at best.
> >>
> >>> AA has regex parser in _kernel_ space, which is very wrong.
> >>
> >> see Linus' rants about why it's not automaticaly the best thing to move
> >> functionality into userspace.
> >>
> >> remember that the files covered by an AA policy can change as files are
> >> renamed. this isn't the case with SELinux so it doesn't have this sort
> >> of problem.
> >
> > How about using the inotify interface on / to watch for file changes and
> > updating the SELinux policies on the fly. This could be done from a
> > userspace daemon and should require minimal SELinux changes.
> >
> > The only possible problems I can see are the (hopefully) small gap
> > between the file change and updating the policy and the performance
> > problems of watching the whole system for changes.
>
> as was mentioned by someone else, if you rename a directory this can result
> in millions of files that need to be relabeled (or otherwise have the policy
> changed for them)
>
> that can take a significant amount of time to do.
So? The number of "real-world" times that this happens is probably
non-existant on a "production" server. And if you are doing this on a
developer machine, then yes, there might be some slow-down, but no more
than is currently happening with tools like Beagle that people are
already shipping and supporting in "enterprise" solutions.
thanks,
greg k-h
-
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