Stephen Smalley wrote:
On Wed, 2007-06-13 at 23:22 +0900, Toshiharu Harada wrote:
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.
Well, not to get into a debate, but think about whether
"/usr/sbin/sshd /bin/bash" and "/sbin/mingetty /bin/bash" is more
understandable to an administrator than "remote shell" vs. "local shell"
- the label-based approach lets you map the low-level detail of
individual programs/pathnames to abstract equivalence classes that are
more understandable, not less. Further, think about the advantages of
being able to encode only the security-relevant invocations, not all of
them.
With our sample implmentation of "automated process invocation
history tracking system" (or TOMOYO Linux, in short :)),
no domain transition design and definition is needed.
All you have to do is just run the kernel.
So limiting to encode does not matter much.
On a different note, from a quick look, it looks like TOMOYO is AppArmor
+ invocation history from a user perspective. Plus a wider range of
controls in your original implementation, but your LSM implementation
seems to be just getting started and only deals with files. So what's
the case for having a whole separate security module vs. a small
extension to AppArmor?
The reason we cut off various MAC controls was to make
the code as small as possible (we knew lkml readers are busy).
If AA would merge the TOMOYO Linux's "automated proccess
invocation history tracking system" and "real-time policy
learning system", I would be fine.
Cheers,
Toshiharu Harada
-
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]
