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 <[email protected]>
---
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
> 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
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
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
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
> 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
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
Kees Cook <[email protected]> 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
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
<[email protected]>
Hi,
On Thu, Jun 17, 2010 at 05:29:53AM -0700, Eric W. Biederman wrote:
> Kees Cook <[email protected]> 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
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
Kees Cook <[email protected]> writes:
> Hi,
>
> On Thu, Jun 17, 2010 at 05:29:53AM -0700, Eric W. Biederman wrote:
>> Kees Cook <[email protected]> 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
> > 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.
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 ***
> > 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 ;)
On Thu, Jun 17, 2010 at 01:45:02PM -0700, Eric W. Biederman wrote:
> Kees Cook <[email protected]> writes:
> > On Thu, Jun 17, 2010 at 05:29:53AM -0700, Eric W. Biederman wrote:
> >> Kees Cook <[email protected]> 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
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
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
> 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)
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
> 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
> 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
Quoting Eric W. Biederman ([email protected]):
> Kees Cook <[email protected]> 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
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
<[email protected]>
"Serge E. Hallyn" <[email protected]> writes:
> Quoting Eric W. Biederman ([email protected]):
>> Kees Cook <[email protected]> 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
Alan Cox wrote:
>> 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.
>
That's not quite how I remember it, and at the time I was on the
anti-stacking side. My recollection is that the issue was not that
stacking was a bad idea but that stacking SELinux and AppArmor was
a bad idea. Stacking two "complete" security "solutions" is still
as bad an idea today as it was at the turn of the century. That
was followed by an extended period during which there was only one
LSM and not a whole lot of incentive to make sure that the LSM
remained a clean interface.
> If you want to fix that by implementing a stacking LSM which has your
> switches then do that.
>
I have changed from anti-stacking to pro-stacking for the simple
reason that where I used to think that is was possible to create
a single cohesive security story in an OS I now believe that doing
so is only possible in a brand new OS, and that the best we can do
in the face of an install base is provide for the rapid deployment
of schemes that make sense to people born after the Orange Book
was published. And no, you can't do that with SELinux policies.
>
>> 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.
>
I agree. Worst (Best?) case is everyone sees how great it is and
it gets pulled out of your LSM and into the "code proper". I seem
to recall a movement to do that with another LSM a few years back,
and the fact that it didn't happen there doesn't mean it can't
happen ever.
> Alan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
i think we really need to have stacked LSM's, because there is a large set
of people who will never use SELinux. Every few years, I take another
look at SELinux, my head explodes with the (IMHO unneeded complexity),
and I go away again...
Yet I would really like a number of features such as this ptrace scope idea ---
which I think is a useful feature, and it may be that stacking is the only
way we can resolve this debate. The SELinux people will never believe that
their system is too complicated, and I don't like using things that are impossible
for me to understand or configure, and that doesn't seem likely to change anytime
in the near future.
I mean, even IPSEC RFC's are easier for me to understand, and that's saying
a lot...
-- Ted
Quoting Roland McGrath ([email protected]):
> > 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.
task->pid always holds the global pid, so 0 and 1 will be the global idle
and init tasks.
As for this particular patch,
Quoting Kees Cook ([email protected]):
>> 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.
Well that's why I like to run things like firefox, irc clients, etc each
as their own userid. That also protects my ssh keys from irc client. But
things like clicking urls in terminals to fire them up in a browser
aren't usually hooked up right when you do that. Not that it'd be
impossible to do right.
Anyway, if you're going to do this (sounds like, as a tiny-lsm?), how
about replacing the sysctl with a per-task flag which, once set,
can't be unset? Then firefox can mark itself unable-to-ptrace (or I
can do so in a wrapper before calling firefox.real), after which it
cannot strace anything which isn't its descendent, but I can still
strace firefox from my shell. Of course, don't bother with that
change unless someone seconds the suggestion, in case ppl don't like
it and ask you to change it back :)
-serge
Theodore Tso <[email protected]> writes:
> i think we really need to have stacked LSM's, because there is a large set
> of people who will never use SELinux. Every few years, I take another
> look at SELinux, my head explodes with the (IMHO unneeded complexity),
> and I go away again...
>
> Yet I would really like a number of features such as this ptrace scope idea ---
> which I think is a useful feature, and it may be that stacking is the only
> way we can resolve this debate. The SELinux people will never believe that
> their system is too complicated, and I don't like using things that are impossible
> for me to understand or configure, and that doesn't seem likely to change anytime
> in the near future.
>
> I mean, even IPSEC RFC's are easier for me to understand, and that's saying
> a lot...
If anyone is going to work on this let me make a concrete suggestion.
Let's aim at not stacked lsm's but chained lsm's, and put the chaining
logic in the lsm core.
The core difficulty appears to be how do you multiplex the security pointers
on various objects out there.
My wishlist has this working so that I can logically have a local security
policy in a container, restricted by the global policy but with additional
restrictions.
Eric
Quoting Eric W. Biederman ([email protected]):
> Theodore Tso <[email protected]> writes:
>
> > i think we really need to have stacked LSM's, because there is a large set
> > of people who will never use SELinux. Every few years, I take another
> > look at SELinux, my head explodes with the (IMHO unneeded complexity),
> > and I go away again...
> >
> > Yet I would really like a number of features such as this ptrace scope idea ---
> > which I think is a useful feature, and it may be that stacking is the only
> > way we can resolve this debate. The SELinux people will never believe that
> > their system is too complicated, and I don't like using things that are impossible
> > for me to understand or configure, and that doesn't seem likely to change anytime
> > in the near future.
> >
> > I mean, even IPSEC RFC's are easier for me to understand, and that's saying
> > a lot...
>
>
> If anyone is going to work on this let me make a concrete suggestion.
> Let's aim at not stacked lsm's but chained lsm's, and put the chaining
> logic in the lsm core.
>
> The core difficulty appears to be how do you multiplex the security pointers
> on various objects out there.
Here ya go, chaining for lsm security pointers:
http://lists.jammed.com/linux-security-module/2004/11/
http://lwn.net/Articles/114588/
:)
> My wishlist has this working so that I can logically have a local security
> policy in a container, restricted by the global policy but with additional
> restrictions.
At the upcoming linux security summit[1], colocated with linuxcon, Kees is going
to be doing a talk 'widely used but out of tree', where presumably the topic
of stacking LSMs will come back up.
If we were going to seriously consider stacking LSMs again, I'd want to
dig through archives to produce a precise list of previous issues, so we
can build on that to try and design something which might work. So
I guess I'm suggesting a beer BOF for the evening or next day for
discussing design in more detail.
The general answer tends to be "generic stacking doesn't work, LSMs
need to know about each other." But even for that (as evidenced by
the selinux+commoncap experience with stacking) is hairy, and more
to the point it probably does not scale when we have 5-10 small
LSMs. I.e. LSM 1 wants to prevent some action while LSM 2 requires
that action to succeed so that it can properly prevent another
action. Concrete examples are buried in the stacker discussions
on the lsm list from 2004-2005.
Mind you, I'm not interested in doing a stacking patchset myself again,
would prefer to spend my time on user namespaces. I'm not even sure
which side of the stacking-vs-nostacking fence I'll be on, except that I
always prefer to discuss based on experience with real code than
pie-in-the-skie arguments, so would encourage patches. I do suspect
once we better understand user namespaces we may have want for fewer
little LSMs. So someone else can have all the fun to themselves :)
-serge
[1] https://security.wiki.kernel.org/index.php/LinuxSecuritySummit2010
Hi,
On Thu, Jun 17, 2010 at 11:30:54PM +0100, Alan Cox wrote:
> - You can give up now.
Failure is always an option! :) Nah, I was never deluded into thinking
these patches were going to be universally-loved and easy to upstream.
I posted them because I want them in, and I'm going to stick with it.
> - 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.
Sounds like this really is the only path, with the idea of finding a
chaining solution later. Without chaining, it's only useful for people
that aren't using a full MAC.
-Kees
--
Kees Cook
Ubuntu Security Team
Kees Cook wrote:
> 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.
Security modules supported by distributor's kernels are one of benchmarks for
Linux users when deciding distro to use. But it is just one of benchmarks.
Linux users do not decide distro only with security modules supported by
distributor's kernels. Linux users choose distro with various benchmarks.
Forcing Linux users to choose specific distro which supports SELinux in order
to use ptrace restriction is nonsense.
> The "just use SELinux" reply is tiresome. If "everyone" used SELinux,
> there wouldn't be at least 3 other LSMs under active development.
SELinux indeed has many functionalities. But SELinux cannot provide ability to
perform restriction based on pathnames. "SELinux can do everything" is wrong.
If there were an all-in-one application that supports web browsing, mail,
writing, music, chat, scheduler etc., will "everyone" use that all-in-one
application? At least, I won't use it because it is too complicated to use.
I use X-desktop only when I need to use. I use SSH terminal if I can achieve
what I want to do. I'm not happy with spending my time for understanding how to
configure X-desktop.
Being unable to configure SELinux by Linux users leads to SELinux being
unavailable for Linux users. If something is blocked by SELinux, Linux users
simply set SELINUX=disabled in /etc/selinux/config rather than finding how to
configure SELinux because they don't know what functionalities are provided by
SELinux and which configuration is wrong.
Linux users are seeking for solutions that they can understand and configure
by themselves.
> 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.
I have strong complaint about closed nature of LSM community. I believe Linux
kernel's duty is to serve userspace applications and Linux users. But whenever
discussion about access control arises, the conclusion comes from Linux kernel
developer's viewpoint rather than Linux user's viewpoint; i.e. "You can do it
using SELinux (or netfilter or whatever in-tree code). Thus spend your time for
understanding how to configure it". But that is too difficult for Linux users.
No LSM module can provide all functionalities. When users want to introduce a
security mechanism that provides specific functionalities, LSM is the only
choice. This forces users to give up other security mechanisms that provide
different functionalities because LSM is exclusive.
Windows users are picking and choosing what they want for security, and are
experiencing what combinations are good and what combinations are bad at their
own risk. But Linux users can't because LSM developers complain conflicts and
deprive Linux users of chances for experiencing what combinations are good and
what combinations are bad.
LSM modules can't be loaded upon runtime since 2.6.24. 2.6.24 strengthened the
barrier for Linux users when they want to choose different security module
because replacing vmlinux is a very very high barrier.
Linux is behind Windows regarding security hooks.
Linux kernel's duty is to serve userspace applications and Linux users, no?
Why not to provide Linux users ability to pick and choose what they want at
their own risk (rather than complaining conflicts forever)?
Eric W. Biederman wrote:
> Theodore Tso <[email protected]> writes:
>
>
>> i think we really need to have stacked LSM's,
!
>> because there is a large set
>> of people who will never use SELinux. Every few years, I take another
>> look at SELinux, my head explodes with the (IMHO unneeded complexity),
>> and I go away again...
>>
>> Yet I would really like a number of features such as this ptrace scope idea ---
>> which I think is a useful feature, and it may be that stacking is the only
>> way we can resolve this debate. The SELinux people will never believe that
>> their system is too complicated, and I don't like using things that are impossible
>> for me to understand or configure, and that doesn't seem likely to change anytime
>> in the near future.
>>
>> I mean, even IPSEC RFC's are easier for me to understand, and that's saying
>> a lot...
>>
>
>
> If anyone is going to work on this let me make a concrete suggestion.
> Let's aim at not stacked lsm's but chained lsm's, and put the chaining
> logic in the lsm core.
>
It's 35 years since my data structures course. What's the important
difference between the two?
> The core difficulty appears to be how do you multiplex the security pointers
> on various objects out there.
>
That and making sure that the hooks that maintain state get called
even if the decision to deny access has already been made by someone
else.
> My wishlist has this working so that I can logically have a local security
> policy in a container, restricted by the global policy but with additional
> restrictions.
>
> Eric
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
>
Casey Schaufler <[email protected]> writes:
> Eric W. Biederman wrote:
>> Theodore Tso <[email protected]> writes:
>>
>>
>>> i think we really need to have stacked LSM's,
>
> !
>
>>> because there is a large set
>>> of people who will never use SELinux. Every few years, I take another
>>> look at SELinux, my head explodes with the (IMHO unneeded complexity),
>>> and I go away again...
>>>
>>> Yet I would really like a number of features such as this ptrace scope idea ---
>>> which I think is a useful feature, and it may be that stacking is the only
>>> way we can resolve this debate. The SELinux people will never believe that
>>> their system is too complicated, and I don't like using things that are impossible
>>> for me to understand or configure, and that doesn't seem likely to change anytime
>>> in the near future.
>>>
>>> I mean, even IPSEC RFC's are easier for me to understand, and that's saying
>>> a lot...
>>>
>>
>>
>> If anyone is going to work on this let me make a concrete suggestion.
>> Let's aim at not stacked lsm's but chained lsm's, and put the chaining
>> logic in the lsm core.
>>
>
> It's 35 years since my data structures course. What's the important
> difference between the two?
Who takes responsibility for making it work, and where you implement
it. If it is in the LSM it is a feature all LSMs automatically
support it. If it is stacked it is an LSM by LSM feature.
Basically implementing chaining is just a walk over a list of
security_operations and calling the appropriate method on each one.
Stacked LSMs at least as I saw it in selinux was the implementation of
each security operation doing calling internally calling the secondary
lsm's security options. Which seems to me to be more code, and harder
to maintain, and a setup that encourages politics.
>> The core difficulty appears to be how do you multiplex the security pointers
>> on various objects out there.
>>
>
> That and making sure that the hooks that maintain state get called
> even if the decision to deny access has already been made by someone
> else.
Yep.
Except for dealing with state maintenance it is absolutely trivial
to implement chained LSMs.
Eric
Kees Cook <[email protected]> writes:
> [...] 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. [...]
For the curious, below is a demonstration an interactive systemtap
script that can implement this sort of local policy, independently of
the other security APIs.
http://sourceware.org/systemtap/examples/keyword-index.html#SECURITY
just a user sammy sysadmin
=========== ==============
8232% echo $$
8232
root# noptrace.stp -x 8232 &
8232% do-stuff &
[1] 8888
root# cat /proc/systemtap/stap_*/blocked
8232 /bin/bash
8888 /usr/local/bin/do-stuff
8232% strace ls
strace: ptrace(PTRACE_TRACEME, ...): No such process
8232% gdb do-stuff 8888
Attaching to program: /usr/local/bin/do-stuff, process 8888
ptrace: No such process.
root# echo 8232 > /proc/systemtap/stap_*/unblock
8232% strace ls
[...working again...]
- FChE
On Fri, 18 Jun 2010, Theodore Tso wrote:
> Yet I would really like a number of features such as this ptrace scope idea ---
> which I think is a useful feature, and it may be that stacking is the only
> way we can resolve this debate.
We've already reached a consensus that these things should be put into a
separate LSM so we can evaluate the possible need for some form of
stacking or a security library API.
Note that people using SELinux or AppArmor already have the ability to
restrict ptrace, and they would thus not need to stack this function if it
were in a separate LSM.
Do you have a use-case where stacking would be useful here?
- James
--
James Morris
<[email protected]>
On Mon, 21 Jun 2010 10:52:11 +1000, James Morris said:
> Note that people using SELinux or AppArmor already have the ability to
> restrict ptrace, and they would thus not need to stack this function if it
> were in a separate LSM.
That's assuming they can figure out how to write and integrate the required
policy changes. Looking inside selinux-policy-3.8.3-4.fc14.src.rpm from Fedora
Rawhide: (Holy cow, there's a .git tree in that tarball - no wonder it's 20M in
size).
% cd serefpolicy-3.8.3/policy/modules; wc -l */* | grep total
135967 total
135kloc of policy that probably nobody in your shop really understands. At
that point, writing something that stacks starts sounding really enticing.