Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

[PATCH] ptrace: allow restriction of ptrace scope

 

 

First page Previous page 1 2 Next page Last page  View All Linux kernel RSS feed   Index | Next | Previous | View Threaded


kees.cook at canonical

Jun 16, 2010, 3:18 PM

Post #1 of 37 (5175 views)
Permalink
[PATCH] ptrace: allow restriction of ptrace scope

As Linux grows in popularity, it will become a larger target for
malware. One particularly troubling weakness of the Linux process
interfaces is that a single user is able to examine the memory and
running state of any of their processes. For example, if one application
(e.g. Pidgin) was compromised, it would be possible for an attacker to
attach to other running processes (e.g. Firefox, SSH sessions, GPG agent,
etc) to extract additional credentials and continue to expand the scope
of their attack without resorting to user-assisted phishing.

This is not a theoretical problem. SSH session hijacking
(http://www.storm.net.nz/projects/7) and arbitrary code injection
(http://c-skills.blogspot.com/2007/05/injectso.html) attacks already
exist and remain possible if PTRACE is allowed to operate as before.
PTRACE is not commonly used by non-developers and non-admins, so system
builders should be allowed the option to disable this debugging system.

For a solution, some applications use prctl(PR_SET_DUMPABLE, ...) to
specifically disallow such PTRACE attachment (e.g. ssh-agent), but many
do not. A more general solution is to only allow PTRACE directly from a
parent to a child process (i.e. direct "gdb EXE" and "strace EXE" still
work), or with CAP_SYS_PTRACE (i.e. "gdb --pid=PID", and "strace -p PID"
still work as root).

This patch is based on the patch in grsecurity. It includes a sysctl
to enable the behavior via /proc/sys/kernel/ptrace_scope. This could
be expanded in the future to further restrict PTRACE to, for example,
only CAP_SYS_PTRACE (scope 2) or only init (scope 3).

Signed-off-by: Kees Cook <kees.cook [at] canonical>
---
Documentation/sysctl/kernel.txt | 16 ++++++++++++++++
kernel/ptrace.c | 24 ++++++++++++++++++++++++
kernel/sysctl.c | 10 ++++++++++
3 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 3894eaa..030f2f2 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -50,6 +50,7 @@ show up in /proc/sys/kernel:
- powersave-nap [ PPC only ]
- panic_on_unrecovered_nmi
- printk
+- ptrace_scope
- randomize_va_space
- real-root-dev ==> Documentation/initrd.txt
- reboot-cmd [ SPARC only ]
@@ -406,6 +407,21 @@ that support this feature.

==============================================================

+ptrace_scope:
+
+This option can used to select the scope of PTRACE functionality.
+
+0 - Standard scope. PTRACE can be used by any process on any other
+ process that shares the same uid and is dumpable (i.e. hasn't been
+ setuid, or has prctl(PR_SET_DUMPABLE) called on it). CAP_SYS_PTRACE
+ overrides any limitations. (This is the default option.)
+
+1 - Child-only. PTRACE can be used by any process on any child process
+ that shares the same uid and is dumpable. CAP_SYS_PTRACE overrides
+ any limitations.
+
+==============================================================
+
reboot-cmd: (Sparc only)

??? This seems to be a way to give an argument to the Sparc
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 74a3d69..5e7777a 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -23,6 +23,8 @@
#include <linux/uaccess.h>
#include <linux/regset.h>

+/* sysctl for defining allowed scope of PTRACE */
+int ptrace_scope;

/*
* ptrace a task: make the debugger its new parent and
@@ -127,6 +129,10 @@ int __ptrace_may_access(struct task_struct *task, unsigned int mode)
* ptrace_attach denies several cases that /proc allows
* because setting up the necessary parent/child relationship
* or halting the specified task is impossible.
+ *
+ * PTRACE scope can be define as:
+ * 0 - classic: CAP_SYS_PTRACE and same uid can ptrace non-setuid
+ * 1 - restricted: as above, but only children of ptracing process
*/
int dumpable = 0;
/* Don't let security modules deny introspection */
@@ -150,6 +156,24 @@ int __ptrace_may_access(struct task_struct *task, unsigned int mode)
dumpable = get_dumpable(task->mm);
if (!dumpable && !capable(CAP_SYS_PTRACE))
return -EPERM;
+ /* require ptrace target be a child of ptracer on attach */
+ if (mode == PTRACE_MODE_ATTACH && ptrace_scope &&
+ !capable(CAP_SYS_PTRACE)) {
+ struct task_struct *walker = task;
+ int rc = 0;
+
+ read_lock(&tasklist_lock);
+ while (walker->pid > 0) {
+ if (walker == current)
+ break;
+ walker = walker->parent;
+ }
+ if (walker->pid == 0)
+ rc = -EPERM;
+ read_unlock(&tasklist_lock);
+ if (rc)
+ return rc;
+ }

return security_ptrace_access_check(task, mode);
}
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index d24f761..fcb61c3 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -86,6 +86,7 @@ extern int sysctl_panic_on_oom;
extern int sysctl_oom_kill_allocating_task;
extern int sysctl_oom_dump_tasks;
extern int max_threads;
+extern int ptrace_scope;
extern int core_uses_pid;
extern int suid_dumpable;
extern char core_pattern[];
@@ -408,6 +409,15 @@ static struct ctl_table kern_table[] = {
.proc_handler = proc_dointvec,
},
{
+ .procname = "ptrace_scope",
+ .data = &ptrace_scope,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &zero,
+ .extra2 = &one,
+ },
+ {
.procname = "core_uses_pid",
.data = &core_uses_pid,
.maxlen = sizeof(int),
--
1.7.1

--
Kees Cook
Ubuntu Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


alan at lxorguk

Jun 16, 2010, 4:01 PM

Post #2 of 37 (5063 views)
Permalink
Re: [PATCH] ptrace: allow restriction of ptrace scope [In reply to]

> As Linux grows in popularity, it will become a larger target for
> malware. One particularly troubling weakness of the Linux process
> interfaces is that a single user is able to examine the memory and
> running state of any of their processes. For example, if one application

And this will help how - or don't you care about procfs.

> + /* require ptrace target be a child of ptracer on attach */
> + if (mode == PTRACE_MODE_ATTACH && ptrace_scope &&
> + !capable(CAP_SYS_PTRACE)) {
> + struct task_struct *walker = task;
> + int rc = 0;
> +
> + read_lock(&tasklist_lock);
> + while (walker->pid > 0) {
> + if (walker == current)
> + break;
> + walker = walker->parent;
> + }
> + if (walker->pid == 0)
> + rc = -EPERM;
> + read_unlock(&tasklist_lock);
> + if (rc)
> + return rc;
> + }


But even if it wasn't pointless this would be the wrong way to do it.

Other distributions do this sensibly by using things like SELinux which
can describe the relationships in ways that matter and also arbitrate
other access paths beyond ptrace which can be used for the same purpose.

And even if you don't care about using the same security stuff the rest
of the world is using to solve the problem this like the other half baked
stuff you posted for links belongs as a security module.

If you'd put it all in security/ubuntu/grsecurity or similar probably
nobody would care too much. The hooks are there so you can do different
things with security policy without making a mess for anyone else.

See ptrace_access_check, ptrace_traceme, and do remember /proc/mem -
which you'll find if you use the proper security hooks is already covered
for you.

So NAK. If you want to use bits of grsecurity then please just write
yourselves a grsecurity kernel module that uses the security hooks
properly and stop messing up the core code. It's all really quite simple,
the infrastrucuture is there, so use it.

Alan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


roland at redhat

Jun 16, 2010, 4:10 PM

Post #3 of 37 (5056 views)
Permalink
Re: [PATCH] ptrace: allow restriction of ptrace scope [In reply to]

This constraint seems fairly insane to me, but I don't really care about
people using sysctl to enable insane things if that's what floats your
boat. GDB's "attach", "strace -p", etc. are pretty normal (and highly
useful) things for ordinary users debugging their own programs.

I tend to think that this constraint offers more a delusion of security
than much real protection. But I'm too lazy to try to come up with a more
contorted exploit that this wouldn't prevent, so I won't belabor the point.

I think those who are actually paranoid would use something more meaningful
via the LSM ptrace check, like SELinux with a policy that only permits
known debugger applications to use ptrace. Aside from SELinux, it could
also be done with a new capability like CAP_PTRACE_MINE and filesystem
capabilities on installed debugger application binaries, for example.

You've described this as allowing ptrace on "children", but really it's
"unorphaned descendants", i.e. also children of children, etc.

I don't think "task->pid > 0" is a sort of check that is used elsewhere in
the kernel for this. Perhaps "task == &init_task" would be better.

It's not immediately obvious to me how this interacts with pid_ns, or
should. Probably it shouldn't pay attention to pid_ns, as it doesn't.
But I think it merits an explicit statement of intent about that.

I suspect you really want to test same_thread_group(walker, current).
You don't actually mean to rule out a debugger that forks children with
one thread and calls ptrace with another, do you?

Oh, and surely you meant real_parent. Off hand I think that might only
really add up to a different constraint if you had some ptrace attaches
already live when you did set the sysctl flag. But I have the vague
sensation I'm overlooking some other arcane case. And it just doesn't
logically match the stated intent of the thing to depend on parent
rather than real_parent.


Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


kees.cook at canonical

Jun 16, 2010, 4:22 PM

Post #4 of 37 (5048 views)
Permalink
Re: [PATCH] ptrace: allow restriction of ptrace scope [In reply to]

Hi Alan,

On Thu, Jun 17, 2010 at 12:01:20AM +0100, Alan Cox wrote:
> > As Linux grows in popularity, it will become a larger target for
> > malware. One particularly troubling weakness of the Linux process
> > interfaces is that a single user is able to examine the memory and
> > running state of any of their processes. For example, if one application
>
> And this will help how - or don't you care about procfs.

I'm not sure I follow this comment. Sensitive things in /proc/$PID/* are
already protected by ptrace_may_access() with mode == ATTACH.

> Other distributions do this sensibly by using things like SELinux which
> can describe the relationships in ways that matter and also arbitrate
> other access paths beyond ptrace which can be used for the same purpose.

Certainly. PTRACE can already be confined by SELinux and AppArmor. I'm
looking for a general approach that doesn't require a system builder to
create MAC policies for unknown software. I want to define a common core
behavior.

> And even if you don't care about using the same security stuff the rest
> of the world is using to solve the problem this like the other half baked
> stuff you posted for links belongs as a security module.

The LSM isn't stackable, so I can't put it there and choose this and
SELinux (for the case of software-without-a-policy).

> If you'd put it all in security/ubuntu/grsecurity or similar probably
> nobody would care too much. The hooks are there so you can do different
> things with security policy without making a mess for anyone else.

I'm not clear how this is "a mess for anyone else" when it defaults to
the classic PTRACE behavior. PTRACE itself is dangerous, so it's not
unreasonable to start inching away from it.

> So NAK. If you want to use bits of grsecurity then please just write
> yourselves a grsecurity kernel module that uses the security hooks
> properly and stop messing up the core code. It's all really quite simple,
> the infrastrucuture is there, so use it.

There is no infrastructure to selectively choose these general-purpose
features. This is why there is a sysctl. It's a global behavioral
change.

Since LSMs aren't arbitrarily stackable, asking me to move the code into
a new LSM isn't a particularly actionable suggestion.

-Kees

--
Kees Cook
Ubuntu Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


kees.cook at canonical

Jun 16, 2010, 4:39 PM

Post #5 of 37 (5043 views)
Permalink
Re: [PATCH] ptrace: allow restriction of ptrace scope [In reply to]

Hi,

On Wed, Jun 16, 2010 at 04:10:06PM -0700, Roland McGrath wrote:
> This constraint seems fairly insane to me, but I don't really care about
> people using sysctl to enable insane things if that's what floats your
> boat. GDB's "attach", "strace -p", etc. are pretty normal (and highly
> useful) things for ordinary users debugging their own programs.

