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 (14):
AppArmor: misc. base functions and defines
AppArmor: basic auditing infrastructure.
AppArmor: contexts used in attaching policy to system objects
AppArmor: dfa match engine
AppArmor: userspace interfaces
AppArmor: file enforcement routines
AppArmor: functions for domain transitions
AppArmor: update Maintainer and Documentation
AppArmor: Enable configuring and building of the AppArmor security module
AppArmor: LSM interface, and security module initialization
AppArmor: mediation of non file objects
AppArmor: policy routines for loading and unpacking policy
AppArmor: core policy routines
AppArmor: Enable configuring and building of the AppArmor security module
Justin P. Mattock (1):
KEYS: Reinstate lost passing of process keyring ID in call_sbin_request_key()
Kees Cook (3):
security: Yama LSM
Yama: turn process ancestry check into function
Yama: verify inode is symlink to avoid bind mounts
Mimi Zohar (1):
security: move LSM xattrnames to xattr.h
Paul E. McKenney (1):
selinux: remove all rcu head initializations
Paul Moore (5):
selinux: Set the peer label correctly on connected UNIX domain sockets
selinux: Consolidate sockcreate_sid logic
selinux: Shuffle the sk_security_struct alloc and free routines
selinux: Convert socket related access controls to use socket labels
selinux: Use current_security() when possible
Rajiv Andrade (1):
tpm_tis: fix subsequent suspend failures
Tetsuo Handa (42):
TOMOYO: Add numeric values grouping support.
TOMOYO: Use structure for passing common arguments.
TOMOYO: Split file access control functions by type of parameters.
TOMOYO: Add mount restriction.
TOMOYO: Add interactive enforcing mode.
TOMOYO: Split files into some pieces.
LSM: Remove unused arguments from security_path_truncate().
TOMOYO: Several fixes for TOMOYO's management programs.
TOMOYO: Support longer pathname.
TOMOYO: Allow wildcard for execute permission.
TOMOYO: Add pathname aggregation support.
TOMOYO: Update profile structure.
TOMOYO: Use callback for updating entries.
TOMOYO: Use common structure for list element.
TOMOYO: Use callback for updating entries.
TOMOYO: Use common code for garbage collection.
TOMOYO: Use common code for open and mkdir etc.
TOMOYO: Pass parameters via structure.
TOMOYO: Use callback for permission check.
TOMOYO: Rename symbols.
TOMOYO: Loosen parameter check for mount operation.
TOMOYO: Remove wrapper function for reading keyword.
TOMOYO: Merge functions.
TOMOYO: Make read function to void.
TOMOYO: Pass "struct list_head" rather than "void *".
TOMOYO: Merge tomoyo_path_group and tomoyo_number_group
TOMOYO: Use array of "struct list_head".
TOMOYO: Aggregate reader functions.
TOMOYO: Merge path_group and number_group.
TOMOYO: Remove alias keyword.
TOMOYO: Use common code for domain transition control.
TOMOYO: Change list iterator.
TOMOYO: Allow reading only execute permission.
TOMOYO: Use common code for policy reading.
TOMOYO: Copy directly to userspace buffer.
TOMOYO: Small cleanup.
TOMOYO: Rename symbols.
TOMOYO: Add missing poll() hook.
TOMOYO: Explicitly set file_operations->llseek pointer.
TOMOYO: Fix quota check.
TOMOYO: Update version to 2.3.0
TOMOYO: Use pathname specified by policy rather than execve()
Tvrtko Ursulin (1):
securityfs: Drop dentry reference count when mknod fails
--
James Morris
<[email protected]>
On Fri, 30 Jul 2010, James Morris wrote:
> 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.
I'm going to revert the Yama stuff for 2.6.36 -- Christoph has nacked it
to me off-list.
- James
--
James Morris
<[email protected]>
On Mon, Aug 02, 2010 at 12:18:46PM +1000, James Morris wrote:
> On Fri, 30 Jul 2010, James Morris wrote:
> > 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.
>
> I'm going to revert the Yama stuff for 2.6.36 -- Christoph has nacked it
> to me off-list.
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
On Sun, 1 Aug 2010, Kees Cook wrote:
> 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.
It's the same nak as before -- I concluded there was consensus on the
lists, but was wrong.
> James, will it stay in security-testing for .37 hopefully?
Not with this approach, I'd imagine.
- James
--
James Morris
<[email protected]>
On Mon, Aug 02, 2010 at 04:41:08PM +1000, James Morris wrote:
> On Sun, 1 Aug 2010, Kees Cook wrote:
> > 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.
>
> It's the same nak as before -- I concluded there was consensus on the
> lists, but was wrong.
>
> > James, will it stay in security-testing for .37 hopefully?
>
> Not with this approach, I'd imagine.
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
Aloha James, Aloha Kees;
Ont the 02.08.2010 08:57, Kees Cook wrote:
> On Mon, Aug 02, 2010 at 04:41:08PM +1000, James Morris wrote:
>
>> On Sun, 1 Aug 2010, Kees Cook wrote:
>>
>>> 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.
>>>
A private NAK against a company's developer's OK
Where is the difference private and company? I thought that it doesn't
matter who and what a developer is, and where she/he comes from.
>> It's the same nak as before -- I concluded there was consensus on the
>> lists, but was wrong.
>>
The opinion as well as the NAK by Christoph was discussed and supported
by other developers.
>>> James, will it stay in security-testing for .37 hopefully?
>>>
>> Not with this approach, I'd imagine.
>>
Yes, because it supports as an experiment the development of the LSM
architecture in general.
> 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.
>
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
core kernel developer).
> 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
>
>
[3] http://lkml.org/lkml/2010/6/30/64
Have fun in the sun
Christian Stroetmann
On Mon, Aug 02, 2010 at 12:18:46PM +1000, James Morris wrote:
> On Fri, 30 Jul 2010, James Morris wrote:
>
> > 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.
>
> I'm going to revert the Yama stuff for 2.6.36 -- Christoph has nacked it
> to me off-list.
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 Christian,
On Mon, Aug 02, 2010 at 12:19:54PM +0200, Christian Stroetmann wrote:
> 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 core kernel developer).
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
Hi Christoph,
On Mon, Aug 02, 2010 at 08:24:21AM -0400, Christoph Hellwig wrote:
> 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.
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
LSM[1], and yet now you're saying I shouldn't.
> Al gave you some very clear advice how a the sticky check should be
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
protections in the VFS itself.
> done for symlinks (if we need it at all, which I tend to disagree with),
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
solution for the past decade.
> 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
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.
> 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.
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
Hi Kees;
On the 02.08.2010 18:36, Kees Cook wrote:
> Hi Christian,
>
> On Mon, Aug 02, 2010 at 12:19:54PM +0200, Christian Stroetmann wrote:
>
>> 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 core kernel developer).
>>
> 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
>
>
Sorry, but: No, you haven't. In fact we have these lines of discussion:
1. You said "Trying to chain comprehensive LSMs seems like it will
always fail, but putting little LSMs in front of big LSMs seems like an
easy win." And I said that "I don't think that the problem is if an LSM
is small or large."
2a. I said also "[...] you will put more and more functionalities, maybe
again taken from other packages, into your new LSM with the result that
at the end it will be a big LSM. And then?". Then after point 1. we have
a chaining problem of comprehensive LSMs, as you said.
2b. Otherwise, if we have no chaining problem as I said (see point 1.)
and your LSM becomes larger, then I said it is better to solve the
problem at the side of the LSM architecture and not be ripping off other
security packages and put their functionalities into LSMs like it was
done by the Yama LSM.
So that doesn't mean that the Yama LSM should not exist because it might
grow. It means: If the Yama LMS grows mainly by porting into it
functionalities of other security packages that actually have no
relation to the LSM system, then it should not exist in favor of a new
LSM architecture that enables the integration of those security
packages. The Yama LSM should not become a container of functionalities
of other already existing security packages. If you put only your own
security concepts and methodes into it, then its OK, for sure.
Also, the Yama LSM should not exist if it only dictates the structure of
the other LSMs, especially if it becomes large and in this way important
to be followed by only growing it with functionalities taken from other
security packages. If you say that the way of the Yama LSM is the right
way to do it in general, then we don't need a new LSM like Yama, but a
new LSM architecture.
Hopefully I could clearify it now a little bit better. Otherwise the
night is long :)
Best regards
Christian Stroetmann
Quoting Christian Stroetmann ([email protected]):
> Aloha James, Aloha Kees;
> Ont the 02.08.2010 08:57, Kees Cook wrote:
> >On Mon, Aug 02, 2010 at 04:41:08PM +1000, James Morris wrote:
> >>On Sun, 1 Aug 2010, Kees Cook wrote:
> >>>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.
>
> A private NAK against a company's developer's OK
> Where is the difference private and company? I thought that it
> doesn't matter who and what a developer is, and where she/he comes
> from.
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
On Mon, 2010-08-02 at 09:59 -0700, Kees Cook wrote:
[...snip]
>
> 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.
>
Would you mind explaining to me what you believe this patch can do that
SELinux can't? Based on what I read in the kconfig entry for the feature
and the subsequent exception patch I'm not seeing anything here that
SELinux can't do. If there is something we are missing I'd like to
understand it so we can make the decision on whether or not our ptrace
access control checks need to be modified.
Dave
Aloha Serge;
On the 02.08.2010 20:08, Serge E. Hallyn wrote:
> Quoting Christian Stroetmann ([email protected]):
>
>> Aloha James, Aloha Kees;
>> Ont the 02.08.2010 08:57, Kees Cook wrote:
>>
>>> On Mon, Aug 02, 2010 at 04:41:08PM +1000, James Morris wrote:
>>>
>>>> On Sun, 1 Aug 2010, Kees Cook wrote:
>>>>
>>>>> 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.
>>>>>
>> A private NAK against a company's developer's OK
>> Where is the difference private and company? I thought that it
>> doesn't matter who and what a developer is, and where she/he comes
>> from.
>>
> 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.)
>
>
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
On Mon, 02 Aug 2010 09:59:36 PDT, Kees Cook said:
> > Al gave you some very clear advice how a the sticky check should be
>
> 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
> protections in the VFS itself.
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.
> > done for symlinks (if we need it at all, which I tend to disagree with),
>
> 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
> solution for the past decade.
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
what the problem is if it isn't working.
> > 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
>
> 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.
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 dangerous for your cause to
bring it up without understanding which it is, and why...
> 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
You're still missing the point:
> [2] http://lkml.org/lkml/2010/6/4/44
You were told to go back and form an actual *security model*. What's important
to protect? What attacks can be made against it? What syscalls are included in
the forseeable attacks (hint - probably more than you think - if you're
mediating symlink access, a bit of thought will show symlinks aren't the only
problem you need to worry about to *actually* secure the resource).
On Mon, Aug 02, 2010 at 02:51:13PM -0400, [email protected] wrote:
> On Mon, 02 Aug 2010 09:59:36 PDT, Kees Cook said:
> > > Al gave you some very clear advice how a the sticky check should be
> >
> > 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
> > protections in the VFS itself.
>
> 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.
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
getting the "good" for the sake of wanting the "perfect".
> 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.
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
how the kernel works without resorting to endlessly carrying a patchset.
> 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
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
the VFS, since I'm trying to fix a flaw in DAC.
> 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.
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
hardlinks are created". :P
> 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
> what the problem is if it isn't working.
I have regression tests for all the Yama features. I can prove if it's
working or not.
> > 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.
>
> 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 dangerous for your cause to
> bring it up without understanding which it is, and why...
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
SECCOMP.
> You were told to go back and form an actual *security model*. What's important
> to protect? What attacks can be made against it? What syscalls are included in
> the forseeable attacks (hint - probably more than you think - if you're
> mediating symlink access, a bit of thought will show symlinks aren't the only
> problem you need to worry about to *actually* secure the resource).
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
Hi David,
On Mon, Aug 02, 2010 at 02:34:21PM -0400, David P. Quigley wrote:
> On Mon, 2010-08-02 at 09:59 -0700, Kees Cook wrote:
> [...snip]
> >
> > 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.
> >
>
> Would you mind explaining to me what you believe this patch can do that
> SELinux can't? Based on what I read in the kconfig entry for the feature
> and the subsequent exception patch I'm not seeing anything here that
> SELinux can't do. If there is something we are missing I'd like to
> understand it so we can make the decision on whether or not our ptrace
> access control checks need to be modified.
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
On Mon, Aug 02, 2010 at 07:33:26PM +0200, Christian Stroetmann wrote:
> structure of the other LSMs, especially if it becomes large and in
> this way important to be followed by only growing it with
> functionalities taken from other security packages. If you say that
> the way of the Yama LSM is the right way to do it in general, then
> we don't need a new LSM like Yama, but a new LSM architecture.
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
On Tue, 03 Aug 2010 09:50:10 PDT, Kees Cook said:
> > 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.
>
> 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
> getting the "good" for the sake of wanting the "perfect".
The fact that a patch for one case has been used for years doesn't mean
that it's a well thought out fix for the general case.
> 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
> how the kernel works without resorting to endlessly carrying a patchset.
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
set in stone and rarely change.
> 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
> hardlinks are created". :P
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
any favors.
> > 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
> > what the problem is if it isn't working.
> I have regression tests for all the Yama features. I can prove if it's
> working or not.
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 major
governments from reading your files. This book is about the latter."
-- Bruce Schneier, "Applied Cryptography"
The same sort of distinction applies to security.
> 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.
So let's see - the program needs some way to *find* said "single specific pid".
It checks the value of getppid()? Easily spoofable - I fork/exec it, wait for
it to say "parent can trace", then trace. It checks in a file? If I can fake that
file out (with, perhaps, a symlink or race that Yama doesn't protect against),
I can do the ptrace. Send it via a unix-domain socket or mmap or shmem?
See passing in a file. Or maybe I can force an OOM to kill the "real" pid,
then a quick fork() loop till I get that pid on the wrap-around. Or maybe I'm
just a bastard and get control of the pid the program declares as "may ptrace'
and then do nothing at all just to DoS the process that you *wanted* tracing you.
I'm sure there's several dozen other practical attacks that a motivated
attacker can come up with. So now you've traded "protect one ptrace() syscall"
for "protect against abuse of at least a dozen system calls".
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.
Hello everybody;
On the 03.08.2010 18:50, Kees Cook wrote:
> On Mon, Aug 02, 2010 at 02:51:13PM -0400, [email protected] wrote:
>
>> On Mon, 02 Aug 2010 09:59:36 PDT, Kees Cook said:
>>
>>>> Al gave you some very clear advice how a the sticky check should be
>>>>
>>> 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
>>> protections in the VFS itself.
>>>
>> 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.
>>
> 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
> getting the "good" for the sake of wanting the "perfect".
>
>
>> 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.
>>
> 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
> how the kernel works without resorting to endlessly carrying a patchset.
>
>
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
and implicitly their security models LSMs."
>> 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
>>
>
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
may rule the structure of the security model of LSMs.
> 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
> the VFS, since I'm trying to fix a flaw in DAC.
>
>
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
be done by already existing LSMs (eg. SELinux).
>> 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.
>>
> 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
> hardlinks are created". :P
>
>
>> 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
>> what the problem is if it isn't working.
>>
> I have regression tests for all the Yama features. I can prove if it's
> working or not.
>
>
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
Yama is working.
>>> 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.
>>>
>> 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 dangerous for your cause to
>> bring it up without understanding which it is, and why...
>>
> 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
> SECCOMP.
>
>
>> You were told to go back and form an actual *security model*. What's important
>> to protect? What attacks can be made against it? What syscalls are included in
>> the forseeable attacks (hint - probably more than you think - if you're
>> mediating symlink access, a bit of thought will show symlinks aren't the only
>> problem you need to worry about to *actually* secure the resource).
>>
> 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
>
>
Have fun
Christian Stroetmann
On Tue, Aug 03, 2010 at 05:38:20PM -0400, [email protected] wrote:
> On Tue, 03 Aug 2010 09:50:10 PDT, Kees Cook said:
> > > 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.
> >
> > 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
> > getting the "good" for the sake of wanting the "perfect".
>
> The fact that a patch for one case has been used for years doesn't mean
> that it's a well thought out fix for the general case.
Well, we clearly disagree on this point. :)
> 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.
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
be used due to lack of stacking."
> 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
> any favors.
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
security updates for an entire class of vulnerability.
> The problem is that "proving it does what it claims" and "proving it
> actually provides security" are two very different things.
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
the symlink/hardlink protection actually does really block the exploit.
> 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?
I think this is irrelevant; the symlink/hardlink combo fixes a
vulnerability with DAC. It's a break in the DAC security model.
> 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".
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
be fixed there, not in a MAC layer above.
> 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?
I get what you're saying. It is convincing me that the symlink/hardlink
features make no sense as an LSM.
> "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 major
> governments from reading your files. This book is about the latter."
> -- Bruce Schneier, "Applied Cryptography"
>
> The same sort of distinction applies to security.
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
just wanted to continue the quoted metaphor.)
> I'm sure there's several dozen other practical attacks that a motivated
> attacker can come up with. So now you've traded "protect one ptrace() syscall"
> for "protect against abuse of at least a dozen system calls".
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
attackers to exploit security vulnerabilities now.
> 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.
Heh, well, I have a PTRACE model. :) "Only CAP_SYSADMIN can PTRACE_ATTACH."
Unfortunately, I'm stuck with these damned crash handlers which are really
just hacks to avoid writing a core to disk. Oddly, this is a solved problem
(via core dump patterns and distro-wide crash handlers), but some
applications want to opt out of it instead of providing proper system hooks
to do crash analysis. Of course, with PTRACE still allowed, there's no
carrot (or stick) to encourage application writers to use distro-provided
crash handlers.
-Kees
--
Kees Cook
Ubuntu Security Team
On Tue, 03 Aug 2010 15:34:51 PDT, Kees Cook said:
> On Tue, Aug 03, 2010 at 05:38:20PM -0400, [email protected] wrote:
> > The fact that a patch for one case has been used for years doesn't mean
> > that it's a well thought out fix for the general case.
>
> Well, we clearly disagree on this point. :)
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.
So Yama is a special case that after years still doesn't cover the genera case
:)
> > - the point is that ad-hoc fixes for the low-hanging fruit isn't doing anybody
> > any favors.
>
> 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
> security updates for an entire class of vulnerability.
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
batshit crazy thing it shouldn't be doing in the first place.
> I think this is irrelevant; the symlink/hardlink combo fixes a
> vulnerability with DAC. It's a break in the DAC security model.
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
to make.
> 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
> be fixed there, not in a MAC layer above.
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
enforce security (which it can't - you need MAC for that).
> 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.
> 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
> attackers to exploit security vulnerabilities now.
The sad part is that there are already known ways developed by smarter people.
You just refuse to consider them as solutions and keep trying to deploy stuff
that a sufficiently clever kid sister can bypass.
> Heh, well, I have a PTRACE model. :) "Only CAP_SYSADMIN can PTRACE_ATTACH."
That's not actually a full model. ;)
> Unfortunately, I'm stuck with these damned crash handlers which are really
> just hacks to avoid writing a core to disk. Oddly, this is a solved problem
> (via core dump patterns and distro-wide crash handlers) , but some
> applications want to opt out of it instead of providing proper system hooks
> to do crash analysis. Of course, with PTRACE still allowed, there's no
> carrot (or stick) to encourage application writers to use distro-provided
> crash handlers.
So do the obvious - ship with SELinux configured to not allow the arbitrary ptrace,
document it, and tell them "it doesn't work, use the proper system interface instead".
:)
On Tue, Aug 03, 2010 at 10:07:55PM -0400, [email protected] wrote:
> On Tue, 03 Aug 2010 15:34:51 PDT, Kees Cook said:
> > On Tue, Aug 03, 2010 at 05:38:20PM -0400, [email protected] wrote:
> > > The fact that a patch for one case has been used for years doesn't mean
> > > that it's a well thought out fix for the general case.
> >
> > Well, we clearly disagree on this point. :)
>
> 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.
>
> So Yama is a special case that after years still doesn't cover the genera case
> :)
Well, Yama is just an LSM. The symlink/hardlink thing has been around
forever and does sufficiently solve the general symlink race flaw. But,
whatever, we disagree about this.
> > 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
> > security updates for an entire class of vulnerability.
>
> 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
> batshit crazy thing it shouldn't be doing in the first place.
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
net win.
> > I think this is irrelevant; the symlink/hardlink combo fixes a
> > vulnerability with DAC. It's a break in the DAC security model.
>
> 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
> to make.
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)
trap.
> that implement its decisions". (Here is where you insert the clip from Indiana
> Jones and the Last Crusade: "He chose... poorly").
Yeah, my next trick will be helping people confine their web applications.
Hahaha ugh. That's an area of endless poor choices.
> > While waiting for smarter people than me make it impossible to exploit
> > security vulnerabilities in the future, I want to make it harder for
> > attackers to exploit security vulnerabilities now.
>
> The sad part is that there are already known ways developed by smarter people.
> You just refuse to consider them as solutions and keep trying to deploy stuff
> that a sufficiently clever kid sister can bypass.
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
as bad.
> > Heh, well, I have a PTRACE model. :) "Only CAP_SYSADMIN can PTRACE_ATTACH."
>
> That's not actually a full model. ;)
alt.ptrace.die.die.die
> > Unfortunately, I'm stuck with these damned crash handlers which are really
> > just hacks to avoid writing a core to disk. Oddly, this is a solved problem
> > (via core dump patterns and distro-wide crash handlers) , but some
> > applications want to opt out of it instead of providing proper system hooks
> > to do crash analysis. Of course, with PTRACE still allowed, there's no
> > carrot (or stick) to encourage application writers to use distro-provided
> > crash handlers.
>
> So do the obvious - ship with SELinux configured to not allow the arbitrary ptrace,
> document it, and tell them "it doesn't work, use the proper system interface instead".
>
> :)
Perhaps later. For the moment, I'm happy with my racey anti-PTRACE
solution.
-Kees
--
Kees Cook
Ubuntu Security Team
[email protected] 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.
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?
[email protected] 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.
Aloha Testsu; Aloha Everybody;
On the 04.08.2010 05:54, Tetsuo Handa wrote :
> [email protected] 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
On Wed, 04 Aug 2010 16:00:21 +0900, Tetsuo Handa said:
> [email protected] 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.