Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 4 Oct 2013 15:59:51 -0700
From: Andy Lutomirski <>
To: "Eric W. Biederman" <>
Cc: Djalal Harouni <>, Kees Cook <>, 
	Al Viro <>, Andrew Morton <>, 
	Linus Torvalds <>, Ingo Molnar <>, 
	"Serge E. Hallyn" <>, Cyrill Gorcunov <>, 
	David Rientjes <>, LKML <>, 
	Linux FS Devel <>, 
	"" <>, Djalal Harouni <>
Subject: Re: [PATCH v2 2/9] procfs: add proc_allow_access() to check if file's
 opener may access task

On Fri, Oct 4, 2013 at 3:55 PM, Eric W. Biederman <> wrote:
> Andy Lutomirski <> writes:
>> On Fri, Oct 4, 2013 at 12:41 PM, Djalal Harouni <> wrote:
>>> On Fri, Oct 04, 2013 at 12:32:09PM -0700, Andy Lutomirski wrote:
>>>> On Fri, Oct 4, 2013 at 12:27 PM, Djalal Harouni <> wrote:
>>>> > So sorry Andy, I don't follow what you are describing.
>>>> And what parameters are you passing to security_ptrace_access_check?
>>>> It's supposed to be f_cred, right?  Because you want to make sure
>>>> that, if the opener had some low-privilege label, the target has
>>>> execed and gotten a more secure label, and the reader has a
>>>> high-privilege label, that the opener's label is checked against the
>>>> target's new label.
>>> The current's cred each time.
>> Exactly.  Hence the NAK.
>>> Is there some mechanism to check what you describe?
>> No.  You could try to add one, but getting it to be compatible with
>> YAMA might be really messy.
>> Or you could see if destroying and recreating all the inodes on exec
>> or some other revoke-like approach would work.
> This is a revoke like approach, and yes proc has a fully functional
> revoke infrastructure.  Right now that revoke is based on the process
> going away.  The problem challenge is that the process is morphing.
> The practical question is which runtime checks do we want to perform.
> If we can say in no uncertain terms that short of a suid exec that
> no calls (such as setuid) can change the process permissions beyond
> our ability to access the file, we can detect and exec and use that
> as a signal.

If you could ptrace a process before it calls setuid and you can't
after it calls setuid, then this is stupid and doesn't matter -- once
you've pwned a process, you retain your pwnership at least until exec.

So yes, except that it's not just suid exec.  It's any exec that any
LSM would not do if no_new_privs were set.

> Alternatively we may to look at a processes credentials and in all
> cases where those change use that as a signal that the file must
> be reopened.

Hmm.  So why don't we just do a revoke whenever an exec that changes
cred happens?  (This will have some false positives, like unsharing
userns, I think, but we probably don't care.)

> Right now the model that we do a full permission check at every system
> call because the morphing process may cause problems.  If analysis can
> be done to show that we can use a simpler check than a full permission
> check that would be grand.
> The problem is not lack of techinical infrastructure (revoke).  The
> problem is a question of which tests are sufficient.

Can you point us at that infrastructure?  My limited grepping skills
didn't spot it.

I'd really like a solution where there are no read or write
implementations in the entire kernel that check permissions.  Failing
that, just getting it for procfs would be nice.  (uid_map, etc will
probably need to be revoked on unshare for this to work.)


Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.