Right, but I don't think "ordinary users" debug their own programs.
Ordinary developers and sysadmin do, absolutely, and for them, this
sysctl would probably stay set to 0.

> I tend to think that this constraint offers more a delusion of security
> than much real protection. But I'm too lazy to try to come up with a more
> contorted exploit that this wouldn't prevent, so I won't belabor the point.

Well, I don't want to present it as something it's not. It's only
designed to block access to what is immediately in memory. It certainly
won't stop an attacker from tricking a user into divulging credentials
directly or launching a process and then ptracing it, but it would put
a stop to an automated worm that did not need to go phishing.

> I think those who are actually paranoid would use something more meaningful
> via the LSM ptrace check, like SELinux with a policy that only permits
> known debugger applications to use ptrace. Aside from SELinux, it could
> also be done with a new capability like CAP_PTRACE_MINE and filesystem
> capabilities on installed debugger application binaries, for example.

This has been the area I've run into the most. I like the idea of a
semi-privileged capability like you suggest. It would solve a number
of iffy spots, like KDE and Chrome that fork/exec a debugger from the
crashing process and attach back to it. Those programs could be given
fscap for CAP_PTRACE_MINE, or something. Though, honestly, just trying to
get rid of PTRACE seems like the better place to spend time.

> You've described this as allowing ptrace on "children", but really it's
> "unorphaned descendants", i.e. also children of children, etc.

