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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 9 Jun 2007 15:44:31 +0200
From:	Andreas Gruenbacher <agruen@...e.de>
To:	Pavel Machek <pavel@....cz>
Cc:	jjohansen@...e.de, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [AppArmor 38/45] AppArmor: Module and LSM hooks

On Saturday 09 June 2007 14:58, 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. /proc only uses pathnames in a few places, 
> > but /proc/mounts will silently fail and produce garbage entries. That's 
> > not ideal of course; we should fix that somehow.
> 
> > Note that this has nothing to do with the AppArmor discussion ...
> 
> This has everything to do with AA discussion.

How pathnames are used in /proc has *nothing* to do with AppAmor.

> You took unreliable, for-user-info kernel subsystem, and made security
> subsystem depend on it. Oops.

Wrong. I said that the kernel uses pathnames for informational purposes only, 
not that they are unreliable. Don't turn words around in my mouth. The dcache 
has a *very* precise idea of pathnames, because this is what it is there for.

The pathnames that d_path computes exactly reflect what the dcache knows. 
(This requires the d_path fixes that are included in the AppArmor series and 
have also been posted independently, and the reasons why these fixes are 
needed are well explained in the mails.) The resulting pathnames are anything 
but unreliable.

> > > Perhaps vfs should be modified not to allow such crazy paths? But 
> > > placing limit in aa is ugly. 
> > 
> > Dream on. Redefining fundamental vfs semantics is not an option; we should 
> > rather make sure that we fail gracefully. Considering the
> 
> And instead of fixing "too long pathnames are problem in kernel" in any
> clean way, you "simply" included
> configurable-but-impossible-to-configure-right limit into
> apparmor. And now you want that merged. Dream on.

The choice here is between the following two things: either allow pathnames to 
grow to arbitrary lengths, or cap them at some point. The former has the 
benefit of working with all possible pathnames, and the drawback that users 
can consume arbitrary amounts of kernel memory by constructing arbitrarily 
long paths.

The latter has the benefit of limiting the amount of kernel memory consumed to 
some upper bound, and the drawback that access to exceptionally long paths 
(beyond the arbitrary limit) is denied. So in a sense, the limit in AppArmor 
does what you are asking for: it modifies things so that the kernel does not 
allow "such crazy paths". It does not introduce this as a vfs limit though, 
because the vfs has all right not to care.

Andreas
-
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/