Preview of changes to the Security susbystem for 2.6.36
in [Kernel]
|
Prev: [PATCH v2] dmaengine: Driver for Topcliff PCH DMA controller
Next: [PATCH] block: move blk_register_queue() before uevent is send out
From: Valdis.Kletnieks on 4 Aug 2010 02:30 On Wed, 04 Aug 2010 12:54:32 +0900, Tetsuo Handa said: > # killall -KILL sshd > # /usr/sbin/sshd -o 'Banner /etc/shadow' > # ssh localhost I am unable to replicate this behavior on my system with SELinux set to enforcing mode. However, it does happen (which is to be expected) when SELinux is set to permissive mode. % rpm -q openssh selinux-policy-mls openssh-5.5p1-18.fc14.x86_64 selinux-policy-mls-3.8.8-8.fc14.noarch Tested by by trying both /etc/issue and /etc/shadow as banner files - in permissive mode, both files would be displayed. In enforcing mode, /etc/issue would show up and /etc/shadow would not. In addition, checking of the actual policy source for ssh shows no entry for auth_read_shadow() for sshd_t, although it is present for many other systemd daemons that have a need to read it. So in enforcing mode, there's no rule allowing sshd to open /etc/shadow, so it won't open. Are you sure you weren't running in permissive mode when you tested this?
From: Tetsuo Handa on 4 Aug 2010 03:10 Valdis.Kletnieks(a)vt.edu wrote: > Are you sure you weren't running in permissive mode when you tested this? I'm running CentOS5.5 and RHEL6beta in enforcing mode with default configuration (TARGETED policy). > I am unable to replicate this behavior on my system with SELinux set to > enforcing mode. However, it does happen (which is to be expected) when SELinux > is set to permissive mode. So, MLS policy can stop this case, can't it? That's fine. But most people is using TARGETED policy, isn't it? How do you provide protection to those who don't use MLS policy? SSHD case is just an example which everyone can try handily. What I want to say is that it is up to application that how the application uses information if the application is allowed to access the information. Thus, we should try to control parameters that affect how the information is used as much as possible in addition to controlling whether the application can reach the information or not. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Christian Stroetmann on 4 Aug 2010 08:20 Aloha Testsu; Aloha Everybody; On the 04.08.2010 05:54, Tetsuo Handa wrote : > Valdis.Kletnieks(a)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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Valdis.Kletnieks on 4 Aug 2010 12:30
On Wed, 04 Aug 2010 16:00:21 +0900, Tetsuo Handa said: > Valdis.Kletnieks(a)vt.edu wrote: > > Are you sure you weren't running in permissive mode when you tested this? > I'm running CentOS5.5 and RHEL6beta in enforcing mode with default configuration > (TARGETED policy). > > > I am unable to replicate this behavior on my system with SELinux set to > > enforcing mode. However, it does happen (which is to be expected) when SELinux > > is set to permissive mode. > So, MLS policy can stop this case, can't it? That's fine. Apparently so. > But most people is using TARGETED policy, isn't it? > How do you provide protection to those who don't use MLS policy? I'll point out that the requirements to even *start* sshd in the MLS policy are much more stringent - basically, running /usr/sbin/sshd on the command line doesn't work because it can't transition from your context to the sshd context. Only init context to sshd is allowed. More crucially, your "breakage" is actually a non-issue, because under the targeted policy, launching sshd with a parameter that results in /etc/shadow being disclosed requires you to be root in pretty much any security context including unconfined_t - at which point you can access /etc/shadow *anyhow*. Who the hell actually *cares* that you can go through all the trouble of restarting sshd and then ssh'ing in to get a copy of a file, when you could just as easily 'cat /etc/shadow'? So what you're saying is that SELinux sucks because it doesn't prevent people who have a legitimate copy of the front door key from climbing in a third floor window. Remember what I said about having a *model*? For MLS, the model includes "/etc/ shadow is only accessible to specifically authorized processes". So care is taken to close down any and all side doors like asking sshd to do the dirty work for you. For the 'targeted' policy, the model is "Only a specified list of network-facing daemons is confined", and no care is taken to prevent authorized users from accessing files they already have legitimate access to. |