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 ...
[ message continues ]

I'm going to revert the Yama stuff for 2.6.36 -- Christoph has nacked it 
to me off-list.


- James
-- 
James Morris
<jmorris@namei.org>
--

[ message continues ]

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

[ message continues ]

It's the same nak as before -- I concluded there was consensus on the 

Not with this approach, I'd imagine.


- James
-- 
James Morris
<jmorris@namei.org>
--

[ message continues ]

I'm sorry to appear dense, but the most recent NAK from Christoph was
here[1], which was for a patch to Yama that is not in security-testing
yet. Prior to that, all I could find was this[2] 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

[1] http://lkml.org/lkml/2010/6/30/31
[2] http://lkml.org/lkml/2010/6/1/78

-- 
Kees Cook
Ubuntu Security Team
--

[ message continues ]

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 [3].
You can see these objections [3] as a second NAK, but now from a 
company's developer (I haven't said this before, because I'm not a hard 

[3] http://lkml.org/lkml/2010/6/30/64

Have fun in the sun
Christian Stroetmann
--

[ message continues ]

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

[ message continues ]

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

[ message continues ]

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

[ message continues ]

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

[ message continues ]

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

[ message continues ]

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[2]. 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

[1] http://lkml.org/lkml/2010/6/1/78
[2] http://lkml.org/lkml/2010/6/4/44

-- 
Kees Cook
Ubuntu Security Team
--

[ message continues ]

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 ...
[ message continues ]

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

[ message continues ]

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 ...
[ message continues ]

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 ...
[ message continues ]

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 ...
[ message continues ]

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

[ message continues ]

/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. ...
[ message continues ]

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?

[ message continues ]

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

[ message continues ]

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.

[ message continues ]

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

[ message continues ]

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

[ message continues ]

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

[ message continues ]