Re: [TOMOYO 5/9] Memory and pathname management functions.
On 6/21/07, Pavel Machek <[EMAIL PROTECTED]> wrote: > >> It's really not worth getting bothered by. Truth is, big > >> giant > >> pathnames break lots of stuff already, both kernel and > >> userspace. > > > >> Just look in /proc for some nice juicy kernel breakage: > >> cwd, exe, fd/*, maps, mounts, mountstats, root, smaps > > > >Well, but we should be fixing that, not adding more. And /proc is > >info-only, while this is security related code. > > Security tools read from /proc, so /proc is security-related. If some tool relies on pathnames in /proc, that tool is broken... as is /proc. We should be fixing that. Running TOMOYO or AppArmor fixes the bug. :-) You can't get long paths that break /proc if you are running either. Therefore, one of those is required. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 5/9] Memory and pathname management functions.
Hi! > >> It's really not worth getting bothered by. Truth is, big > >> giant > >> pathnames break lots of stuff already, both kernel and > >> userspace. > > > >> Just look in /proc for some nice juicy kernel breakage: > >> cwd, exe, fd/*, maps, mounts, mountstats, root, smaps > > > >Well, but we should be fixing that, not adding more. And /proc is > >info-only, while this is security related code. > > Security tools read from /proc, so /proc is security-related. If some tool relies on pathnames in /proc, that tool is broken... as is /proc. We should be fixing that. > The limit imposed by TOMOYO (or AppArmor) is fine, > despite being security-related. It just needs to fail in It is not "fine", but maybe it will not get us a bugtraq posting. 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 5/9] Memory and pathname management functions.
On 6/15/07, Pavel Machek <[EMAIL PROTECTED]> wrote: [Albert Cahalan] > It's really not worth getting bothered by. Truth is, big > giant > pathnames break lots of stuff already, both kernel and > userspace. > Just look in /proc for some nice juicy kernel breakage: > cwd, exe, fd/*, maps, mounts, mountstats, root, smaps Well, but we should be fixing that, not adding more. And /proc is info-only, while this is security related code. Security tools read from /proc, so /proc is security-related. The limit imposed by TOMOYO (or AppArmor) is fine, despite being security-related. It just needs to fail in the safe direction: access denied. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 5/9] Memory and pathname management functions.
Hi! > >>We limit the maximum length of any string data (such as > >>domainname and pathnames) to TOMOYO_MAX_PATHNAME_LEN > >>(which is 4000) bytes to fit within a single page. > >> > >>Userland programs can obtain the amount of RAM > >>currently > >>used by TOMOYO from /proc interface. > > > >Same NACK for this as for AppArmor, on exactly the same > >grounds. > >Please stop wasting your time on pathname-based > >non-solutions. > > This issue is a very very small wart on an otherwise > fine idea. > It's really not worth getting bothered by. Truth is, big > giant > pathnames break lots of stuff already, both kernel and > userspace. > Just look in /proc for some nice juicy kernel breakage: > cwd, exe, fd/*, maps, mounts, mountstats, root, smaps Well, but we should be fixing that, not adding more. And /proc is info-only, while this is security related code. 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 5/9] Memory and pathname management functions.
Christoph Hellwig writes: On Thu, Jun 14, 2007 at 04:36:09PM +0900, Kentaro Takeda wrote: We limit the maximum length of any string data (such as domainname and pathnames) to TOMOYO_MAX_PATHNAME_LEN (which is 4000) bytes to fit within a single page. Userland programs can obtain the amount of RAM currently used by TOMOYO from /proc interface. Same NACK for this as for AppArmor, on exactly the same grounds. Please stop wasting your time on pathname-based non-solutions. This issue is a very very small wart on an otherwise fine idea. It's really not worth getting bothered by. Truth is, big giant pathnames break lots of stuff already, both kernel and userspace. Just look in /proc for some nice juicy kernel breakage: cwd, exe, fd/*, maps, mounts, mountstats, root, smaps So, is that a NACK for the /proc filesystem too? :-) We even limit filenames to 255 chars; just the other day a Russian guy was complaining that his monstrous filenames on a vfat filesystem could not be represented in UTF-8 mode. Both TOMOYO and AppArmor are good ideas. At minimum, one of them ought to be accepted. My preference would be TOMOYO, having origins untainted by Novell's Microsoft dealings. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 5/9] Memory and pathname management functions.
Christoph Hellwig wrote: On Thu, Jun 14, 2007 at 04:36:09PM +0900, Kentaro Takeda wrote: We limit the maximum length of any string data (such as domainname and pathnames) to TOMOYO_MAX_PATHNAME_LEN (which is 4000) bytes to fit within a single page. Userland programs can obtain the amount of RAM currently used by TOMOYO from /proc interface. Same NACK for this as for AppArmor, on exactly the same grounds. Please stop wasting your time on pathname-based non-solutions. TOMOYO Linux is a pathname-based MAC, that is true. But what that patch aimed for was sharing the idea of having Linux kernel to keep "process invocation history" information for each process. In that sense, TOMOYO Linux is just a sample implementation. Please take a look at the following message: http://lkml.org/lkml/2007/6/13/58 Best regards, Toshiharu Harada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TOMOYO 5/9] Memory and pathname management functions.
On Thu, Jun 14, 2007 at 04:36:09PM +0900, Kentaro Takeda wrote: > We limit the maximum length of any string data (such as domainname and > pathnames) > to TOMOYO_MAX_PATHNAME_LEN (which is 4000) bytes to fit within a single > page. > > Userland programs can obtain the amount of RAM currently used by TOMOYO > from /proc interface. Same NACK for this as for AppArmor, on exactly the same grounds. Please stop wasting your time on pathname-based non-solutions. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
