linux-kernel - Re: [RFC] TOMOYO Linux

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1181763466.17547.502.camel@moss-spartans.epoch.ncsc.mil>
Date:	Wed, 13 Jun 2007 15:37:46 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Toshiharu Harada <haradats@...il.com>
Cc:	Toshiharu Harada <haradats@...data.co.jp>,
	linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [RFC] TOMOYO Linux

On Wed, 2007-06-13 at 23:22 +0900, Toshiharu Harada wrote:
> 2007/6/13, Stephen Smalley <sds@...ho.nsa.gov>:
> > 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.

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?

-- 
Stephen Smalley
National Security Agency

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