Re: Preview of changes to the Security susbystem for 2.6.36

[Christian Stroetmann <stroetmann@ontolinux.com>]

Aloha Testsu; Aloha Everybody;
On the 04.08.2010 05:54, Tetsuo Handa wrote :
> Valdis.Kletnieks@vt.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.
>   

I don't think that the job of SELinux is the protection on the
application level, but on the operating system level.

> 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.
>   

That's why I argued that the Yama LSM can exist, but with own concepts
and methodes and not as a container for throwning in ad-hoc rules taken
from other security packages (if there exist other ways to get the
functionalities/features), please.

> 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.
>   

So that would mean a change of the LSM architecture to make it stackable
and in an additional step it could be changed that other security
packages that are no LSMs (grsecurity/Openwall/RSBAC/...) can become as
a whole an LSM and stackable/chainable so that they don't have to be
reinvented, or let us better say imported, by the Yama LSM. But this
would mean as well that then the actual Yama LSM is obsolete.

Have fun
Christian Stroetmann