Re: Pass struct vfsmount to the inode_create LSM hook

[Tetsuo Handa]

Hello.

Andreas Gruenbacher wrote:
> > Therefore, TOMOYO Linux checks the combination of filename and argv[0]
> > passed to execve().
> So you are indeed trying to control the value of argv[0]? Well, good luck with 
> that, but it's totally insane. You are guaranteed to break some applications.
TOMOYO Linux ristricts argv[0] using allow_argv0 syntax.
"allow_argv0 /bin/bash -bash" to allow passing "/bin/bash" to filename and "-bash" to argv[0] .
"allow_argv0 /bin/gzip gunzip" to allow passing "/bin/gzip" to filename and "gunzip" to argv[0] .
"allow_argv0 /sbin/busybox cat" to allow passing "/sbin/busybox" to filename and "cat" to argv[0] .
No need to use allow_argv0 syntax if the basename of filename and basename of argv[0] are the same
(i.e. "allow_argv0 /bin/bash bash" is not required).
TOMOYO Linux doesn't unconditionally forbid passing different values for filename and argv[0].
TOMOYO Linux allows passing different values for filename and argv[0] only if it is allowed by allow_argv0 syntax.
Could you please explain me why this approach breaks applications?

> If /bin/cat and /bin/rm are binaries or hardlinks to the same busybox binary 
> (rather than symlinks), different profiles could be used for each of them.
It is true if all processes are kept under control (e.g. strict policy in SELinux).
If there is a process that is not kept under control (e.g. targeted policy in SELinux),
you can't protect the application.
For example, an administrator may wish to allow users run /bin/ls without applying profiles
because /bin/ls won't read/write the content of files. But a malicious user may pass
"/bin/ls" to filename and "rm" to argv[0] and "/etc/shadow" to argv[1].
A malicious user may pass "/bin/ls" to filename and "/usr/sbin/httpd" to argv[0],
resulting behave as /usr/sbin/httpd without applying profiles for /usr/sbin/httpd .

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/