Re: [AppArmor 38/45] AppArmor: Module and LSM hooks

[Stephen Smalley]

On Mon, 2007-06-11 at 01:10 +0200, Andreas Gruenbacher wrote:
> On Wednesday 06 June 2007 15:09, Stephen Smalley wrote:
> > On Mon, 2007-06-04 at 16:30 +0200, Andreas Gruenbacher wrote:
> > > On Monday 04 June 2007 15:12, Pavel Machek wrote:
> > > > How will kernel work with very long paths? I'd suspect some problems,
> > > > if path is 1MB long and I attempt to print it in /proc
> > > > somewhere.
> > > 
> > > Pathnames are only used for informational purposes in the kernel, except 
> > > in AppArmor of course.
> > 
> > I don't mean this as a flame, but isn't the above statement the very
> > crux of this discussion?
> 
> I think the question at the core of it all is, shall a pathname based security 
> mechanism be allowed. I was under the impression that this question had 
> already been answered affirmatively. If the answer here was no, then we could 
> stop the entire discussion right there.

There is a difference between using the pathname at the kernel/userland
interface as part of configuring a security mechanism and using it as
the basis for the runtime checking itself.  Further, there is a
difference between generating and matching full pathnames on each access
vs. caching information in the parent dentry and making decisions based
on that cached information and the last component-name.  The only
question I saw being answered was the abstract one of "can a pathname
play a role in the security mechanism" not "should the kernel be
regenerating a full path on each open and glob matching it against a
list of file globs."

> > Why should AppArmor be different from the rest of the kernel in its usage of
> > pathnames (basis for decisions vs. informational reporting to userspace)? 
> > And if it is ok for AppArmor to generate and use pathnames as its basis of
> > decisions on each open, then is it also ok for audit, inotify, and others to
> > use them in the same manner?
> 
> Audit and inotify don't make any decisions based on pathnames, or on SELinux 
> labels for that matter, they only report. That being said, sure those parts 
> of the kernel that report pathnames should report them correctly -- I guess 
> there is no disagreement about that.

>From a userland perspective, audit and inotify allow you to specify
watches on pathnames, and those watches trigger actions by the audit and
inotify subsystems when those files are accessed.  The kernel mechanism
however is inode-based, not pathname-based; the pathname is merely
looked up when the watch is added and mapped to an inode.  That's my
point - why should AA be different?  Would you really recommend that
audit or inotify call d_path() on each open and glob match the result
against a list of audit or inotify watches?  BTW, audit does allow
filters on SELinux labels these days.

> > Another question:  it seems like the read-only bind mount folks gave up
> > on propagating the vfsmounts down and switched to a rather different
> > approach (checking near the entry points, using mount writer counters).
> > So similarly, what makes AppArmor fundamentally different that it
> > wouldn't take a similar approach to what they are doing vs. propagating
> > the vfsmounts down?
> 
> Without the vfsmounts propagated down you won't know the pathnames. Whether 
> or not a different problem can be solved without the vfsmounts is not really 
> relevant.

Well, that presumes that your mechanism has to generate full pathnames
on each access check.  But even if so, you could be doing your checking
in the higher level code then where you have a vfsmount available.

-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/