• 1

Re: I prefer AppArmor's approach.

(Anonymous)
Pathname-based security considered harmful - that is a basic security 101 lesson. A single file may be accessible under multiple distinct paths, each process can have its own distinct namespace (view of the filesystem tree), renaming a file should not change its protections automatically, the path-to-object mapping can change at runtime, and the pathname tells us nothing about the runtime security properties of an object.

Labeling the inodes with the security attributes and then using those security labels for the permission checks is the only approach to provide real enforcement of confidentiality and integrity guarantees, or any kind of information flow policy. It allows consistent protection of the objects no matter how they are named/referenced and allows the real security properties of the object to be bound to it. It also allows the policy to scale, by grouping subjects (processes) and objects into equivalence classes (types and levels) rather than having to consider each individual subject/object, and allows analysis of the policy for information flows independent of the current filesystem state (which may include millions of objects and be changing during runtime). Using the inode attributes is consistent with the existing Linux DAC checking, which bases its checking on properties of the inode (mode, owner, group), not the path by which it was accessed.

Further, only SELinux provides comprehensive control of all objects and operations in the system, which is also necessary to provide real security guarantees.

Re: I prefer AppArmor's approach.

(Anonymous)
I know the potential of SELinux's ability. But I think SELinux's approach is not user friendly. I want SELinux to consider pathname-based approach to become more user friendly.

> Labeling the inodes with the security attributes and then using those security labels for the permission checks is the only approach to provide real enforcement of confidentiality and integrity guarantees,
Why do we have to worry that security labels are kept correctly assigned? Fedora Core introduces a cron job to check security labels are kept correctly assigned, for there is a possibility of existence of a moment that security labels are incorrectly assigned. At the moment when security labels are incorrectly assigned, how SELinux (or any inode's security-label-based MAC) can provide real enforcement?

> A single file may be accessible under multiple distinct paths,
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.

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