The following is a summary of changes to the security subsystem for the 2.6.36 kernel, which may be found in my development tree at: git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next One issue which needs to be addressed is to confirm that there is consensus on the new Yama LSM module. I had thought there was, based on list discussion, but have since had differing feedback. ---- Arnd Bergmann (2): ima: use generic_file_llseek for securityfs selinux: use generic_file_llseek Chihau Chau (1): Security: capability: code style issue Dan Carpenter (9): smack: opt_dentry is never null in in smack_d_instantiate() KEYS: Propagate error code instead of returning -EINVAL selinux: cleanup return codes in avtab_read_item() selinux: propagate error codes in cond_read_list() selinux: fix error codes in cond_read_av_list() selinux: fix error codes in cond_read_node() selinux: fix error codes in cond_policydb_init() selinux: fix error codes in cond_read_bool() selinux: fix error codes in symtab_init() David Howells (3): KEYS: Authorise keyctl_set_timeout() on a key if we have its authorisation key KEYS: Make /proc/keys check to see if a key is possessed before security check KEYS: Use the variable 'key' in keyctl_describe_key() Eric Paris (8): SELinux: seperate range transition rules to a seperate function SELinux: move genfs read to a separate function SELinux: break ocontext reading into a separate function vfs: re-introduce MAY_CHDIR security: make LSMs explicitly mask off permissions SELinux: special dontaudit for access checks selinux: place open in the common file perms SELinux: Move execmod to the common perms James Morris (3): Merge branch 'next-queue' into next AppArmor: update path_truncate method to latest version Merge branch 'master' into next-preview John Johansen ...
I'm going to revert the Yama stuff for 2.6.36 -- Christoph has nacked it to me off-list. - James -- James Morris <firstname.lastname@example.org> --
Well, at least I'll have something for my summit presentation again. On the other hand, it's rather hard for me to defend against a private NAK. Care to describe the reasoning in public, Christoph? James, will it stay in security-testing for .37 hopefully? -Kees -- Kees Cook Ubuntu Security Team --
It's the same nak as before -- I concluded there was consensus on the Not with this approach, I'd imagine. - James -- James Morris <email@example.com> --
I'm sorry to appear dense, but the most recent NAK from Christoph was here, which was for a patch to Yama that is not in security-testing yet. Prior to that, all I could find was this which explicitly asked me to put stuff in a special LSM. I really would like to see it in mainline, but next steps are not clear. -Kees  http://lkml.org/lkml/2010/6/30/31  http://lkml.org/lkml/2010/6/1/78 -- Kees Cook Ubuntu Security Team --
Aloha James, Aloha Kees; A private NAK against a company's developer's OK Where is the difference private and company? I thought that it doesn't The opinion as well as the NAK by Christoph was discussed and supported Yes, because it supports as an experiment the development of the LSM That is not quite right. It is correct that this special Yama LSM was accepted so far. The inclusion into mainline was not an issue at that time. But we discussed as well that the problem of chaining of small or large LSMs is not an argument for the existence of the Yama LSM, and that the LSM architecture should be developed further so that all of the functionalities of other securtiy packages without an LSM can be integrated as a whole by a new version of the LSM system in the future and not by ripping them of like it was done with the Yama LSM . You can see these objections  as a second NAK, but now from a company's developer (I haven't said this before, because I'm not a hard  http://lkml.org/lkml/2010/6/30/64 Have fun in the sun Christian Stroetmann --
Hi Christian, I'm not sure I understand you, exactly. Are you saying that Yama should not exist because it might grow into a large LSM? -Kees -- Kees Cook Ubuntu Security Team --
Well, trying to get these protections into mainline does seem to be demonstrating a need for some kind of security architecture that isn't LSM. As for chaining, I was considering introducing basic "first non-zero return code wins" chain of LSMs, but the chain could include only up to 1 LSM that implements the proc attr hook (though the prctl handler isn't non-zero but rather non-ENOSYS). -Kees -- Kees Cook Ubuntu Security Team --
That's not what private means in this case. A private nak is one made in a private email, so that the list - and the submitter - can't see the rationale. It is problematic because it doesn't really allow the other party to address the objection. (No big deal - Christoph has since responded in public.) -serge --
Aloha Serge; Sorry, but AFAIK the NAK by Christoph that I meant was written in a public e-mail with full context to the LSM mailing list some weeks ago around the end of June (23 June 2010?!) and I thought Kees meant this NAK. :D But thanks for trying to clearify the case. Sorry Kees, if you indeed meant with private NAK a NAK made in a private e-mail. Have fun Christian Stroetmann --
I'm also happy to do it on-list, but I really didn't want to do it before I've actually validated the patches in your tree still are the same that were objected before. As mentioned a few times during the past discussion moving broken code into a LSM doesn't magically fix it. In fact YAMA is not any kind of (semi-)coherent security policy like Selinux, smack or similar but just a random set of hacks that you didn't get past the subsystem maintainers. Al gave you some very clear advice how a the sticky check should be done for symlinks (if we need it at all, which I tend to disagree with), and the ptrace check completely breaks crash handlers that we have in all kinds of applications. If you can get it into the main ptrace code past Roland and Oleg that's fine, but just pushing it out into a tree that has percieved easier merge criteria doesn't work. --
Hi Christoph, I would love to have these "hacks" in the subsystem directly. But no one has stepped forward to decode Al Viro's hints. I'm getting pretty tired of moving this logic back and forth between the subsystems and an LSM. You yourself told me to put these things in an This is patently false. "Very clear advice" would have included actionable instructions. He (and everyone else) has ignored my requests for clarification. If you see how the check should be implemented, please send a patch demonstrating how. I would greatly prefer having these I can see how one might disagree with it, but anyone who handles day-to-day security threats understands this protection to be a clear and obvious I've seen two so far. Both are addressed with a one line fix. And I would stress that no other existing subsystem in the kernel can provide the same level of control that my ptrace exception logic provides. SELinux cannot do This advice is precisely counter to prior advise. It would seem that no one knows how to handle these patches. I find it very simple; either: - let me put them in an LSM that people can choose to enable - help me get the patches into shape for the subsystems directly Since the latter has been repeatedly denied, the former was suggested to me, which I implemented. The option "give up" is not available to me. Perhaps there is another option I could choose from so I can get these protections into the mainline kernel? -Kees  http://lkml.org/lkml/2010/6/1/78  http://lkml.org/lkml/2010/6/4/44 -- Kees Cook Ubuntu Security Team --
You're overlooking step zero of Al's advice: First, *think* about the issue in a deep fashion, rather than a knee-jerk patch to fix one instance of The problem is that although your patch closes *one set* of symlink attacks that has been traditionally a problem, it doesn't do a very good job of creating a conceptual model and then *really* dealing with the issue. That's the big distinction between SELinux, Tomoyo, Smack, and your proposal - they form a *model* of what's important to protect, and what actions need to be taken to *actually* protect them. They don't just apply one arbitrary rule that closes some attacks - they make an honest effort to deal with all variants of the attack, and other attacks that allow bypass, and so on. The reason people are worried that this might grow into a "large" LSM is that quite often, throwing in a bunch of ad-hoc rules may create *apparent* security, but not provide any *real* security. You yourself admit that Yama only closes one set of symlink attacks without addressing the general issue of symlinks, hard links, TOCTOU races, and a lot of *other* similar "the file you actually opened is not the one you intended to open" attacks. And the reason it doesn't address the general issue is because it lacks a security model. And the reason you're having so much trouble getting it into the tree is because if you're going to apply this at either the VFS or LSM layers, you need to address the *general* problem and not one ad-hoc variant of it. And quite frankly, the idea of this morphing into a "large" LSM containing a lot of ad-hoc rules scares most security people, because without a good conceptual model, it's hard to define if the security is in fact working, or Quick question: Now is that "SELinux doesn't consider the added granularity important and doesn't bother doing it", or "SELinux can't do it *currently*", or "there are innate structural reasons why SELinux is by design unable to do it"? Note that it's a big difference, and it's ...
I think this is unfair. This solution has been used for 15 years in other hardened kernel patches. It's not knee-jerk at all. Not fixing this is not Okay, thanks for this explanation of why people don't want Yama as an LSM. I disagree with the logic, but at least I understand the reasoning now. "Since Yama does not provide a security model, it cannot be an LSM." This then leaves a gap for people wanting to make small changes to the logic of I can accept this as a theoretical position, but it's not like I've suddenly invented some new unproven protection. Given a choice between fighting to have it be an LSM and fighting to have it in the VFS, I prefer Well, here we disagree. DAC is flawed, this fixes a giant class of security problems. The model is "fix what sticky means for symlinks" and "fix when I have regression tests for all the Yama features. I can prove if it's I don't know the answer to this, but other people I've asked have said they didn't think it was possible. I would tend to agree since it requires an explicit action from the debugee. MAC is system-owner defined. This is programmer defined. I want my program to be able to declare that a single specific pid can PTRACE it and nothing else. Another example of programmer defined access control would be the ability to "give up" access to syscalls, a finer-grained version of Cross-uid symlink following and cross-permission hardlink creation are flaws in DAC that lead to a large persistent class of ToCToU vulnerabilities that are trivially avoidable. It's been fixed for 15 years. I'm not exactly sure how to model this. We've discussed how shared /tmp is one aspect of the problem, but it's not the entire problem. We've discussed how per-user /tmp is untenable in the short-term, etc. This is a way to get there now while per-user /tmp is slowly adopted over the next 15 years. -Kees -- Kees Cook Ubuntu Security Team --
The fact that a patch for one case has been used for years doesn't mean 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. You're of course free to keep a patchset that adds a private LSM, which should be fairly immune to inter-release changes because the LSM hooks are pretty That's not a model. A model is "these are the things that need to be protected, these are the threats/attacks, and here are the ways we do to protect". I won't disagree with the concept that DAC isn't usually sufficient - the point is that ad-hoc fixes for the low-hanging fruit isn't doing anybody The problem is that "proving it does what it claims" and "proving it actually provides security" are two very different things. If somebody attacks via a different symlink attack than Yama checks for, is it a Yama failure? If somebody attacks via a non-symlink attack, was that a Yama failure or no? If I find a way to trick SELinux into allowing me to scribble on /etc/passwd, that's an SELinux failure. If I find a way to do an end-run around Tomoyo, or Smack, or AppArmor, that's a failure. And if I write to the SELinux or Tomoyo or Smack or AppArmor folks, I'm quite certain they'll all send back a reply "Oh damn, that shouldn't happen, we'll think about a policy or code fix to prevent that". 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. Do you see the difference? "There are two kinds of cryptography in this world: cryptography that will stop your kid sister from reading your files, and cryptography that will stop ...
Well, I can make Yama stack, but I suspect I shouldn't waste my time on that since Yama itself would be rejected on different grounds. I'm sure you can see how this appears to be a catch 22. "We don't need stacking because nothing needs to be stacked, and we don't need a micro-LSM because it can't This is the basis of our disagreement. Fixing it does do people a favor. At the very least, it does me a favor because now I don't have to publish Understood. I get what you're saying about the models, and my only real defense here is that I didn't want these features in an LSM to begin with, so I don't mind it not being an LSM. That said, again, we disagree, it does actually provide security. I can point to lists of vulnerabilities where I think this is irrelevant; the symlink/hardlink combo fixes a Right, though my objection to all MACs is that they are on top of DAC, and that large portions of the Linux user base do not use a MAC, but they cannot avoid DAC. Since the symlink/hardlink issue is with DAC, it should I get what you're saying. It is convincing me that the symlink/hardlink Right. But I'm trying to help protect people from their kid sister too. Unfortunately, the use-case is where it's both the kid sister admin with no MAC policy being attacked by the kid sister script kiddie with a symlink race exploit due to the kid sister programmer who wrote an application that uses a guessable /tmp file. (With apologies to kid sisters everywhere; I You're completely right that the PTRACE exception idea isn't perfect. It could be raced between the crasher's fork()/exec() and prctl(). There are probably more cases, but it sure is better than just letting everything PTRACE everything else. While waiting for smarter people than me make it impossible to exploit security vulnerabilities in the future, I want to make it harder for Heh, well, I have a PTRACE model. :) "Only CAP_SYSADMIN can PTRACE_ATTACH." Unfortunately, I'm stuck with these damned crash handlers which are ...
Actually, we do, because you yourself have stated that: a) It's a patch for one case. b) It's been around for 15 years. c) It doesn't even try to address the general case. Umm.. Tell you what. I'll give you a chance to pretend you didn't send that from a vendor e-mail address... :) Do you *really* want to go on record as saying "We didn't ship a fix for Frobozz 3.2 because The Kernel Would Stop The Obvious Exploit", when it's usually quite possible that somebody can come up with a different exploit scenario? That's also going to go over *really* well with customers who end up turning off Yama because it breaks some third-party app that's doing some Actually, if you trace it through, in almost every single case of an exploit abusing a symlink, at no time does the DAC model actually get violated. Every single access *is* in fact done according to the DAC in effect. The problem is that some of the accesses are not the ones the programmer intended the software As pointed out above, it's *not* a DAC issue. The abused program never actually writes to anything that the DAC doesn't allow it to. In fact, a moment's thought will show that in general, a DAC *cannot* by definition actually secure a system - because the D stands for Discretionary. And most of the abuses you're trying to stop are basically convincing a program to abuse its discretionary choices. DAC is by definition "The user/program gets to decide who gets what access, and we trust the user/program to take actions that implement its decisions". (Here is where you insert the clip from Indiana Jones and the Last Crusade: "He chose... poorly"). That's DAC in a nutshell. The break is *not* in DAC, because it was never intended to defend against certain classes of threats (namely, programs that can be accidentally tricked into do things they didn't intend to, but the DAC says they can do). The break is in your idea that DAC can actually The sad part is that there are already known ways developed by smarter ...
Well, Yama is just an LSM. The symlink/hardlink thing has been around forever and does sufficiently solve the general symlink race flaw. But, Well, it drastically reduces the urgency of such a vulnerability. Besides, if this makes a million systems safer and 1 less safe, that's still a I'm not convinced. I see what you're trying to say, but I just don't agree. The symlink/hardlink thing is a tiny corner case of the operational conditions under which DAC operates, and this is fixing a mistake in the design that leads programmers into a (well known but seemingly unavoidable) Yeah, my next trick will be helping people confine their web applications. We'll agree to disagree. And at the same time I'll point out that if SELinux is off (or app is running without policy), symlink races are just Perhaps later. For the moment, I'm happy with my racey anti-PTRACE solution. -Kees -- Kees Cook Ubuntu Security Team --
/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 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 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. ...
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?
I'm running CentOS5.5 and RHEL6beta in enforcing mode with default configuration 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. --
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.
Aloha Testsu; Aloha Everybody; I don't think that the job of SELinux is the protection on the 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 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 --
Hello everybody; I would say it in a different way: "Since Yama has as a security model a container that is field with functionality of other security packages that have a security model but are no LSMs, then instead of making a new LSM like Yama the LSM architecture should be overworked to make the whole security packages To be honest, I don't think this is a reason. The reason I see is that a "large" LSM consisting of a thrown in bunch of ad-hoc rules But it was discussed that it should become at least an LSM. And it was found out that: 1. No new unproven protections have been invented. 2. The functionalities/features were taken out of other security packages that are no LSMs but (seem to) have a security model. 3. The question was not answered if the functionalities/features could That's out of context. The context was if the whole conceptual model with all of its features is working and not if every single feature of Have fun Christian Stroetmann --
Hi David, Sure thing. When looking at how PTRACE is used, it seemed clear that there were exactly 2 use-cases: - tracking children (either for monitoring or debugging) - in-memory crash handlers Allowing child-tracing was easy: this is discoverable through process ancestry. Doing the crash handlers is different, since the handler can come from anywhere. One thing that seemed common was that the crashing program would know which pid was going to attach to it, so if those programs declared to the kernel which pid is allowed to attach, then it could make an exception for it. I did not find a heuristic approach that the kernel could use to figure this out for itself (maybe I missed something). It seems to me that SELinux (and AppArmor and maybe others?) can declare general relationships of who can PTRACE who, etc, but nothing that specifically says "only _this_ instance". Instead of "the crash handler binary running as $identity can attach to program foo running as $identity", it is "the crash handler process specified by program foo at the time of the crash, can attach to foo", which is much more specific. If there's a way to do this already, I am genuinely interested to learn more about it. Perhaps I've grossly misunderstood something. -Kees -- Kees Cook Ubuntu Security Team --
|Greg KH||Og dreams of kernels|
|Jens Axboe||[PATCH 31/33] Fusion: sg chaining support|
|Arnd Bergmann||Re: finding your own dead "CONFIG_" variables|
|Mark Brown||[PATCH 2/2] Subject: natsemi: Allow users to disable workaround for DspCfg reset|
|Tony Breeds||[LGUEST] Look in object dir for .config|
|Brian Downing||Re: Git in a Nutshell guide|
|John Benes||Re: master has some toys|
|Matthias Lederhofer||[PATCH 4/7] introduce GIT_WORK_TREE to specify the work tree|
|Alexander Sulfrian||[RFC/PATCH] RE: git calls SSH_ASKPASS even if DISPLAY is not set|
|Junio C Hamano||Re: Rss produced by git is not valid xml?|
|Linux Kernel Mailing List||iSeries: fix section mismatch in iseries_veth|
|Linux Kernel Mailing List||ixbge: remove TX lock and redo TX accounting.|
|Linux Kernel Mailing List||ixgbe: fix several counter register errata|
|Linux Kernel Mailing List||b43: fix build with CONFIG_SSB_PCIHOST=n|
|Linux Kernel Mailing List||9p: block-based virtio client|