Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSMhook

[Tetsuo Handa]

Hello.

Crispin Cowan wrote:
> AppArmor actually does something similar to this, by mediating all of
> the ways that you can make an alias to a file. These are:
> 
>     * Symbolic links: these actually don't work for making aliases with
>       respect to LSM-based security systems such as AppArmor, SELinux,
>       and TOMOYO Linux, because the symbolic link is resolved before the
>       access request is presented to the LSM hooks. So if you create the
>       symbolic link /tmp/harmless -> /etc/shadow and then the confined
>       victim tries to access /tmp/harmless, what the LSM sees is an
>       attempt to access /etc/shadow.
Yes, TOMOYO does so too.

Although TOMOYO is not using LSM, TOMOYO checks it by manually inserted hooks
that are called after resolving the symbolic links.

>     * Hard links: AppArmor explicitly mediates permission to make a hard
>       link to a file. To be able to make a hard link /tmp/harmless ->
>       /etc/shadow you have to have explicit permission to do so, or the
>       attempt to make the link is blocked. This mediation is kept
>       relatively simple by the fact that you can only hard link to
>       files, and not to directories.
Yes, TOMOYO does so too.

Conventional UNIX's access control can't restrict
which path_to_file can link with which another_path_to_file
because UNIX's access control is a label-based access control.
Therefore "ln /etc/shadow /tmp/harmless" becomes a problem
when introducing pathname-based access control.

TOMOYO checks the combination of both link source and destination,
using "allow_link path_to_link_source path_to_link_destination" syntax.
Therefore "ln /etc/shadow /tmp/harmless" is impossible as long as
"allow_link /etc/shadow /tmp/harmless" (or something like "allow_link /etc/\* /tmp/\*")
is not given. TOMOYO checks rename operation as well using
"allow_rename path_to_oldname path_to_newname" syntax.

>     * Multiple mounts: Linux lets you mount the same file system
>       multiple times at multiple mount points, so the same file could
>       appear at two different places. AppArmor has very coarse mediation
>       here, and simply prohibits all calls to mount() without special
>       permission. So only highly privileged processes can create such an
>       alias.
Yes, TOMOYO does so too.

But TOMOYO checks not only the capability to call mount() system call
but also the combination of "path_to_device" "path_to_mountpoint" and "filesystem_type"
using "allow_mount path_to_device path_to_mountpoint filesystem_type"
("allow_mount --bind path_to_bind_source path_to_bind_destionation" for bind mounts) syntax.

And, this is why this very long long thread began.
One of the reasons that TOMOYO doesn't use LSM is that
it is impossible to obtain "struct vfsmount" parameter inside some of LSM hook functions.
 From the label-based access control's point of view,
bind mount interferes nothing with label based access control
and passing "struct vfsmount" parameter looks redundant.
But, from the pathname-based access control's point of view,
bind mount interferes severely with pathname-based access control
because it is impossible to determine which pathname was requested.
Although both pathnames point to the same object,
TOMOYO focuses on the PROCEDURE FOR REACHING AN OBJECT
and being able to know the procedure is very important.
(In contrast, SELinux focuses on the ATTRIBUTE OF THE REQUESTED OBJECT, doesn't it?)

> So it could be done, but AFAICT, with small benefit and large cost. More
> security may be more secure, but it isn't necessarily better.
I don't think so.
I think the pathname-based access control and the label-based access control are
complementarity relation. TOMOYO can coexist with SELinux and AppArmor.
What is sad, it becomes impossible to coexist with SELinux and AppArmor if TOMOYO uses LSM.

Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/