Right, I should say "descendants", which is the correct intent.

> I don't think "task->pid > 0" is a sort of check that is used elsewhere in
> the kernel for this. Perhaps "task == &init_task" would be better.

Is this correct for pid_ns? I thought pid 1 (regardless of NS) would have
a NULL parent?

> It's not immediately obvious to me how this interacts with pid_ns, or
> should. Probably it shouldn't pay attention to pid_ns, as it doesn't.
> But I think it merits an explicit statement of intent about that.

Okay, I can do that.

> I suspect you really want to test same_thread_group(walker, current).
> You don't actually mean to rule out a debugger that forks children with
> one thread and calls ptrace with another, do you?

Won't they ultimately have the same parent, though?

> Oh, and surely you meant real_parent. Off hand I think that might only
> really add up to a different constraint if you had some ptrace attaches
> already live when you did set the sysctl flag. But I have the vague
> sensation I'm overlooking some other arcane case. And it just doesn't
> logically match the stated intent of the thing to depend on parent
> rather than real_parent.

Oh, yes. That seems right. I can fix that.

-Kees

--
Kees Cook
Ubuntu Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


roland at redhat

Jun 16, 2010, 5:11 PM

Post #6 of 37 (5051 views)
Permalink
Re: [PATCH] ptrace: allow restriction of ptrace scope [In reply to]

> Though, honestly, just trying to get rid of PTRACE seems like the better
> place to spend time.

Crushing irony of telling *me* this duly noted. ;-)
I am not really sure what deeply different set of security constraints
you envision on any other kind of new debugger interface that would be
any different for the concerns you've expressed, though.

> > I don't think "task->pid > 0" is a sort of check that is used elsewhere in
> > the kernel for this. Perhaps "task == &init_task" would be better.
>
> Is this correct for pid_ns? I thought pid 1 (regardless of NS) would have
> a NULL parent?

Don't ask me. I just mentioned pid_ns to get those who really know about
it to feel obliged to review your code.

> > I suspect you really want to test same_thread_group(walker, current).
> > You don't actually mean to rule out a debugger that forks children with
> > one thread and calls ptrace with another, do you?
>
> Won't they ultimately have the same parent, though?

Sure, those debugger threads will have the same parent, such as the shell
that spawned the debugger. But your "security" check is that the caller of
ptrace is a direct ancestor of the tracee. The ancestry of that ptrace
caller is immaterial.


Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


kees.cook at canonical

Jun 16, 2010, 5:46 PM

Post #7 of 37 (5051 views)
Permalink
Re: [PATCH] ptrace: allow restriction of ptrace scope [In reply to]

On Wed, Jun 16, 2010 at 05:11:14PM -0700, Roland McGrath wrote:
> > Though, honestly, just trying to get rid of PTRACE seems like the better
> > place to spend time.
>
> Crushing irony of telling *me* this duly noted. ;-)
> I am not really sure what deeply different set of security constraints
> you envision on any other kind of new debugger interface that would be
> any different for the concerns you've expressed, though.

I haven't though too much about replacements, but it seems like having
a way for processes to declare who/what can debug them is the way to go.
I realize this is very close to MAC policy, but having this be more
general-purpose seems valuable.

Like, a different version of PTRACE_TRACEME, something like PTRACE_BY_YOU.
Imagined example with total lack of error checking and invalid syntax...

void segfault_handler(void) {
pid = horrible_dbus_insanity("spawn a debugger");
prctl(PR_SET_DEBUGGER, pid);
}

PTRACE_TRACEME would be effectively the same as:

