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]
Message-ID: <20070612130630.GA11880@elf.ucw.cz>
Date:	Tue, 12 Jun 2007 15:06:30 +0200
From:	Pavel Machek <pavel@....cz>
To:	Andreas Gruenbacher <agruen@...e.de>
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

Hi!

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

Well, we know they are unreliable from other sources.

> 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.

Yes?

Like... everything but AA works with very long paths?

Like... deleted files handling, where AA used to pick random name?

Like... races during tree renames, where AA may use name file never
ever had?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