| 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
| ||
|
Message-Id: <200706041630.49316.agruen@suse.de> Date: Mon, 4 Jun 2007 16:30:49 +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 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. /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 ... > 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 alternatives, I still prefer the configurable limit. That's way more useful than allowing a process to DOS the kernel with AppArmor. 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/
Powered by blists - more mailing lists