Date:	Wed, 04 Aug 2010 12:54:32 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	Valdis.Kletnieks@...edu
Cc:	hch@...radead.org, jmorris@...ei.org, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, viro@....linux.org.uk,
	kees.cook@...onical.com
Subject: Re: Preview of changes to the Security susbystem for 2.6.36

Valdis.Kletnieks@...edu wrote:
> That's why you need an actual model, not ad-hoc rules.  Start with "This program
> has data we don't want leaked, by ptrace or any other means".  Work from there.

/usr/sbin/sshd deals data (e.g. the content of /etc/shadow) which we don't want
leaked, by ptrace or any other means.

Please execute below commands on a system protected by SELinux, provided that
permissions to execute below commands are given.

# killall -KILL sshd
# /usr/sbin/sshd -o 'Banner /etc/shadow'
# ssh localhost

The person who manages SELinux's policy believes that /etc/shadow is not leaked
by the root user (e.g. "cat /etc/shadow" piped to "mail" command). But the root
user can be different from the person who manages SELinux's policy (it can be a
non-root user executing above commands using "sudo" command).

> But scribbling on /etc/passwd by using any of the 4,394 different known attacks
> against Linux except the 1 that Yama protects against isn't considered a
> problem.

Leaking the content of /etc/shadow by using "banner" option isn't considered a
problem, is it? What SELinux developers think "security" is not always same as
what Linux users and non SELinux developers think.

An app is dealing credit card information which we don't want leaked, by ptrace
or any other means. But that app needs to send mail in order to report results.
Who can prove that SELinux prevents that app from leaking credit card
information while keeping that app working? Nobody can.

SELinux is good at dealing read/write/execute permission and is a good solution
for isolating information. But SELinux is not a perfect solution for controlling
how the information is used (in other words, for what purpose the information
is used). I can't believe in "information flow control" or BLP model because
information itself cannot be labeled. Expecting LSM modules to guarantee "Data
dealt by this program is never leaked, by ptrace or any other means" sounds an
illusion for me.

TOMOYO is less good at dealing read/write/execute permission but is better at
dealing parameters (e.g. filename, command line arguments, environment
variables, DAC mode) that affect how the information is used. Although, TOMOYO
does not make any guarantee like BLP model, TOMOYO is addressing problems which
SELinux is not addressing.

> It will likely not be accepted as an in-tree LSM, especially given that currently
> it's rather difficult to stack two LSM's - which means that if a site wants to
> run Yama, it becomes unable to take advantage of all the *other* security
> features of SELinux or something similar.  In other words - if you want to be
> an LSM, you need to be full-featured enough to cover all the bases, not just
> a few cherry-picked ones.

If a site wants to run TOMOYO, it becomes unable to take advantage of SELinux.
No LSM module is full-featured enough to cover all the bases. TOMOYO was
accepted as an in-tree LSM nonetheless TOMOYO is covering only a few
cherry-picked ones.

I don't have a plan to make TOMOYO cover all the bases by reinventing what
SELinux/Smack already does. Rather, I want to stack/chain LSM modules so that
TOMOYO can be used with SELinux/Smack/AppArmor/Yama.

I'm not happy to keep Yama out-of-tree because of "Yama covers only a few
cherry-picked ones" and "LSM is not stackable/chainable".
I believe LSM should become stackable/chainable.
--
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/

Powered by blists - more mailing lists