• 1

Please understand what you are breaking

TOMOYO Linux uses canonicalized absolute pathname that contains no "//", ".", ".." and symbolic links (unlike AppArmor) to ensure a single file with link-count = 1 is accessed under unique pathname. A file need to be accessible under it's link-count's ways of paths because the file is designed to allow access under multiple distinct paths.

So, a file with link count > 1 has multiple security policies ... depending on the name used to access it. Unix has never done this, and it is mostly completely insanity.

each process can have its own distinct namespace (view of the filesystem tree),
TOMOYO Linux ignores each process's "/" directory (unlike AppArmor). (Even if a process is running under chroot()'ed environment, TOMOYO Linux derives canonicalized absolute pathname from outside the chroot()'ed environment.)

Please learn what namespaces are, it has nothing to do with chroot(). There is not a static canonical name for even a file with link count == 1, when you have namespaces.

That's not to say some path name analysis wouldn't be useful (allowing the webserver to serve anything accessed from /home/*/public_html without having to label files comes to mind or allow access to all files in /home/* is an obvious application), but it certainly can't be the only way to specify security.


Re: Please understand what you are breaking

(Anonymous)
Probably my explanation was incorrect.

TOMOYO Linux uses canonicalized absolute pathname that contains no "//", ".", ".." and symbolic links (unlike AppArmor) to ensure a single file with link-count = 1 is accessed under unique pathname. A file need to be accessible under it's link-count's ways of paths because the file is designed to allow access under multiple distinct paths.

was inappropriate. This should be

TOMOYO Linux uses canonicalized absolute pathname that contains no "//", ".", ".." and symbolic links (unlike AppArmor) so that the policy can specify a single file with link-count = 1 using 1 pathname. TOMOYO Linux's policy can specify a single file with link-count > 1 using it's link-count's ways of pathnames.



> So, a file with link count > 1 has multiple security policies ... depending on the name used to access it. Unix has never done this, and it is mostly completely insanity.
There are program files with link-count > 1. For example, busybox.
Why it is insanity to granting/rejecting access depending on the name used to access?
The busybox should be controlled depending on the name used to access, shouldn't it?



> Please learn what namespaces are, it has nothing to do with chroot(). There is not a static canonical name for even a file with link count == 1, when you have namespaces.
I'm sorry but I couldn't understand what you want me to figure out.
TOMOYO Linux controls access using canonicalized absolute pathname.
The canonicalized absolute pathname is derived based on the dynamic mount situation.
So, there is not a static canonicalized absolute pathname for a file.
TOMOYO Linux doesn't ensure that only resources whose security labels match the ones in the policy file are accessible.
TOMOYO Linux just ensures that only resources whose (dynamically derived) canonicalized absolute pathnames match ones (taken from a snapshot) in the policy file are accessible.

  • 1
?

Log in