Re: [RFC] TOMOYO Linux

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2007/6/13, Stephen Smalley <[email protected]>:
On Wed, 2007-06-13 at 17:13 +0900, Toshiharu Harada wrote:
> Here are examples:
> /bin/bash process invoked from mingetty: /sbin/mingetty /bin/bash
> /bin/bash process invoked from sshd: /usr/sbin/sshd /bin/bash
> /bin/bash process invoked from /bin/bash which was invoked from sshd: /usr/sbin/sshd /bin/bash /bin/bash

Why can't you do this via SELinux domain transitions?  That lets you do
it by equivalence class rather than per-binary, and let's you just
encode the security-relevant parts of the "invocation history" aka call
chain.  For example, the above could be expressed in SELinux policy
already as:
        domain_auto_trans(getty_t, shell_exec_t, local_shell_t)
        domain_auto_trans(sshd_t, shell_exec_t, remote_shell_t)
        domain_auto_trans(remote_shell_t, shell_exec_t, remote_subshell_t)
or whatever you like.  But you don't have to keep extending it
indefinitely when you don't need to distinguish in policy, so you might
choose to entirely omit the last one, and just have it stay in
remote_shell_t.

The above SELinux policy looks similar to the one I wrote, but
that is not very true.  Because in my example, path name corresponds to a file
while local_shell_t are bound to multiple.
I understand the advantages of label, but it needs to be
translated to human understandable form of path name.
So I think pathname based call chains are advantages for
at least auditing and profiling.

--
Toshiharu Harada
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux