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

---
 Documentation/sysctl/kernel.txt |   16 ++++++++++++++++
 kernel/ptrace.c                 |   24 ++++++++++++++++++++++++
 kernel/sysctl.c                 |   10 ++++++++++
 3 files changed, 50 insertions(+), 0 deletions(-)

index 3894eaa..030f2f2 100644
@@ -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

index 74a3d69..5e7777a 100644
@@ -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);
 }

index d24f761..fcb61c3 100644
@@ -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

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

Hi Alan,

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

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.

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

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.

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

On Wed, 16 Jun 2010, Kees Cook wrote:

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

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

Sorry, I was blindly using get_maintainer output.

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

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

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

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

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

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.

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

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

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

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.

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.

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.

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

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

Here ya go, chaining for lsm security pointers:

http://lists.jammed.com/linux-security-module/2004/11/
http://lwn.net/Articles/114588/

:)

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

!

It's 35 years since my data structures course. What's the important difference between the two?

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.

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.

Yep.

Except for dealing with state maintenance it is absolutely trivial to implement chained LSMs.

Eric

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

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.

Hi,

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.

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

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.

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.

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

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

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

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

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

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,

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.

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.

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.

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

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

Okay, I can do that.

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

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

-Kees

Kees Cook
Ubuntu Security Team

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.

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

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

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);
	}
}

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

task->pid always holds the global pid, so 0 and 1 will be the global idle and init tasks.

As for this particular patch,

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

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

Hi,

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

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.

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

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.

Yes. Apparently pulseaudio has been fixed recently.

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

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.

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

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

I'll go dig around.

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

-Kees

Kees Cook
Ubuntu Security Team

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

Cool.

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