• 1

I prefer AppArmor's approach.

(Anonymous)
I think pathname-based MAC used in AppArmor is better than security-label-based MAC used in SELinux.
Users and processes require access to resources using pathnames, not security-labels.
So, performing MAC using pathnames is more natural than doing it using security-labels.
Why not perform MAC based on pathnames?

NTT DATA CORPORATION (Japan) has released TOMOYO Linux, an implementation of pathname-based MAC like SubDomain, on November 11, 2005.

TOMOYO Linux can study MAC's policy like AppArmor.
This is because TOMOYO Linux uses pathname-based MAC.
If one security-label corresponds to multiple pathnames, security-label-based policy grants unnecessary access while pathname-based policy doesn't.

TOMOYO Linux can catch up with Fedora Core series that many users are choosing to "disable SELinux".
Changing TOMOYO Linux's policy doesn't require expertise.
You needn't to call a consultant just for a configuration change.

TOMOYO Linux is good at supporting customized programs that RedHat hasn't written policy for.
Many business applications developed by newbie programmers are running on Linux, they are not developed by RedHat and the administrator have to write policy for such applications.
Such applications tend to have more vulnerabilities (such as buffer overflows and directory traversals) than applications provided by distributors.

Though TOMOYO Linux doesn't have GUI tools, TOMOYO Linux is enough easy to manage using only CUI tools.

I think the time to review LSM is approaching.
TOMOYO Linux didn't use LSM because "the location of hooks" and "the parameters passed to hooks" and "the granularity of capability" are not enough.
I see AppArmor has struggled deriving absolute pathname inside LSM's hook function.
TOMOYO Linux derives absolute pathname outside VFS function, making MAC's code and policy much simpler and easier to manage.

Just try the KickStart for Debian Sarge on http://tomoyo.sourceforge.jp/en/kickstart/ .
You will find the advantages of pathname-based MAC.

Papers: http://sourceforge.jp/docman2/ViewCategory.php?group_id=1973&category_id=531&language_id=1
Project: http://tomoyo.sourceforge.jp/

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