void segfault_handler(void) {
if (pid = fork()) {
execl(debugger,getppid());
exit(1);
} else {
prctl(PR_SET_DEBUGGER, pid);
}
}

> > > I suspect you really want to test same_thread_group(walker, current).
> > > You don't actually mean to rule out a debugger that forks children with
> > > one thread and calls ptrace with another, do you?
> >
> > Won't they ultimately have the same parent, though?
>
> Sure, those debugger threads will have the same parent, such as the shell
> that spawned the debugger. But your "security" check is that the caller of
> ptrace is a direct ancestor of the tracee. The ancestry of that ptrace
> caller is immaterial.

Ah right, sorry, I was being too literal (thought in your example the
parent didn't fork a debugger and called ptrace on its children).

Right, this would probably solve the Chrome case, but not KDE, which seems
to fork the crash handler from very far away. I haven't looked too closely
there yet.

-Kees

--
Kees Cook
Ubuntu Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


ebiederm at xmission

Jun 17, 2010, 5:29 AM

Post #8 of 37 (5038 views)
Permalink
Re: [PATCH] ptrace: allow restriction of ptrace scope [In reply to]

Kees Cook <kees.cook [at] canonical> writes:

> As Linux grows in popularity, it will become a larger target for
> malware. One particularly troubling weakness of the Linux process
> interfaces is that a single user is able to examine the memory and
> running state of any of their processes. For example, if one application
> (e.g. Pidgin) was compromised, it would be possible for an attacker to
> attach to other running processes (e.g. Firefox, SSH sessions, GPG agent,
> etc) to extract additional credentials and continue to expand the scope
> of their attack without resorting to user-assisted phishing.
>
> This is not a theoretical problem. SSH session hijacking
> (http://www.storm.net.nz/projects/7) and arbitrary code injection
> (http://c-skills.blogspot.com/2007/05/injectso.html) attacks already
> exist and remain possible if PTRACE is allowed to operate as before.
> PTRACE is not commonly used by non-developers and non-admins, so system
> builders should be allowed the option to disable this debugging system.
>
> For a solution, some applications use prctl(PR_SET_DUMPABLE, ...) to
> specifically disallow such PTRACE attachment (e.g. ssh-agent), but many
> do not. A more general solution is to only allow PTRACE directly from a
> parent to a child process (i.e. direct "gdb EXE" and "strace EXE" still
> work), or with CAP_SYS_PTRACE (i.e. "gdb --pid=PID", and "strace -p PID"
> still work as root).
>
> This patch is based on the patch in grsecurity. It includes a sysctl
> to enable the behavior via /proc/sys/kernel/ptrace_scope. This could
> be expanded in the future to further restrict PTRACE to, for example,
> only CAP_SYS_PTRACE (scope 2) or only init (scope 3).

This is ineffective. As an attacker after I gain access to a users
system on ubuntu I can wait around until a package gets an update,
and then run sudo and gain the power to do whatever I want.

Either that or I can inject something nasty into the suid pulse-audio.

I tell you what. If you really want something effective, help Serge
and I finish getting the cross namespace issues fixed for the user
namespace. When complete, it will possible for an unprivileged process
to create a new one, and since kernel capabilities along with everything
else will be local to it, running pidgin, or firefox, or another network
facing potentially buggy application in such a namespace will ensure that
even if the process is compromised it won't have privileges to ptrace another
process or do much else on the system.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jmorris at namei

Jun 17, 2010, 6:45 AM

Post #9 of 37 (5031 views)
Permalink
Re: [PATCH] ptrace: allow restriction of ptrace scope [In reply to]

On Wed, 16 Jun 2010, Kees Cook wrote:

[.Note: it would be useful to cc: the LSM list on security discussions]

> Certainly. PTRACE can already be confined by SELinux and AppArmor. I'm
> looking for a general approach that doesn't require a system builder to
> create MAC policies for unknown software. I want to define a common core
> behavior.
>
> > And even if you don't care about using the same security stuff the rest
> > of the world is using to solve the problem this like the other half baked
> > stuff you posted for links belongs as a security module.
>
> The LSM isn't stackable, so I can't put it there and choose this and
> SELinux (for the case of software-without-a-policy).

SELinux already supports a global switch for ptrace via the allow_ptrace
boolean. You don't need to write any policy, just set it to 0.

Global behavior can be further customized and refined (e.g. create a
generic policy module for apps without an existing policy, which allows
everything except things like ptrace and dangerous symlinks).

SELinux users would not need the other LSM, and stacking is thus not
required.


- James
--
James Morris
<jmorris [at] namei>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


kees.cook at canonical

Jun 17, 2010, 9:59 AM

Post #10 of 37 (5035 views)
Permalink
Re: [PATCH] ptrace: allow restriction of ptrace scope [In reply to]

Hi,

On Thu, Jun 17, 2010 at 05:29:53AM -0700, Eric W. Biederman wrote:
> Kees Cook <kees.cook [at] canonical> writes:
> > running state of any of their processes. For example, if one application
> > (e.g. Pidgin) was compromised, it would be possible for an attacker to
> > attach to other running processes (e.g. Firefox, SSH sessions, GPG agent,
> > etc) to extract additional credentials and continue to expand the scope
> > of their attack without resorting to user-assisted phishing.
>
> This is ineffective. As an attacker after I gain access to a users
> system on ubuntu I can wait around until a package gets an update,
> and then run sudo and gain the power to do whatever I want.

I doesn't stop phishing, correct. But it does stop immediate expansion of
an attack using already-existing credentials.

> Either that or I can inject something nasty into the suid pulse-audio.

Hmm?

$ ls -la /usr/bin/pulseaudio
-rwxr-xr-x 1 root root 71712 2010-06-10 11:59 /usr/bin/pulseaudio

But I take your meaning to be "can still exploit other vulnerabilities".
That'll always be true, but that's why I'm looking to make the attack
surface smaller.

> I tell you what. If you really want something effective, help Serge
> and I finish getting the cross namespace issues fixed for the user
> namespace. When complete, it will possible for an unprivileged process
> to create a new one, and since kernel capabilities along with everything
> else will be local to it, running pidgin, or firefox, or another network
> facing potentially buggy application in such a namespace will ensure that
> even if the process is compromised it won't have privileges to ptrace another
> process or do much else on the system.

It sounds pretty good, but isolating desktop applications is no simple
task. They tend to like to have free reign over a user's entire home
directory. But I think that's a bit of a tangent. That said, I'd like to
know more; where can I find details?

I'm all for better separations. In fact, I'd like to see /proc/sys using
caps instead of DAC so that containers mounting /proc can't fiddle with the
entire system. Has anyone done anything with this? It seems like it's
only seen sporadic attention (e.g. my patch to test CAP_SYS_RAWIO for
changing mmap_min_addr). I would assume there are others that need a
similar protection?

-Kees

--
Kees Cook
Ubuntu Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


kees.cook at canonical

Jun 17, 2010, 10:04 AM

Post #11 of 37 (5035 views)
Permalink
Re: [PATCH] ptrace: allow restriction of ptrace scope [In reply to]

Hi James,

On Thu, Jun 17, 2010 at 11:45:42PM +1000, James Morris wrote:
> On Wed, 16 Jun 2010, Kees Cook wrote:
>
> [.Note: it would be useful to cc: the LSM list on security discussions]

Sorry, I was blindly using get_maintainer output.

> > Certainly. PTRACE can already be confined by SELinux and AppArmor. I'm
> > looking for a general approach that doesn't require a system builder to
> > create MAC policies for unknown software. I want to define a common core
> > behavior.
> >
> > > And even if you don't care about using the same security stuff the rest
> > > of the world is using to solve the problem this like the other half baked
> > > stuff you posted for links belongs as a security module.
> >
> > The LSM isn't stackable, so I can't put it there and choose this and
> > SELinux (for the case of software-without-a-policy).
>
> SELinux already supports a global switch for ptrace via the allow_ptrace
> boolean. You don't need to write any policy, just set it to 0.
>
> Global behavior can be further customized and refined (e.g. create a
> generic policy module for apps without an existing policy, which allows
> everything except things like ptrace and dangerous symlinks).
>
> SELinux users would not need the other LSM, and stacking is thus not
> required.

But if a user wants to disable ptrace using the SELinux LSM and then
also disable sticky-symlinks via the ItsHideous LSM, they're out of luck.

-Kees

--
Kees Cook
Ubuntu Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


ebiederm at xmission

Jun 17, 2010, 1:45 PM

Post #12 of 37 (5043 views)
Permalink
Re: [PATCH] ptrace: allow restriction of ptrace scope [In reply to]

Kees Cook <kees.cook [at] canonical> writes:

> Hi,
>
> On Thu, Jun 17, 2010 at 05:29:53AM -0700, Eric W. Biederman wrote:
>> Kees Cook <kees.cook [at] canonical> writes:
>> > running state of any of their processes. For example, if one application
>> > (e.g. Pidgin) was compromised, it would be possible for an attacker to
>> > attach to other running processes (e.g. Firefox, SSH sessions, GPG agent,
>> > etc) to extract additional credentials and continue to expand the scope
>> > of their attack without resorting to user-assisted phishing.
>>
>> This is ineffective. As an attacker after I gain access to a users
>> system on ubuntu I can wait around until a package gets an update,
>> and then run sudo and gain the power to do whatever I want.
>
> I doesn't stop phishing, correct. But it does stop immediate expansion of
> an attack using already-existing credentials.

sudo last I checked caches your password for a couple of seconds.
So if you can probe the system to see when those couple of seconds
are.


>> Either that or I can inject something nasty into the suid pulse-audio.
>
> Hmm?
>
> $ ls -la /usr/bin/pulseaudio
> -rwxr-xr-x 1 root root 71712 2010-06-10 11:59 /usr/bin/pulseaudio
>
> But I take your meaning to be "can still exploit other vulnerabilities".
> That'll always be true, but that's why I'm looking to make the attack
> surface smaller.

Yes. Apparently pulseaudio has been fixed recently.


>> I tell you what. If you really want something effective, help Serge
>> and I finish getting the cross namespace issues fixed for the user
>> namespace. When complete, it will possible for an unprivileged process
>> to create a new one, and since kernel capabilities along with everything
>> else will be local to it, running pidgin, or firefox, or another network
>> facing potentially buggy application in such a namespace will ensure that
>> even if the process is compromised it won't have privileges to ptrace another
>> process or do much else on the system.
>
> It sounds pretty good, but isolating desktop applications is no simple
> task. They tend to like to have free reign over a user's entire home
> directory. But I think that's a bit of a tangent. That said, I'd like to
> know more; where can I find details?

The archives of the containers list.
https://lists.linux-foundation.org/pipermail/containers/ or just
looking.

> I'm all for better separations. In fact, I'd like to see /proc/sys using
> caps instead of DAC so that containers mounting /proc can't fiddle with the
> entire system. Has anyone done anything with this? It seems like it's
> only seen sporadic attention (e.g. my patch to test CAP_SYS_RAWIO for
> changing mmap_min_addr).

Ugh. CAP_SYS_RAWIO???? That certainly does not feel like the proper
capability there. Which is among the reason I'm not a particular
fan of capabilities.

> I would assume there are others that need a similar protection?

Let me quickly summarize the plan. The current implementation of the
user_namespace is not much more than a place holder for what should be
implemented. We may want to rename the user_namespace to the security
credentials namespace when we are done.

All uids, gids, capabilities comparisons should change from.
if ( uid1 == uid2 ) to if ((user_ns1 == user_ns2) && uid1 == uid2).

Somewhere Serge has a git tree where he started making the capabilities
tests user_namespace local. Which means that when you create a process
that does not share the current user_namespace you will get a full
set of capabilities relative to the current user_namespace.

The tricky bits are:
- Working through the vfs logic, so that filesystems can be aware
of multiple user namespaces and can do what best suits them when
presented with a DAC security test.

proc will need to become uid namespace aware, different files
will become user namespace aware.

Things like /proc/sys/ will be default stay in the same user_namespace
and root in other user namespaces will only get world permissions when
accessing files.

- Correctly implementing and using ns_capable. Which makes the capabilities
caparison hierarchical. A few key capability comparisons like CAP_NET_ADMIN
will gradually be switched from a global capability comparison to a local one.

If you are inside a user_namespace your capabilities will only be
good for manipulating other objects (like the network namespace)
that you have created after you entered the user namespace, other
capability checks will fail because they will require the global
capability namespace.

The cute detail is that if you are not in a user namespace but are
the creator of that user_namespace you will be treated for the purposes
of security checks as having all capabilities that user_namespace
posses. Which will allow important things like the ability to kill
your children in a child user_namespace.

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


alan at lxorguk

Jun 17, 2010, 1:53 PM

Post #13 of 37 (5029 views)
Permalink
Re: [PATCH] ptrace: allow restriction of ptrace scope [In reply to]

> > SELinux users would not need the other LSM, and stacking is thus not
> > required.
>
> But if a user wants to disable ptrace using the SELinux LSM and then
> also disable sticky-symlinks via the ItsHideous LSM, they're out of luck.

Thats a nonsensical configuration so we don't care. If you are using
SELinux you just do it via SELinux. If you are doing it via
UbuntuHasToBeDifferent then you do it via that.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


rdunlap at xenotime

Jun 17, 2010, 2:06 PM

Post #14 of 37 (5038 views)
Permalink
Re: [PATCH] ptrace: allow restriction of ptrace scope [In reply to]

On Thu, 17 Jun 2010 21:53:49 +0100 Alan Cox wrote:

> > > SELinux users would not need the other LSM, and stacking is thus not
> > > required.
> >
> > But if a user wants to disable ptrace using the SELinux LSM and then
> > also disable sticky-symlinks via the ItsHideous LSM, they're out of luck.
>
> Thats a nonsensical configuration so we don't care. If you are using
> SELinux you just do it via SELinux. If you are doing it via
> UbuntuHasToBeDifferent then you do it via that.


Well, surely there are people who use something other than Ubuntu
and also care about not using SELinux... eh?


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


kees.cook at canonical

Jun 17, 2010, 2:14 PM

Post #15 of 37 (5031 views)
Permalink
Re: [PATCH] ptrace: allow restriction of ptrace scope [In reply to]

On Thu, Jun 17, 2010 at 01:45:02PM -0700, Eric W. Biederman wrote:
> Kees Cook <kees.cook [at] canonical> writes:
> > On Thu, Jun 17, 2010 at 05:29:53AM -0700, Eric W. Biederman wrote:
> >> Kees Cook <kees.cook [at] canonical> writes:
> >> > running state of any of their processes. For example, if one application
> >> > (e.g. Pidgin) was compromised, it would be possible for an attacker to
> >> > attach to other running processes (e.g. Firefox, SSH sessions, GPG agent,
> >> > etc) to extract additional credentials and continue to expand the scope
> >> > of their attack without resorting to user-assisted phishing.
> >>
> >> This is ineffective. As an attacker after I gain access to a users
> >> system on ubuntu I can wait around until a package gets an update,
> >> and then run sudo and gain the power to do whatever I want.
> >
> > I doesn't stop phishing, correct. But it does stop immediate expansion of
> > an attack using already-existing credentials.
>
> sudo last I checked caches your password for a couple of seconds.
> So if you can probe the system to see when those couple of seconds
> are.

Sure, that's a downside of sudo, which is why privilege elevation has been
tending to move towards PolicyKit, FWIW.

> The archives of the containers list.
> https://lists.linux-foundation.org/pipermail/containers/ or just
> looking.

I'll go dig around.

> Things like /proc/sys/ will be default stay in the same user_namespace
> and root in other user namespaces will only get world permissions when
> accessing files.

Excellent. I'll move my questions about this to the containers mailing
list.

-Kees

--
Kees Cook
Ubuntu Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


kees.cook at canonical

Jun 17, 2010, 2:16 PM

Post #16 of 37 (5029 views)
Permalink
Re: [PATCH] ptrace: allow restriction of ptrace scope [In reply to]

On Thu, Jun 17, 2010 at 02:06:30PM -0700, Randy Dunlap wrote:
> On Thu, 17 Jun 2010 21:53:49 +0100 Alan Cox wrote:
>
> > > > SELinux users would not need the other LSM, and stacking is thus not
> > > > required.
> > >
> > > But if a user wants to disable ptrace using the SELinux LSM and then
> > > also disable sticky-symlinks via the ItsHideous LSM, they're out of luck.
> >
> > Thats a nonsensical configuration so we don't care. If you are using
> > SELinux you just do it via SELinux. If you are doing it via
> > UbuntuHasToBeDifferent then you do it via that.
>
>
> Well, surely there are people who use something other than Ubuntu
> and also care about not using SELinux... eh?

And for them, it certainly seems like a good idea to be able to turn off
PTRACE without having to fiddle with an LSM.

--
Kees Cook
Ubuntu Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


alan at lxorguk

Jun 17, 2010, 2:18 PM

Post #17 of 37 (5028 views)
Permalink
Re: [PATCH] ptrace: allow restriction of ptrace scope [In reply to]

> > Thats a nonsensical configuration so we don't care. If you are using
> > SELinux you just do it via SELinux. If you are doing it via
> > UbuntuHasToBeDifferent then you do it via that.
>
>
> Well, surely there are people who use something other than Ubuntu
> and also care about not using SELinux... eh?

Then they can load UbuntuSecurity and use that, just enabling the
features they want.

I'm not against the Ubuntu stuff getting beaten into a security module
and put where it belongs. Far from it - I just want to see it put where
it belongs, which is not junk randomly spewed over the tree. Doubly so
when they do it wrong *because* they are not using the security hooks.

It seems pretty easy to me. Kees needs to package up the grsecurity
features that Ubuntu thinks are valuable into security/something/... with
a set of sysfs entries to turn on/off the various features. Ubuntu is
happy, people who want a simple set of sysfs feature controls for
security are happy and nobody else will even notice.

It'll appeal to some people because it looks easy to work and it won't
upset anyone else because its all nicely filed away where it belongs.

We don't put MSDOS fs hacks randomly all over the VFS[1], please don't try
and put security hacks into random bits of kernel code.

Alan
[1] Maybe we should be scarier, like Al ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


kees.cook at canonical

Jun 17, 2010, 2:51 PM

Post #18 of 37 (5040 views)
Permalink
Re: [PATCH] ptrace: allow restriction of ptrace scope [In reply to]

On Thu, Jun 17, 2010 at 10:18:15PM +0100, Alan Cox wrote:
> > > Thats a nonsensical configuration so we don't care. If you are using
> > > SELinux you just do it via SELinux. If you are doing it via
> > > UbuntuHasToBeDifferent then you do it via that.
> >
> >
> > Well, surely there are people who use something other than Ubuntu
> > and also care about not using SELinux... eh?
>
> Then they can load UbuntuSecurity and use that, just enabling the
> features they want.
>
> I'm not against the Ubuntu stuff getting beaten into a security module
> and put where it belongs. Far from it - I just want to see it put where
> it belongs, which is not junk randomly spewed over the tree. Doubly so
> when they do it wrong *because* they are not using the security hooks.
>
> It seems pretty easy to me. Kees needs to package up the grsecurity
> features that Ubuntu thinks are valuable into security/something/... with
> a set of sysfs entries to turn on/off the various features. Ubuntu is
> happy, people who want a simple set of sysfs feature controls for
> security are happy and nobody else will even notice.
>
> It'll appeal to some people because it looks easy to work and it won't
> upset anyone else because its all nicely filed away where it belongs.

If all I cared about was the default Ubuntu distro, I wouldn't forward
these patches at all. As it turns out, I care about all kinds of
configurations, e.g. people using SELinux on Ubuntu, AppArmor on SUSE,
no LSM on Fedora, grsecurity on Gentoo, or TOMOYO on Debian. There are
all kinds of combinations, obviously, and I'm interested in making this
stuff available to anyone and everyone.

The "just use SELinux" reply is tiresome. If "everyone" used SELinux,
there wouldn't be at least 3 other LSMs under active development.
Ignore that my email ends in "@canonical.com", as it seems to be
distracting these discussions.

The PTRACE, symlink, and other stuff are features people want. If the
point of your argument is that the logic and configuration for each
of these features should be added to every LSM, that's not sensible.
An end user should be able to pick and choose what they want. If I
create the security/hideous/ LSM tree, it would _exclude_ the ability to
use TOMOYO or Smack or SELinux or AppArmor.

At present, I'm aware of global PTRACE control being possible in SELinux,
AppArmor, grsecurity, and as a patch in Ubuntu's kernel. I don't know
about TOMOYO or Smack, but configuring the default scope of PTRACE in
at least 4 different ways so far (or not being able to change it at all)
just seems crazy.

If the security API allowed the end user to pick and choose the features
they wanted, then those features would be developed in a single place
and configured in a single way. Since that's not possible, I'm proposing
these features be central, and configured via /proc/sys.

-Kees

--
Kees Cook
Ubuntu Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


alan at lxorguk

Jun 17, 2010, 3:18 PM

Post #19 of 37 (5044 views)
Permalink
Re: [PATCH] ptrace: allow restriction of ptrace scope [In reply to]

> And for them, it certainly seems like a good idea to be able to turn off
> PTRACE without having to fiddle with an LSM.

But that *is* an LSM, its a security policy.

You don't seem to get it - even the default kernel security is a
security policy (security/commoncap.c etc)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


kees.cook at canonical

Jun 17, 2010, 3:25 PM

Post #20 of 37 (5041 views)
Permalink
Re: [PATCH] ptrace: allow restriction of ptrace scope [In reply to]

On Thu, Jun 17, 2010 at 11:18:59PM +0100, Alan Cox wrote:
> > And for them, it certainly seems like a good idea to be able to turn off
> > PTRACE without having to fiddle with an LSM.
>
> But that *is* an LSM, its a security policy.
>
> You don't seem to get it - even the default kernel security is a
> security policy (security/commoncap.c etc)

I do get it. I also get that every LSM calls out to commoncap, making
it effectively stacked with the primary LSM -- the only LSM that gets
stacked. In fact, this is how I even started implementing these features:
as patches to commoncap, but James preferred it to be in core since they
are of general utility. But core people want the changes in security/
instead.

I don't mind putting them in commoncap at all. I would just like people
to agree on what they disagree about. :)

-Kees

--
Kees Cook
Ubuntu Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


alan at lxorguk

Jun 17, 2010, 3:30 PM

Post #21 of 37 (5053 views)
Permalink
Re: [PATCH] ptrace: allow restriction of ptrace scope [In reply to]

> The "just use SELinux" reply is tiresome. If "everyone" used SELinux,
> there wouldn't be at least 3 other LSMs under active development.

People using SELinux, SMACK and the other LSMs already *have* this
feature (done right, unlike the version you posted).

> The PTRACE, symlink, and other stuff are features people want. If the
> point of your argument is that the logic and configuration for each
> of these features should be added to every LSM, that's not sensible.
> An end user should be able to pick and choose what they want. If I
> create the security/hideous/ LSM tree, it would _exclude_ the ability to
> use TOMOYO or Smack or SELinux or AppArmor.

This is like trying to have two different file systems on the same
partition at once. We tried stackability - the reason LSMs don't currently
stack neatly is because it turned out to be a very bad idea.

If you want to fix that by implementing a stacking LSM which has your
switches then do that.

> At present, I'm aware of global PTRACE control being possible in SELinux,
> AppArmor, grsecurity, and as a patch in Ubuntu's kernel. I don't know
> about TOMOYO or Smack, but configuring the default scope of PTRACE in
> at least 4 different ways so far (or not being able to change it at all)
> just seems crazy.

So you want to add a fifth. It won't replace the others because its not
as flexible. How does having five help ?

> If the security API allowed the end user to pick and choose the features
> they wanted, then those features would be developed in a single place
> and configured in a single way. Since that's not possible, I'm proposing
> these features be central, and configured via /proc/sys.

They *are* central, which is why we have the security directory and the
security hooks abstracted into one central location.

So if you care about everyone then do it right - put it in its own LSM.
After that or in parallel you can look at how it needs to interact to
make it stackable. That's a door that the integrity/ima work has partly
re-opened already.

Really you have three choices

- You can keep trying to put stuff in places it doesn't belong, in which
case you'll keep getting NAKs from people like Christoph and from Al
Viro and then give up.

- You can give up now.

- You can put it together as a security module - which will make people
happy and get your stuff upstream. After that you can have a meaningful
discussion about stacking, although I think you'll find that stacking
is really really hard because you get conflicting behaviour between
security modules and ignoring those conflicts ends up violating at least
one of the security models leaving you worse not better off.

Your path to making any of the stuff you want happen is via the security
layer and the LSM hooks. Even if you want them stackable and usable with
other modules your starting point is still a security module.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


alan at lxorguk

Jun 17, 2010, 3:34 PM

Post #22 of 37 (5037 views)
Permalink
Re: [PATCH] ptrace: allow restriction of ptrace scope [In reply to]

> I don't mind putting them in commoncap at all. I would just like people
> to agree on what they disagree about. :)

I don't believe they belong in commoncap, but as something which can sit
on top of commoncap and then be dropped into by the security modules that
makes total sense.

(Really thats just the stacking debate and how to dodge it ;))

Ie you'd have

optionally:
LSMs
optionally:
cap_switches
required:
commoncap
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


serge at hallyn

Jun 17, 2010, 3:50 PM

Post #23 of 37 (5041 views)
Permalink
Re: [PATCH] ptrace: allow restriction of ptrace scope [In reply to]

Quoting Eric W. Biederman (ebiederm [at] xmission):
> Kees Cook <kees.cook [at] canonical> writes:
> Somewhere Serge has a git tree where he started making the capabilities

FWIW I believe the latest one is

http://git.kernel.org/?p=linux/kernel/git/sergeh/linux-cr.git;a=shortlog;h=refs/heads/userns.feb16.1

I (/we) should get back to that... Though waiting for certain other
bits to settle (i.e. tagged sysfs and user-ns-safe SCM_CREDENTIALS)
isn't a bad thing.

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


jmorris at namei

Jun 17, 2010, 4:03 PM

Post #24 of 37 (5031 views)
Permalink
Re: [PATCH] ptrace: allow restriction of ptrace scope [In reply to]

On Thu, 17 Jun 2010, Alan Cox wrote:

> - You can put it together as a security module - which will make people
> happy and get your stuff upstream. After that you can have a meaningful
> discussion about stacking

It think this approach is worth pursuing, so that we can also see what's
there, and determine if there is a need for some form of stacking, or
whether we can consolidate some of this into library code which the
various LSMs utilize.

People who don't want to run SELinux / AppArmor / Smack / TOMOYO etc., run
can still get some protection.


- James
--
James Morris
<jmorris [at] namei>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


ebiederm at xmission

Jun 17, 2010, 4:11 PM

Post #25 of 37 (5051 views)
Permalink
Re: [PATCH] ptrace: allow restriction of ptrace scope [In reply to]

"Serge E. Hallyn" <serge [at] hallyn> writes:

> Quoting Eric W. Biederman (ebiederm [at] xmission):
>> Kees Cook <kees.cook [at] canonical> writes:
>> Somewhere Serge has a git tree where he started making the capabilities
>
> FWIW I believe the latest one is
>
> http://git.kernel.org/?p=linux/kernel/git/sergeh/linux-cr.git;a=shortlog;h=refs/heads/userns.feb16.1

Cool.

> I (/we) should get back to that... Though waiting for certain other
> bits to settle (i.e. tagged sysfs and user-ns-safe SCM_CREDENTIALS)
> isn't a bad thing.

Tagged sysfs is in 2.6.35-rc1+
user-ns-safe SCM_CREDENTIALS have merged to net-next.

ns_capable seems to be the next piece easy piece of the user_namespace.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

First page Previous page 1 2 Next page Last page  View All Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.