security: Yama LSM

PATCH Superseded Kees Cook 7 participants 32 messages Oct 26, 2011 – Nov 28, 2011

Subsystems (7)

Documentation MM core Scheduler Security (LSM) +3 more subsystems

lore

Share & tools

lore

Kees Cook

author

2011-10-26 23:59 UTC #0 lore raw

v6 cover security: Yama LSM

As discussed at the Linux Security Summit, I'm resubmitting this code. As an LSM, it has coherent policy around expanding specific DAC behaviors. There is no need for it to be a full-blown MAC, since it is not intended to be one, but rather to be a simplified expansion to DAC, with system-wide knobs. See the specific patches for details...

Thanks,

-Kees

Kees Cook

author

2011-10-26 23:59 UTC #1 lore raw

PATCH v6 1/3 security: Yama LSM

This adds the Yama Linux Security Module to collect several DAC security improvements (symlink, hardlink, and ptrace restrictions) that have existed in various forms over the years and have been carried outside the mainline kernel by other Linux distributions like Openwall and grsecurity.

As discussed at the Linux Security Summit, I'm resending this patchset since it has value to a few distros. It was observed that while Yama is not a MAC, this isn't required for an LSM. It has a distinct policy, one that enhances DAC security, and that will continue to be its role as an LSM.

Signed-off-by Kees Cook <[email protected]>

---
v6:
- Fix interaction with overlayfs, thanks to Andy Whitcroft and Leann Ogasawara.
- Clarify rationale for LSM.
- Move documentation under security subdirectory.
v5:
- resend, with ptrace relationship interface
v4:
- drop accidentally included fs/exec.c chunk.
v3:
- drop needless cap_ callbacks.
- fix usage of get_task_comm.
- drop CONFIG_ of sysctl defaults, as recommended by Andi Kleen.
- require SYSCTL.
v2:
- add rcu locking, thanks to Tetsuo Handa.
- add Documentation/Yama.txt for summary of features.

---
 Documentation/security/Yama.txt |   91 ++++++++++++++
 security/Kconfig                |    6 +
 security/Makefile               |    2 +
 security/yama/Kconfig           |   14 ++
 security/yama/Makefile          |    3 +
 security/yama/yama_lsm.c        |  250 +++++++++++++++++++++++++++++++++++++++
 6 files changed, 366 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/security/Yama.txt
 create mode 100644 security/yama/Kconfig
 create mode 100644 security/yama/Makefile
 create mode 100644 security/yama/yama_lsm.c

Documentation/security/Yama.txt new file +91 -0

new file mode 100644
index 0000000..1916742
@@ -0,0 +1,91 @@
+Yama is a Linux Security Module that collects a number of system-wide DAC
+security protections that are not handled by the core kernel itself. To
+select it at boot time, specify "security=yama" (though this will disable
+any other LSM).
+
+Yama is controlled through sysctl in /proc/sys/kernel/yama:
+
+- protected_sticky_symlinks
+- protected_nonaccess_hardlinks
+- ptrace_scope
+
+==============================================================
+
+protected_sticky_symlinks:
+
+A long-standing class of security issues is the symlink-based
+time-of-check-time-of-use race, most commonly seen in world-writable
+directories like /tmp. The common method of exploitation of this flaw
+is to cross privilege boundaries when following a given symlink (i.e. a
+root process follows a symlink belonging to another user). For a likely
+incomplete list of hundreds of examples across the years, please see:
+http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=/tmp
+
+When set to "0", symlink following behavior is unrestricted.
+
+When set to "1" symlinks are permitted to be followed only when outside
+a sticky world-writable directory, or when the uid of the symlink and
+follower match, or when the directory owner matches the symlink's owner.
+
+This protection is based on the restrictions in Openwall and grsecurity.
+
+==============================================================
+
+protected_nonaccess_hardlinks:
+
+Hardlinks can be abused in a similar fashion to symlinks in sticky
+world-writable directories, but their weakness is not limited to
+just that scenario. For example, if /etc and /home are on the same
+partition, a regular user can create a hardlink to /etc/shadow in their
+home directory. While it retains the original owner and permissions,
+it is possible for privileged programs that are otherwise symlink-safe
+to mistakenly access the file through its hardlink. Additionally, a very
+minor untraceable quota-bypassing local denial of service is possible by
+an attacker exhausting disk space by filling a world-writable directory
+with hardlinks.
+
+When set to "0", hardlink creation behavior is unrestricted.
+
+When set to "1", hardlinks cannot be created to files that a given user
+would be unable to read and write originally, or are otherwise sensitive.
+
+This protection is based on the restrictions in Openwall and grsecurity.
+
+==============================================================
+
+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.
+Since ptrace is not commonly used by non-developers and non-admins, 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).
+
+0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other
+    process running under the same uid, as long as it is dumpable (i.e.
+    did not transition uids, start privileged, or have called
+    prctl(PR_SET_DUMPABLE...) already).
+
+1 - restricted ptrace: a process can only call PTRACE_ATTACH on its
+    descendants when the above classic criteria is also met.
+
+This protection is based on the restrictions in grsecurity.
+
+==============================================================

security/Kconfig +6 -0

index 51bd5a0..ccc61f8 100644
@@ -187,6 +187,7 @@ source security/selinux/Kconfig
 source security/smack/Kconfig
 source security/tomoyo/Kconfig
 source security/apparmor/Kconfig
+source security/yama/Kconfig
 
 source security/integrity/Kconfig

@@ -196,6 +197,7 @@ choice
 	default DEFAULT_SECURITY_SMACK if SECURITY_SMACK
 	default DEFAULT_SECURITY_TOMOYO if SECURITY_TOMOYO
 	default DEFAULT_SECURITY_APPARMOR if SECURITY_APPARMOR
+	default DEFAULT_SECURITY_YAMA if SECURITY_YAMA
 	default DEFAULT_SECURITY_DAC
 
 	help

@@ -214,6 +216,9 @@ choice
 	config DEFAULT_SECURITY_APPARMOR
 		bool "AppArmor" if SECURITY_APPARMOR=y
 
+	config DEFAULT_SECURITY_YAMA
+		bool "Yama" if SECURITY_YAMA=y
+
 	config DEFAULT_SECURITY_DAC
 		bool "Unix Discretionary Access Controls"

@@ -225,6 +230,7 @@ config DEFAULT_SECURITY
 	default "smack" if DEFAULT_SECURITY_SMACK
 	default "tomoyo" if DEFAULT_SECURITY_TOMOYO
 	default "apparmor" if DEFAULT_SECURITY_APPARMOR
+	default "yama" if DEFAULT_SECURITY_YAMA
 	default "" if DEFAULT_SECURITY_DAC
 
 endmenu

security/Makefile +2 -0

index a5e502f..c26c81e 100644
@@ -7,6 +7,7 @@ subdir-$(CONFIG_SECURITY_SELINUX)	+= selinux
 subdir-$(CONFIG_SECURITY_SMACK)		+= smack
 subdir-$(CONFIG_SECURITY_TOMOYO)        += tomoyo
 subdir-$(CONFIG_SECURITY_APPARMOR)	+= apparmor
+subdir-$(CONFIG_SECURITY_YAMA)		+= yama
 
 # always enable default capabilities
 obj-y					+= commoncap.o

@@ -21,6 +22,7 @@ obj-$(CONFIG_SECURITY_SMACK)		+= smack/built-in.o
 obj-$(CONFIG_AUDIT)			+= lsm_audit.o
 obj-$(CONFIG_SECURITY_TOMOYO)		+= tomoyo/built-in.o
 obj-$(CONFIG_SECURITY_APPARMOR)		+= apparmor/built-in.o
+obj-$(CONFIG_SECURITY_YAMA)		+= yama/built-in.o
 obj-$(CONFIG_CGROUP_DEVICE)		+= device_cgroup.o
 
 # Object integrity file lists

security/yama/Kconfig new file +14 -0

new file mode 100644
index 0000000..1a5d1c1
@@ -0,0 +1,14 @@
+config SECURITY_YAMA
+	bool "Yama support"
+	depends on SECURITY
+	select SECURITYFS
+	select SECURITY_PATH
+	default n
+	help
+	  This selects Yama, which extends DAC support with additional
+	  system-wide security settings beyond regular Linux discretionary
+	  access controls. Currently available are symlink, hardlink, and
+	  ptrace scope restrictions. Further information can be found in
+	  Documentation/security/Yama.txt.
+
+	  If you are unsure how to answer this question, answer N.

security/yama/Makefile new file +3 -0

new file mode 100644
index 0000000..8b5e065
@@ -0,0 +1,3 @@
+obj-$(CONFIG_SECURITY_YAMA) := yama.o
+
+yama-y := yama_lsm.o

security/yama/yama_lsm.c new file +250 -0

250 lines not on this page · raw message

Signature · 1 line

1.7.5.4

Kees Cook

author

2011-10-26 23:59 UTC #2 lore raw

PATCH v6 2/3 security: create task_free security callback

In reply to Kees Cook

The current LSM interface to cred_free is not sufficient for allowing an LSM to track the life and death of a task. This patch adds the task_free hook so that an LSM can clean up resources on task death.

Signed-off-by Kees Cook <[email protected]>

---
 include/linux/security.h |    9 +++++++++
 kernel/fork.c            |    1 +
 security/capability.c    |    4 ++++
 security/security.c      |    5 +++++
 4 files changed, 19 insertions(+), 0 deletions(-)

include/linux/security.h +9 -0

index 19d8e04..256befc 100644
@@ -650,6 +650,10 @@ static inline void security_free_mnt_opts(struct security_mnt_opts *opts)
  *	manual page for definitions of the @clone_flags.
  *	@clone_flags contains the flags indicating what should be shared.
  *	Return 0 if permission is granted.
+ * @task_free:
+ *	@task task being freed
+ *	Handle release of task-related resources. (Note that this can be called
+ *  from interrupt context.)
  * @cred_alloc_blank:
  *	@cred points to the credentials.
  *	@gfp indicates the atomicity of any memory allocations.

@@ -1500,6 +1504,7 @@ struct security_operations {
 	int (*dentry_open) (struct file *file, const struct cred *cred);
 
 	int (*task_create) (unsigned long clone_flags);
+	void (*task_free) (struct task_struct *task);
 	int (*cred_alloc_blank) (struct cred *cred, gfp_t gfp);
 	void (*cred_free) (struct cred *cred);
 	int (*cred_prepare)(struct cred *new, const struct cred *old,

@@ -1762,6 +1767,7 @@ int security_file_send_sigiotask(struct task_struct *tsk,
 int security_file_receive(struct file *file);
 int security_dentry_open(struct file *file, const struct cred *cred);
 int security_task_create(unsigned long clone_flags);
+void security_task_free(struct task_struct *task);
 int security_cred_alloc_blank(struct cred *cred, gfp_t gfp);
 void security_cred_free(struct cred *cred);
 int security_prepare_creds(struct cred *new, const struct cred *old, gfp_t gfp);

@@ -2273,6 +2279,9 @@ static inline int security_task_create(unsigned long clone_flags)
 	return 0;
 }
 
+static inline void security_task_free(struct task_struct *task)
+{ }
+
 static inline int security_cred_alloc_blank(struct cred *cred, gfp_t gfp)
 {
 	return 0;

kernel/fork.c +1 -0

index 8e6b6f4..6371378 100644
@@ -190,6 +190,7 @@ void __put_task_struct(struct task_struct *tsk)
 	WARN_ON(atomic_read(&tsk->usage));
 	WARN_ON(tsk == current);
 
+	security_task_free(tsk);
 	exit_creds(tsk);
 	delayacct_tsk_free(tsk);
 	put_signal_struct(tsk->signal);

security/capability.c +4 -0

index 2984ea4..e4206b5 100644
@@ -359,6 +359,9 @@ static int cap_task_create(unsigned long clone_flags)
 	return 0;
 }
 
+static void cap_task_free(struct task_struct *task)
+{ }
+
 static int cap_cred_alloc_blank(struct cred *cred, gfp_t gfp)
 {
 	return 0;

@@ -955,6 +958,7 @@ void __init security_fixup_ops(struct security_operations *ops)
 	set_to_cap_if_null(ops, file_receive);
 	set_to_cap_if_null(ops, dentry_open);
 	set_to_cap_if_null(ops, task_create);
+	set_to_cap_if_null(ops, task_free);
 	set_to_cap_if_null(ops, cred_alloc_blank);
 	set_to_cap_if_null(ops, cred_free);
 	set_to_cap_if_null(ops, cred_prepare);

security/security.c +5 -0

index 0c6cc69..49a7227 100644
@@ -749,6 +749,11 @@ int security_task_create(unsigned long clone_flags)
 	return security_ops->task_create(clone_flags);
 }
 
+void security_task_free(struct task_struct *task)
+{
+	security_ops->task_free(task);
+}
+
 int security_cred_alloc_blank(struct cred *cred, gfp_t gfp)
 {
 	return security_ops->cred_alloc_blank(cred, gfp);

Signature · 1 line

1.7.5.4

Kees Cook

author

2011-10-26 23:59 UTC #3 lore raw

PATCH v6 3/3 security: Yama: add ptrace relationship tracking interface

In reply to Kees Cook

Some application suites have external crash handlers that depend on being able to use ptrace to generate crash reports (KDE, Wine, Chromium, Firefox, etc). Since the inferior process has a defined application-specific relationship with the debugger, allow the inferior to express that relationship by declaring who can call PTRACE_ATTACH against it. The inferior can use prctl() with PR_SET_PTRACER to allow a specific PID and its descendants to perform the ptrace instead of only a direct ancestor.

Signed-off-by Kees Cook <[email protected]>

---
v5:
- Use _bh spinlocks, thanks to Ming Lei.
v4:
- make sure to use thread group leader when creating exceptions.
v3:
- make sure to use thread group leader when searching for exceptions.
v2:
- kmalloc, spinlock init, and doc typo corrections from Tetsuo Handa.
- make sure to replace if possible on add, thanks to Eric Paris.

---
 Documentation/security/Yama.txt |   18 +++-
 include/linux/prctl.h           |    6 +
 security/yama/yama_lsm.c        |  240 ++++++++++++++++++++++++++++++++++++---
 3 files changed, 243 insertions(+), 21 deletions(-)

Documentation/security/Yama.txt +15 -3

index 1916742..9a83aa5 100644
@@ -78,14 +78,26 @@ 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).
 
+For software that has defined application-specific relationships
+between a debugging process and its inferior (crash handlers, etc),
+prctl(PR_SET_PTRACER, pid, ...) can be used. An inferior can declare which
+other process (and its descendents) are allowed to call PTRACE_ATTACH
+against it. For example, this is used by KDE, Chromium, and Firefox's
+crash handlers, and by Wine for allowing only Wine processes to ptrace
+each other.
+
 0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other
     process running under the same uid, as long as it is dumpable (i.e.
     did not transition uids, start privileged, or have called
     prctl(PR_SET_DUMPABLE...) already).
 
-1 - restricted ptrace: a process can only call PTRACE_ATTACH on its
-    descendants when the above classic criteria is also met.
+1 - restricted ptrace: a process must have a predefined relationship
+    with the inferior it wants to call PTRACE_ATTACH on. By default,
+    this relationship is that of only its descendants when the above
+    classic criteria is also met. To change the relationship, an
+    inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare
+    an allowed debugger PID to call PTRACE_ATTACH on the inferior.
 
-This protection is based on the restrictions in grsecurity.
+The original children-only logic was based on the restrictions in grsecurity.
 
 ==============================================================

include/linux/prctl.h +6 -0

index a3baeb2..da7837b 100644
@@ -102,4 +102,10 @@
 
 #define PR_MCE_KILL_GET 34
 
+/*
+ * Set specific pid that is allowed to PTRACE the current task.
+ * A value of 0 mean "no process".
+ */
+#define PR_SET_PTRACER 0x59616d61
+
 #endif /* _LINUX_PRCTL_H */

security/yama/yama_lsm.c +222 ~~-18~~

270 lines not on this page · raw message

Signature · 1 line

1.7.5.4

Vasiliy Kulikov

2011-11-19 16:30 UTC #4 lore raw

Re: [PATCH 3/3] security: Yama: add ptrace relationship tracking interface

Hi Kees,

Thank you for working on this! We'll use Yama in Openwall too :-)

security/yama/yama_lsm.c static int yama_ptrace_access_check(struct task_struct *child, · line 257

Quoted 6 lines · Kees Cook

security/yama/yama_lsm.c +6 -0

+	if (mode == PTRACE_MODE_ATTACH &&
+	    ptrace_scope &&
+	    !capable(CAP_SYS_PTRACE) &&
+	    !task_is_descendant(current, child) &&
+	    !ptracer_exception_found(current, child))
+		rc = -EPERM;

capable() is better to put after all other tests as a failed capable() might emit a false positive warning into logs or something.

Thanks,

Signature · 1 line

Vasiliy

Solar Designer

2011-11-19 16:59 UTC #5 lore raw

Re: [PATCH 3/3] security: Yama: add ptrace relationship tracking interface

Quoted 9 lines · Vasiliy Kulikov

security/yama/yama_lsm.c static int yama_ptrace_access_check(struct task_struct *child, · line 257
Quoted 6 lines · Kees Cook
security/yama/yama_lsm.c +6 -0
+	if (mode == PTRACE_MODE_ATTACH &&
+	    ptrace_scope &&
+	    !capable(CAP_SYS_PTRACE) &&
+	    !task_is_descendant(current, child) &&
+	    !ptracer_exception_found(current, child))
+		rc = -EPERM;
capable() is better to put after all other tests

Right, but...

Quoted 2 lines

as a failed capable()
might emit a false positive warning into logs or something.

...primarily for another reason: a successful capable() sets PF_SUPERPRIV, whereas the permission might have been granted without capable() as well. The PF_SUPERPRIV flag is visible via BSD process accounting.

Alexander

Kees Cook

author

2011-11-21 18:40 UTC #6 lore raw

Re: [PATCH 3/3] security: Yama: add ptrace relationship tracking interface

Quoted 13 lines · Solar Designer

Quoted 9 lines · Vasiliy Kulikov
Quoted 6 lines · Kees Cook
+ if (mode == PTRACE_MODE_ATTACH &&
+ ptrace_scope &&
+ !capable(CAP_SYS_PTRACE) &&
+ !task_is_descendant(current, child) &&
+ !ptracer_exception_found(current, child))
+ rc = -EPERM;
capable() is better to put after all other tests
Right, but...

Quoted 7 lines

Quoted 2 lines
as a failed capable()
might emit a false positive warning into logs or something.
...primarily for another reason: a successful capable() sets PF_SUPERPRIV, whereas the permission might have been granted without capable() as well. The PF_SUPERPRIV flag is visible via BSD process accounting.

Fair point, I'll move it. I had to go look up an earlier thread since this was ringing a bell, but in there I was talking about moving it to the end of the tests too. :)

https://lkml.org/lkml/2010/6/30/5

-Kees

Signature · 2 lines

Kees Cook
ChromeOS Security

James Morris

maintainer

2011-11-01 20:45 UTC #7 lore raw

In reply to Kees Cook

Quoted 5 lines · Kees Cook

As discussed at the Linux Security Summit, I'm resubmitting this code. As an LSM, it has coherent policy around expanding specific DAC behaviors. There is no need for it to be a full-blown MAC, since it is not intended to be one, but rather to be a simplified expansion to DAC, with system-wide knobs. See the specific patches for details...

Yes, there was a strong consensus (unanimous I believe) at the security summit on incorporating the Yama LSM as a container for generally useful miscellaneous security hardening features that don't belong elsewhere.

This means that LSM is no longer 'officially' only for access control mechanisms.

We probably need to flesh out criteria for inclusion in Yama and document it.

- James

Signature · 2 lines

James Morris
<[email protected]>

Kees Cook

author

2011-11-01 21:05 UTC #8 lore raw

Quoted 8 lines · James Morris

Quoted 5 lines · Kees Cook
As discussed at the Linux Security Summit, I'm resubmitting this code. As an LSM, it has coherent policy around expanding specific DAC behaviors. There is no need for it to be a full-blown MAC, since it is not intended to be one, but rather to be a simplified expansion to DAC, with system-wide knobs. See the specific patches for details...

Quoted 6 lines

Yes, there was a strong consensus (unanimous I believe) at the security summit on incorporating the Yama LSM as a container for generally useful miscellaneous security hardening features that don't belong elsewhere.
This means that LSM is no longer 'officially' only for access control mechanisms.

That would be very welcome.

Quoted 2 lines

We probably need to flesh out criteria for inclusion in Yama and document it.

What's the best way for me to help with that documentation?

Thanks,

-Kees

--
Kees Cook
ChromeOS Security

James Morris

maintainer

2011-11-01 21:37 UTC #9 lore raw

Quoted 4 lines · Kees Cook

Quoted 2 lines
We probably need to flesh out criteria for inclusion in Yama and document it.
What's the best way for me to help with that documentation?

Perhaps post a basic document for review. It doesn't have to be a novel.

One thing I'd like to see is making it clear that if a feature is nacked by a core maintainer, Yama is not a means to bypass that nack. That maintainer will need to ack it as part of Yama, too.

- James

Signature · 2 lines

James Morris
<[email protected]>

Kees Cook

author

2011-11-01 23:23 UTC #10 lore raw

Quoted 8 lines · James Morris

Quoted 4 lines · Kees Cook
Quoted 2 lines
We probably need to flesh out criteria for inclusion in Yama and document it.
What's the best way for me to help with that documentation?
Perhaps post a basic document for review. It doesn't have to be a novel.

I've sent this now. We can expand it further if needed.

Quoted 3 lines

One thing I'd like to see is making it clear that if a feature is nacked by a core maintainer, Yama is not a means to bypass that nack. That maintainer will need to ack it as part of Yama, too.

At the same time, Yama isn't intended to be an endless dumping ground for all random things. It's intended to be a place to put DAC extensions that make sense for general system hardening. I can clarify that further in the Yama documentation, if that's not already clear.

-Kees

Signature · 2 lines

Kees Cook
ChromeOS Security

James Morris

maintainer

2011-11-18 04:17 UTC #11 lore raw

In reply to Kees Cook

Quoted 5 lines · Kees Cook

As discussed at the Linux Security Summit, I'm resubmitting this code. As an LSM, it has coherent policy around expanding specific DAC behaviors. There is no need for it to be a full-blown MAC, since it is not intended to be one, but rather to be a simplified expansion to DAC, with system-wide knobs. See the specific patches for details...

In principle, Yama can be merged, however there are features with unresolved upstream naks:

- Handling symlinks in sticky directories
- The ptrace tracker

These still need to be resolved.

Signature · 2 lines

James Morris
<[email protected]>

Kees Cook

author

2011-11-18 21:39 UTC #12 lore raw

Quoted 8 lines · James Morris

Quoted 5 lines · Kees Cook
As discussed at the Linux Security Summit, I'm resubmitting this code. As an LSM, it has coherent policy around expanding specific DAC behaviors. There is no need for it to be a full-blown MAC, since it is not intended to be one, but rather to be a simplified expansion to DAC, with system-wide knobs. See the specific patches for details...

Quoted 7 lines

In principle, Yama can be merged, however there are features with unresolved upstream naks:
- Handling symlinks in sticky directories
- The ptrace tracker
These still need to be resolved.

Oleg, Roland,

Do you have any objection to my LSM performing ptrace restrictions? It's entirely self-contained, and all the major upstream crash handlers are already using the prctl() interface it uses to declare ptrace attach relationships.

Thanks,

-Kees

Signature · 2 lines

Kees Cook
ChromeOS Security

Roland McGrath

2011-11-18 21:45 UTC #13 lore raw

Quoted 4 lines

Do you have any objection to my LSM performing ptrace restrictions? It's entirely self-contained, and all the major upstream crash handlers are already using the prctl() interface it uses to declare ptrace attach relationships.

I don't have the context of what your LSM does. But other LSMs apply their own rules in security_ptrace(). That's what the hook is for. I'm not sure why we would object from the perspective of core ptrace functionality. LSMs are LSMs. Their behavior is between you and your users, as far as I am concerned. As experts on ptrace and aficionados of its users, we may have thoughts on what constraints on ptrace users would find annoying. But that doesn't mean we'd object per se to whatever bizarre constraints users want to ask an LSM to put on them.

Thanks,
Roland

Kees Cook

author

2011-11-18 22:44 UTC #14 lore raw

Quoted 5 lines · Roland McGrath

Quoted 4 lines
Do you have any objection to my LSM performing ptrace restrictions? It's entirely self-contained, and all the major upstream crash handlers are already using the prctl() interface it uses to declare ptrace attach relationships.

Quoted 8 lines

I don't have the context of what your LSM does. But other LSMs apply their own rules in security_ptrace(). That's what the hook is for. I'm not sure why we would object from the perspective of core ptrace functionality. LSMs are LSMs. Their behavior is between you and your users, as far as I am concerned. As experts on ptrace and aficionados of its users, we may have thoughts on what constraints on ptrace users would find annoying. But that doesn't mean we'd object per se to whatever bizarre constraints users want to ask an LSM to put on them.

Yup, that's precisely what Yama does as well. Sounds like you're not naking an LSM that uses security_ptrace(), then.

Thanks!

-Kees

Signature · 2 lines

Kees Cook
ChromeOS Security

Kees Cook

author

2011-11-18 23:18 UTC #15 lore raw

In reply to James Morris

Quoted 8 lines · James Morris

Quoted 5 lines · Kees Cook
As discussed at the Linux Security Summit, I'm resubmitting this code. As an LSM, it has coherent policy around expanding specific DAC behaviors. There is no need for it to be a full-blown MAC, since it is not intended to be one, but rather to be a simplified expansion to DAC, with system-wide knobs. See the specific patches for details...

Quoted 4 lines

In principle, Yama can be merged, however there are features with unresolved upstream naks:
- Handling symlinks in sticky directories

Also hardlink restrictions (disallow hardlinking to anything that a user doesn't have read/write access to -- breaks no software, solves actual vulnerabilities).

Quoted 3 lines

- The ptrace tracker
These still need to be resolved.

Hi Al,

I know you're not a fan of LSMs in general, but can you let Yama extend DAC in these two cases (symlink and hardlink restrictions) for the distros and admins that want these specific, decades-old, well-established tweaks to how links work? Other LSMs handle policy via these hooks, and Yama is just doing the same thing.

Thanks,

-Kees

Signature · 2 lines

Kees Cook
ChromeOS Security

Vasiliy Kulikov

2011-11-21 19:18 UTC #16 lore raw

RFC 1/1 Make Yama pid_ns aware

In reply to Kees Cook

Hi,

As Yama's sysctls are about defining a security policy for the system, it is reasonable to define it per container in case of LXC containers (or out-of-tree alternatives like OpenVZ). In my opinion they belong to pid namespace. With per-pid_ns sysctls it is possible to create multiple containers with different ptrace, /tmp, etc. policies.

As Yama is not merged yet, I post the patch in this thread.

The patch is straightforward:

1) all sysctl variables are moved from global vars to pid_namespace fields.

2) each cloned pid ns gets the settings of the parent.

3) the variables of current pid ns are visible through sysctl interface.

proc_pid_dointvec_minmax() is stolen from its ipc_ns equivalent in ipc/ipc_sysctl.c.

(The patch is not tested.)

include/linux/pid_namespace.h +5 -0

index 38d1032..46edaf8 100644
@@ -30,6 +30,11 @@ struct pid_namespace {
 #ifdef CONFIG_BSD_PROCESS_ACCT
 	struct bsd_acct_struct *bacct;
 #endif
+#ifdef CONFIG_SECURITY_YAMA
+	int ptrace_scope;
+	int protected_sticky_symlinks;
+	int protected_nonaccess_hardlinks;
+#endif
 };
 
 extern struct pid_namespace init_pid_ns;

kernel/pid.c +5 -0

index fa5f722..0cd8926 100644
@@ -78,6 +78,11 @@ struct pid_namespace init_pid_ns = {
 	.last_pid = 0,
 	.level = 0,
 	.child_reaper = &init_task,
+#ifdef CONFIG_SECURITY_YAMA
+	.ptrace_scope = 1,
+	.protected_sticky_symlinks = 1,
+	.protected_nonaccess_hardlinks = 1,
+#endif
 };
 EXPORT_SYMBOL_GPL(init_pid_ns);

kernel/pid_namespace.c +8 -0

index e9c9adc..73d47c4 100644
@@ -101,6 +101,14 @@ static struct pid_namespace *create_pid_namespace(struct pid_namespace *parent_p
 	if (err)
 		goto out_put_parent_pid_ns;
 
+#ifdef CONFIG_SECURITY_YAMA
+	ns->ptrace_scope = parent_pid_ns->ptrace_scope;
+	ns->protected_sticky_symlinks =
+		parent_pid_ns->protected_sticky_symlinks;
+	ns->protected_nonaccess_hardlinks =
+		parent_pid_ns->protected_nonaccess_hardlinks;
+#endif
+
 	return ns;
 
 out_put_parent_pid_ns:

security/yama/yama_lsm.c +30 ~~-13~~

95 lines not on this page · raw message

---

Kees Cook

author

2011-11-21 19:42 UTC #17 lore raw

Re: [RFC] Make Yama pid_ns aware

Quoted 5 lines · Vasiliy Kulikov

As Yama's sysctls are about defining a security policy for the system, it is reasonable to define it per container in case of LXC containers (or out-of-tree alternatives like OpenVZ). In my opinion they belong to pid namespace. With per-pid_ns sysctls it is possible to create multiple containers with different ptrace, /tmp, etc. policies.

Cool, this seems like a good idea. Thanks for the patch! If Serge (or other folks thinking about per-pid_ns stuff) think this is a good approach, I'm happy to include it in the next revision of the Yama patchset.

Quoted 2 lines

proc_pid_dointvec_minmax() is stolen from its ipc_ns equivalent in ipc/ipc_sysctl.c.

I wonder if this function should be moved into a common location, in case other things will want to do similar things.

-Kees

Signature · 2 lines

Kees Cook
ChromeOS Security

Serge Hallyn

2011-11-22 18:13 UTC #18 lore raw

Re: [RFC] Make Yama pid_ns aware

In reply to Vasiliy Kulikov

Quoted 7 lines · Vasiliy Kulikov

Hi,
As Yama's sysctls are about defining a security policy for the system, it is reasonable to define it per container in case of LXC containers (or out-of-tree alternatives like OpenVZ). In my opinion they belong to pid namespace. With per-pid_ns sysctls it is possible to create multiple containers with different ptrace, /tmp, etc. policies.

tying the ptrace policy to pidns makes some sense, but is it definately what we want?

Is the idea that the container should never be able to bypass the restrictions, or should root in the container eventually be able to bypass it as he can on the host?

Would a securebits interface be more or less suitable? It would allow per-process setting, inherited from parent on fork. It would however not allow a root shell on the desktop, after the fact, saying that a running gdb should be allowed to access firefox. But, it would be able to say "I, from now on, am exempt, so that I can debug the running firefox", without the rest of the system having its setting changed.

Quoted 177 lines

As Yama is not merged yet, I post the patch in this thread.

The patch is straightforward:

1) all sysctl variables are moved from global vars to pid_namespace fields.

2) each cloned pid ns gets the settings of the parent.

3) the variables of current pid ns are visible through sysctl interface.

proc_pid_dointvec_minmax() is stolen from its ipc_ns equivalent in ipc/ipc_sysctl.c.

(The patch is not tested.)

include/linux/pid_namespace.h +5 -0

index 38d1032..46edaf8 100644
@@ -30,6 +30,11 @@ struct pid_namespace {
 #ifdef CONFIG_BSD_PROCESS_ACCT
 	struct bsd_acct_struct *bacct;
 #endif
+#ifdef CONFIG_SECURITY_YAMA
+	int ptrace_scope;
+	int protected_sticky_symlinks;
+	int protected_nonaccess_hardlinks;
+#endif
 };
 
 extern struct pid_namespace init_pid_ns;

kernel/pid.c +5 -0

index fa5f722..0cd8926 100644
@@ -78,6 +78,11 @@ struct pid_namespace init_pid_ns = {
 	.last_pid = 0,
 	.level = 0,
 	.child_reaper = &init_task,
+#ifdef CONFIG_SECURITY_YAMA
+	.ptrace_scope = 1,
+	.protected_sticky_symlinks = 1,
+	.protected_nonaccess_hardlinks = 1,
+#endif
 };
 EXPORT_SYMBOL_GPL(init_pid_ns);

kernel/pid_namespace.c +8 -0

index e9c9adc..73d47c4 100644
@@ -101,6 +101,14 @@ static struct pid_namespace *create_pid_namespace(struct pid_namespace *parent_p
 	if (err)
 		goto out_put_parent_pid_ns;
 
+#ifdef CONFIG_SECURITY_YAMA
+	ns->ptrace_scope = parent_pid_ns->ptrace_scope;
+	ns->protected_sticky_symlinks =
+		parent_pid_ns->protected_sticky_symlinks;
+	ns->protected_nonaccess_hardlinks =
+		parent_pid_ns->protected_nonaccess_hardlinks;
+#endif
+
 	return ns;
 
 out_put_parent_pid_ns:

security/yama/yama_lsm.c +30 ~~-15~~

index a92538c..cf99a8c 100644
@@ -16,10 +16,7 @@
 #include <linux/ptrace.h>
 #include <linux/prctl.h>
 #include <linux/ratelimit.h>
-
-static int ptrace_scope = 1;
-static int protected_sticky_symlinks = 1;
-static int protected_nonaccess_hardlinks = 1;
+#include <linux/pid_namespace.h>
 
 /* describe a PTRACE relationship for potential exception */
 struct ptrace_relation {

@@ -250,7 +247,7 @@ static int yama_ptrace_access_check(struct task_struct *child,
 
 	/* require ptrace target be a child of ptracer on attach */
 	if (mode == PTRACE_MODE_ATTACH &&
-	    ptrace_scope &&
+	    current->nsproxy->pid_ns->ptrace_scope &&
 	    !capable(CAP_SYS_PTRACE) &&
 	    !task_is_descendant(current, child) &&
 	    !ptracer_exception_found(current, child))

@@ -292,7 +289,7 @@ static int yama_inode_follow_link(struct dentry *dentry,
 	const struct inode *inode;
 	const struct cred *cred;
 
-	if (!protected_sticky_symlinks)
+	if (!current->nsproxy->pid_ns->protected_sticky_symlinks)
 		return 0;
 
 	/* if inode isn't a symlink, don't try to evaluate blocking it */

@@ -362,7 +359,7 @@ static int yama_path_link(struct dentry *old_dentry, struct path *new_dir,
 	const int mode = inode->i_mode;
 	const struct cred *cred = current_cred();
 
-	if (!protected_nonaccess_hardlinks)
+	if (!current->nsproxy->pid_ns->protected_nonaccess_hardlinks)
 		return 0;
 
 	if (cred->fsuid != inode->i_uid &&

@@ -395,6 +392,26 @@ static struct security_operations yama_ops = {
 static int zero;
 static int one = 1;
 
+static void *get_pid_data(ctl_table *table)
+{
+	char *which = table->data;
+	struct pid_namespace *pid_ns = current->nsproxy->pid_ns;
+	which = (which - (char *)&init_pid_ns) + (char *)pid_ns;
+	return which;
+}
+
+static int proc_pid_dointvec_minmax(ctl_table *table, int write,
+	void __user *buffer, size_t *lenp, loff_t *ppos)
+{
+	struct ctl_table pid_table;
+
+	memcpy(&pid_table, table, sizeof(pid_table));
+	pid_table.data = get_pid_data(table);
+
+	return proc_dointvec_minmax(&pid_table, write, buffer, lenp, ppos);
+}
+
+
 struct ctl_path yama_sysctl_path[] = {
 	{ .procname = "kernel", },
 	{ .procname = "yama", },

@@ -404,28 +421,28 @@ struct ctl_path yama_sysctl_path[] = {
 static struct ctl_table yama_sysctl_table[] = {
 	{
 		.procname       = "protected_sticky_symlinks",
-		.data           = &protected_sticky_symlinks,
+		.data           = &init_pid_ns.protected_sticky_symlinks,
 		.maxlen         = sizeof(int),
 		.mode           = 0644,
-		.proc_handler   = proc_dointvec_minmax,
+		.proc_handler   = proc_pid_dointvec_minmax,
 		.extra1         = &zero,
 		.extra2         = &one,
 	},
 	{
 		.procname       = "protected_nonaccess_hardlinks",
-		.data           = &protected_nonaccess_hardlinks,
+		.data           = &init_pid_ns.protected_nonaccess_hardlinks,
 		.maxlen         = sizeof(int),
 		.mode           = 0644,
-		.proc_handler   = proc_dointvec_minmax,
+		.proc_handler   = proc_pid_dointvec_minmax,
 		.extra1         = &zero,
 		.extra2         = &one,
 	},
 	{
 		.procname       = "ptrace_scope",
-		.data           = &ptrace_scope,
+		.data           = &init_pid_ns.ptrace_scope,
 		.maxlen         = sizeof(int),
 		.mode           = 0644,
-		.proc_handler   = proc_dointvec_minmax,
+		.proc_handler   = proc_pid_dointvec_minmax,
 		.extra1         = &zero,
 		.extra2         = &one,
 	},
---
--

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

Vasiliy Kulikov

2011-11-22 19:20 UTC #19 lore raw

Re: [RFC] Make Yama pid_ns aware

Hi Serge,

Quoted 7 lines · Serge Hallyn

Quoted 5 lines · Vasiliy Kulikov
As Yama's sysctls are about defining a security policy for the system, it is reasonable to define it per container in case of LXC containers (or out-of-tree alternatives like OpenVZ). In my opinion they belong to pid namespace. With per-pid_ns sysctls it is possible to create multiple containers with different ptrace, /tmp, etc. policies.

Quoted 6 lines

tying the ptrace policy to pidns makes some sense, but is it definately what we want?
Is the idea that the container should never be able to bypass the restrictions, or should root in the container eventually be able to bypass it as he can on the host?

In-container root already has CAP_SYS_PTRACE, so he can avoid the check even if Yama's ptrace policy is enabled.

Quoted 2 lines

Would a securebits interface be more or less suitable? It would allow per-process setting, inherited from parent on fork.

IMHO securebits doesn't belong to such finegrained type of things. I don't find anything dangerous for privileged process (i.e. with CAP_SYS_ADMIN and CAP_SYS_PTRACE) to be able to fork from ptrace-restricted pid namespace, unshare pid namespace and relax ptrace policy. Because (1) process which is able to do unshare is already able to ptrace everybody and (2) unshared namespace cannot explicitly interact with parent namespace.

Quoted 6 lines

It would however
not allow a root shell on the desktop, after the fact, saying that a running gdb should be allowed to access firefox. But, it would be able to say "I, from now on, am exempt, so that I can debug the running firefox", without the rest of the system having its setting changed.

Thanks,

Signature · 2 lines

Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

Serge Hallyn

2011-11-22 20:10 UTC #20 lore raw

Re: [RFC] Make Yama pid_ns aware

Quoted 13 lines · Vasiliy Kulikov

Hi Serge,
Quoted 10 lines · Serge Hallyn
Quoted 5 lines · Vasiliy Kulikov
As Yama's sysctls are about defining a security policy for the system, it is reasonable to define it per container in case of LXC containers (or out-of-tree alternatives like OpenVZ). In my opinion they belong to pid namespace. With per-pid_ns sysctls it is possible to create multiple containers with different ptrace, /tmp, etc. policies.
tying the ptrace policy to pidns makes some sense, but is it definately what we want?

Quoted 6 lines

Quoted 3 lines
Is the idea that the container should never be able to bypass the restrictions, or should root in the container eventually be able to bypass it as he can on the host?
In-container root already has CAP_SYS_PTRACE, so he can avoid the check even if Yama's ptrace policy is enabled.

Well, not necessarily :) But in general.

But still, is turning this on and off per-container, and leaving it off on the host, something people will reasonably want to do? I'm just wondering whether adding the extra data on the pidns is worth it. It's fine if it is, but I'm having a hard time imagining someone using it like that.

thanks,
-serge

Vasiliy Kulikov

2011-11-23 07:45 UTC #21 lore raw

Re: [RFC] Make Yama pid_ns aware

Quoted 14 lines · Serge Hallyn

Quoted 13 lines · Vasiliy Kulikov
Hi Serge,
Quoted 10 lines · Serge Hallyn
Quoted 5 lines · Vasiliy Kulikov
As Yama's sysctls are about defining a security policy for the system, it is reasonable to define it per container in case of LXC containers (or out-of-tree alternatives like OpenVZ). In my opinion they belong to pid namespace. With per-pid_ns sysctls it is possible to create multiple containers with different ptrace, /tmp, etc. policies.
tying the ptrace policy to pidns makes some sense, but is it definately what we want?

Quoted 8 lines

Quoted 6 lines
Quoted 3 lines
Is the idea that the container should never be able to bypass the restrictions, or should root in the container eventually be able to bypass it as he can on the host?
In-container root already has CAP_SYS_PTRACE, so he can avoid the check even if Yama's ptrace policy is enabled.
Well, not necessarily :) But in general.

This is the question is what in-container root is :-) Until LXC root is restricted up to the case where he is unable to get out of the container in the mainline kernel, I assume we're talking about an abstract entity which has full control over the container. It includes stuff like CAP_CHOWN, CAP_KILL, CAP_SYS_PTRACE, CAP_NET_ADMIN, etc. etc. The debatable thing is what parts of CAP_SYS_ADMIN belong to in-container root, like ability to mount/umount. But CAP_SYS_PTRACE is surely belongs to the in-container root.

Quoted 2 lines

But still, is turning this on and off per-container, and leaving it off on the host, something people will reasonably want to do?

Probably we need strict rules like ptrace is relaxed iff in both source ns and dest ns ptrace is relaxed.

Quoted 4 lines

I'm just
wondering whether adding the extra data on the pidns is worth it. It's fine if it is, but I'm having a hard time imagining someone using it like that.

We have already very big net_namespace with all kind of per-ns stuff. Yama's variables don't significantly increase the size of container.

Actually, what concerns me is not ptrace, but symlink/hardling protection. There is no interaction between namespaces in case of containers via symlinks in the basic case. In case of ptrace I don't think the child ns may weaken the parent ns - child ns may not access processes of the parent namespace and everything it may ptrace is already inside of this ns.

Thanks,

Signature · 2 lines

Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

Serge Hallyn

2011-11-23 14:41 UTC #22 lore raw

Re: [RFC] Make Yama pid_ns aware

Quoted 5 lines · Vasiliy Kulikov

Quoted 2 lines
But still, is turning this on and off per-container, and leaving it off on the host, something people will reasonably want to do?
Probably we need strict rules like ptrace is relaxed iff in both source ns and dest ns ptrace is relaxed.

But will people want that?

Quoted 7 lines

Quoted 4 lines
I'm just
wondering whether adding the extra data on the pidns is worth it. It's fine if it is, but I'm having a hard time imagining someone using it like that.
We have already very big net_namespace with all kind of per-ns stuff. Yama's variables don't significantly increase the size of container.

Yes I'm not complaining about the extra host memory usage, just trying to make sure we don't pollute the pidns struct with something noone wants

Quoted 6 lines

Actually, what concerns me is not ptrace, but symlink/hardling protection. There is no interaction between namespaces in case of containers via symlinks in the basic case. In case of ptrace I don't think the child ns may weaken the parent ns - child ns may not access processes of the parent namespace and everything it may ptrace is already inside of this ns.

User namespace being respected by VFS will help symlinking.

-serge

Serge E. Hallyn

maintainer

2011-11-23 14:49 UTC #23 lore raw

Re: [RFC] Make Yama pid_ns aware

In reply to Vasiliy Kulikov

Quoted 6 lines · Vasiliy Kulikov

Actually, what concerns me is not ptrace, but symlink/hardling protection. There is no interaction between namespaces in case of containers via symlinks in the basic case. In case of ptrace I don't think the child ns may weaken the parent ns - child ns may not access processes of the parent namespace and everything it may ptrace is already inside of this ns.

Oh, yes. If you're saying the symlink protection shouldn't be per-pidns, I agree it seems an odd fit.

How about a version of this patch leaving symlink protection out of pidns (maybe in user ns), and just putting ptrace protection per-pidns?

-serge

Vasiliy Kulikov

2011-11-23 16:55 UTC #24 lore raw

Re: [RFC] Make Yama pid_ns aware

Quoted 8 lines · Serge E. Hallyn

Quoted 6 lines · Vasiliy Kulikov
Actually, what concerns me is not ptrace, but symlink/hardling protection. There is no interaction between namespaces in case of containers via symlinks in the basic case. In case of ptrace I don't think the child ns may weaken the parent ns - child ns may not access processes of the parent namespace and everything it may ptrace is already inside of this ns.

Quoted 6 lines

Oh, yes. If you're saying the symlink protection shouldn't be per-pidns, I agree it seems an odd fit.
How about a version of this patch leaving symlink protection out of pidns (maybe in user ns), and just putting ptrace protection per-pidns?

I don't think moving symlink/hardling from pid ns to user ns is a good idea as user ns is not matured yet. Also we (Openwall) want to use Yama almost as-is in our RHEL6 and RHEL5-based kernels with OpenVZ support which don't have user namespaces yet at all (yes, it is not a cause for mainline decisions :-) ).

While user ns is not yet ready, I don't clearly see what is the division of security policies among namespaces including user namespace. I had a view that all stuff related to processes (i.e. distinct processes in several ways) belongs to pid ns, all net stuff to net ns, etc. If we differentiate user ns and pid ns, only strictly things handling pids (like kill(2), procfs, ptrace(2), etc.) belong to pid ns and all other process-related stuff (like credentials handling, these symlink/hardling things, etc.) belong to user namespaces.

Can we probably leave them in pid ns for now and when user ns is matured just move it from pid ns to user ns? Is it possible without breaking Yama's ABI (I think so)?

Thanks,

Signature · 2 lines

Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

Serge Hallyn

2011-11-23 17:00 UTC #25 lore raw

Re: [RFC] Make Yama pid_ns aware

Quoted 31 lines · Vasiliy Kulikov

Quoted 8 lines · Serge E. Hallyn
Quoted 6 lines · Vasiliy Kulikov
Actually, what concerns me is not ptrace, but symlink/hardling protection. There is no interaction between namespaces in case of containers via symlinks in the basic case. In case of ptrace I don't think the child ns may weaken the parent ns - child ns may not access processes of the parent namespace and everything it may ptrace is already inside of this ns.
Quoted 6 lines
Oh, yes. If you're saying the symlink protection shouldn't be per-pidns, I agree it seems an odd fit.
How about a version of this patch leaving symlink protection out of pidns (maybe in user ns), and just putting ptrace protection per-pidns?
I don't think moving symlink/hardling from pid ns to user ns is a good idea as user ns is not matured yet. Also we (Openwall) want to use Yama almost as-is in our RHEL6 and RHEL5-based kernels with OpenVZ support which don't have user namespaces yet at all (yes, it is not a cause for mainline decisions :-) ).
While user ns is not yet ready, I don't clearly see what is the division of security policies among namespaces including user namespace. I had a view that all stuff related to processes (i.e. distinct processes in several ways) belongs to pid ns, all net stuff to net ns, etc. If we differentiate user ns and pid ns, only strictly things handling pids (like kill(2), procfs, ptrace(2), etc.) belong to pid ns and all other process-related stuff (like credentials handling, these symlink/hardling things, etc.) belong to user namespaces.

Quoted 3 lines

Can we probably leave them in pid ns for now and when user ns is matured just move it from pid ns to user ns? Is it possible without breaking Yama's ABI (I think so)?

That's fine with me.

thanks,
-serge

Kees Cook

author

2011-11-28 18:12 UTC #26 lore raw

Re: [RFC] Make Yama pid_ns aware

In reply to Vasiliy Kulikov

Quoted 31 lines · Vasiliy Kulikov

Quoted 8 lines · Serge E. Hallyn
Quoted 6 lines · Vasiliy Kulikov
Actually, what concerns me is not ptrace, but symlink/hardling protection. There is no interaction between namespaces in case of containers via symlinks in the basic case. In case of ptrace I don't think the child ns may weaken the parent ns - child ns may not access processes of the parent namespace and everything it may ptrace is already inside of this ns.
Quoted 6 lines
Oh, yes. If you're saying the symlink protection shouldn't be per-pidns, I agree it seems an odd fit.
How about a version of this patch leaving symlink protection out of pidns (maybe in user ns), and just putting ptrace protection per-pidns?
I don't think moving symlink/hardling from pid ns to user ns is a good idea as user ns is not matured yet. Also we (Openwall) want to use Yama almost as-is in our RHEL6 and RHEL5-based kernels with OpenVZ support which don't have user namespaces yet at all (yes, it is not a cause for mainline decisions :-) ).
While user ns is not yet ready, I don't clearly see what is the division of security policies among namespaces including user namespace. I had a view that all stuff related to processes (i.e. distinct processes in several ways) belongs to pid ns, all net stuff to net ns, etc. If we differentiate user ns and pid ns, only strictly things handling pids (like kill(2), procfs, ptrace(2), etc.) belong to pid ns and all other process-related stuff (like credentials handling, these symlink/hardling things, etc.) belong to user namespaces.

Quoted 3 lines

Can we probably leave them in pid ns for now and when user ns is matured just move it from pid ns to user ns? Is it possible without breaking Yama's ABI (I think so)?

So it sounds like you'll send a new patch where only ptrace_scope is tied to pidns?

-Kees

Signature · 2 lines

Kees Cook
ChromeOS Security

Vasiliy Kulikov

2011-11-28 18:14 UTC #27 lore raw

Re: [RFC] Make Yama pid_ns aware

Quoted 7 lines · Kees Cook

Quoted 3 lines · Vasiliy Kulikov
Can we probably leave them in pid ns for now and when user ns is matured just move it from pid ns to user ns? Is it possible without breaking Yama's ABI (I think so)?
So it sounds like you'll send a new patch where only ptrace_scope is tied to pidns?

Em, no. I've said we'll leave everything in pid ns for now. When user ns is ready, we'll move some options (all of them?) from pid ns to user ns. As user interface is kernel.yama.* sysctls and will not be changed with the migration, ABI would not be broken by this migration.

Thanks,

Signature · 2 lines

Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

Vasiliy Kulikov

2011-11-28 19:16 UTC #28 lore raw

RFC 1/1 Make Yama pid_ns aware

In reply to Kees Cook

The patch is straightforward:

1) all sysctl variables are moved from global vars to pid_namespace fields.

2) each cloned pid ns gets the settings of the parent.

3) the variables of current pid ns are visible through sysctl interface.

proc_pid_dointvec_minmax() is stolen from its ipc_ns equivalent in ipc/ipc_sysctl.c.

P.S. As user namespaces are not merged yet and it's not clear when/whether they are merged, these changes belong to pid namespace for now. When user namespaces are merged, per pid_ns variables should go to struct user_namespace. It will not break ABI as userspace sees the same kernel.yama.* sysctls in both pid ns and user ns cases.

Signed-off-by Vasiliy Kulikov <[email protected]>

include/linux/pid_namespace.h +5 -0

index 38d1032..46edaf8 100644
@@ -30,6 +30,11 @@ struct pid_namespace {
 #ifdef CONFIG_BSD_PROCESS_ACCT
 	struct bsd_acct_struct *bacct;
 #endif
+#ifdef CONFIG_SECURITY_YAMA
+	int ptrace_scope;
+	int protected_sticky_symlinks;
+	int protected_nonaccess_hardlinks;
+#endif
 };
 
 extern struct pid_namespace init_pid_ns;

kernel/pid.c +5 -0

index fa5f722..0cd8926 100644
@@ -78,6 +78,11 @@ struct pid_namespace init_pid_ns = {
 	.last_pid = 0,
 	.level = 0,
 	.child_reaper = &init_task,
+#ifdef CONFIG_SECURITY_YAMA
+	.ptrace_scope = 1,
+	.protected_sticky_symlinks = 1,
+	.protected_nonaccess_hardlinks = 1,
+#endif
 };
 EXPORT_SYMBOL_GPL(init_pid_ns);

kernel/pid_namespace.c +8 -0

index e9c9adc..73d47c4 100644
@@ -101,6 +101,14 @@ static struct pid_namespace *create_pid_namespace(struct pid_namespace *parent_p
 	if (err)
 		goto out_put_parent_pid_ns;
 
+#ifdef CONFIG_SECURITY_YAMA
+	ns->ptrace_scope = parent_pid_ns->ptrace_scope;
+	ns->protected_sticky_symlinks =
+		parent_pid_ns->protected_sticky_symlinks;
+	ns->protected_nonaccess_hardlinks =
+		parent_pid_ns->protected_nonaccess_hardlinks;
+#endif
+
 	return ns;
 
 out_put_parent_pid_ns:

security/yama/yama_lsm.c +30 ~~-13~~

95 lines not on this page · raw message

---

Kees Cook

author Acked-by on v1 1/1

2011-11-28 19:35 UTC #29 lore raw

Re: [RFC -resend] Make Yama pid_ns aware

Quoted 7 lines · Vasiliy Kulikov

As Yama's sysctls are about defining a security policy for the system, it is reasonable to define it per container in case of LXC containers (or out-of-tree alternatives like OpenVZ). In my opinion they belong to pid namespace. With per-pid_ns sysctls it is possible to create multiple containers with different ptrace, /tmp, etc. policies.
[...]
Signed-off-by Vasiliy Kulikov <[email protected]>

Thanks! I'll include this in the next Yama patch set.

Acked-by Kees Cook <[email protected]>

-Kees

Signature · 2 lines

Kees Cook
ChromeOS Security

Kees Cook

author

2011-11-28 20:15 UTC #30 lore raw

Re: [RFC -resend] Make Yama pid_ns aware

Quoted 9 lines · Kees Cook

Quoted 7 lines · Vasiliy Kulikov
As Yama's sysctls are about defining a security policy for the system, it is reasonable to define it per container in case of LXC containers (or out-of-tree alternatives like OpenVZ). In my opinion they belong to pid namespace. With per-pid_ns sysctls it is possible to create multiple containers with different ptrace, /tmp, etc. policies.
[...]
Signed-off-by Vasiliy Kulikov <[email protected]>

Quoted 3 lines

Thanks! I'll include this in the next Yama patch set.
Acked-by Kees Cook <[email protected]>

I should mention, this lives here now:
http://git.kernel.org/?p=linux/kernel/git/kees/linux.git;a=shortlog;h=refs/heads/yama

-Kees

Signature · 2 lines

Kees Cook
ChromeOS Security

Serge E. Hallyn

maintainer Acked-by Serge Hallyn on v1 1/1

2011-11-28 20:00 UTC #31 lore raw

Re: [RFC -resend] Make Yama pid_ns aware

In reply to Vasiliy Kulikov

Quoted 18 lines · Vasiliy Kulikov

As Yama's sysctls are about defining a security policy for the system, it is reasonable to define it per container in case of LXC containers (or out-of-tree alternatives like OpenVZ). In my opinion they belong to pid namespace. With per-pid_ns sysctls it is possible to create multiple containers with different ptrace, /tmp, etc. policies.
The patch is straightforward:
1) all sysctl variables are moved from global vars to pid_namespace fields.
2) each cloned pid ns gets the settings of the parent.
3) the variables of current pid ns are visible through sysctl interface.
proc_pid_dointvec_minmax() is stolen from its ipc_ns equivalent in ipc/ipc_sysctl.c.

Quoted 7 lines

P.S. As user namespaces are not merged yet and it's not clear when/whether they are merged, these changes belong to pid namespace for now. When user namespaces are merged, per pid_ns variables should go to struct user_namespace. It will not break ABI as userspace sees the same kernel.yama.* sysctls in both pid ns and user ns cases.
Signed-off-by Vasiliy Kulikov <[email protected]>

Acked-by Serge Hallyn <[email protected]>

thanks,
-serge

Quoted 159 lines

include/linux/pid_namespace.h +5 -0

index 38d1032..46edaf8 100644
@@ -30,6 +30,11 @@ struct pid_namespace {
 #ifdef CONFIG_BSD_PROCESS_ACCT
 	struct bsd_acct_struct *bacct;
 #endif
+#ifdef CONFIG_SECURITY_YAMA
+	int ptrace_scope;
+	int protected_sticky_symlinks;
+	int protected_nonaccess_hardlinks;
+#endif
 };
 
 extern struct pid_namespace init_pid_ns;

kernel/pid.c +5 -0

index fa5f722..0cd8926 100644
@@ -78,6 +78,11 @@ struct pid_namespace init_pid_ns = {
 	.last_pid = 0,
 	.level = 0,
 	.child_reaper = &init_task,
+#ifdef CONFIG_SECURITY_YAMA
+	.ptrace_scope = 1,
+	.protected_sticky_symlinks = 1,
+	.protected_nonaccess_hardlinks = 1,
+#endif
 };
 EXPORT_SYMBOL_GPL(init_pid_ns);

kernel/pid_namespace.c +8 -0

index e9c9adc..73d47c4 100644
@@ -101,6 +101,14 @@ static struct pid_namespace *create_pid_namespace(struct pid_namespace *parent_p
 	if (err)
 		goto out_put_parent_pid_ns;
 
+#ifdef CONFIG_SECURITY_YAMA
+	ns->ptrace_scope = parent_pid_ns->ptrace_scope;
+	ns->protected_sticky_symlinks =
+		parent_pid_ns->protected_sticky_symlinks;
+	ns->protected_nonaccess_hardlinks =
+		parent_pid_ns->protected_nonaccess_hardlinks;
+#endif
+
 	return ns;
 
 out_put_parent_pid_ns:

security/yama/yama_lsm.c +30 ~~-14~~

index a92538c..cf99a8c 100644
@@ -16,10 +16,7 @@
 #include <linux/ptrace.h>
 #include <linux/prctl.h>
 #include <linux/ratelimit.h>
-
-static int ptrace_scope = 1;
-static int protected_sticky_symlinks = 1;
-static int protected_nonaccess_hardlinks = 1;
+#include <linux/pid_namespace.h>
 
 /* describe a PTRACE relationship for potential exception */
 struct ptrace_relation {

@@ -250,7 +247,7 @@ static int yama_ptrace_access_check(struct task_struct *child,
 
 	/* require ptrace target be a child of ptracer on attach */
 	if (mode == PTRACE_MODE_ATTACH &&
-	    ptrace_scope &&
+	    current->nsproxy->pid_ns->ptrace_scope &&
 	    !capable(CAP_SYS_PTRACE) &&
 	    !task_is_descendant(current, child) &&
 	    !ptracer_exception_found(current, child))

@@ -292,7 +289,7 @@ static int yama_inode_follow_link(struct dentry *dentry,
 	const struct inode *inode;
 	const struct cred *cred;
 
-	if (!protected_sticky_symlinks)
+	if (!current->nsproxy->pid_ns->protected_sticky_symlinks)
 		return 0;
 
 	/* if inode isn't a symlink, don't try to evaluate blocking it */

@@ -362,7 +359,7 @@ static int yama_path_link(struct dentry *old_dentry, struct path *new_dir,
 	const int mode = inode->i_mode;
 	const struct cred *cred = current_cred();
 
-	if (!protected_nonaccess_hardlinks)
+	if (!current->nsproxy->pid_ns->protected_nonaccess_hardlinks)
 		return 0;
 
 	if (cred->fsuid != inode->i_uid &&

@@ -395,6 +392,26 @@ static struct security_operations yama_ops = {
 static int zero;
 static int one = 1;
 
+static void *get_pid_data(ctl_table *table)
+{
+	char *which = table->data;
+	struct pid_namespace *pid_ns = current->nsproxy->pid_ns;
+	which = (which - (char *)&init_pid_ns) + (char *)pid_ns;
+	return which;
+}
+
+static int proc_pid_dointvec_minmax(ctl_table *table, int write,
+	void __user *buffer, size_t *lenp, loff_t *ppos)
+{
+	struct ctl_table pid_table;
+
+	memcpy(&pid_table, table, sizeof(pid_table));
+	pid_table.data = get_pid_data(table);
+
+	return proc_dointvec_minmax(&pid_table, write, buffer, lenp, ppos);
+}
+
+
 struct ctl_path yama_sysctl_path[] = {
 	{ .procname = "kernel", },
 	{ .procname = "yama", },

@@ -404,28 +421,28 @@ struct ctl_path yama_sysctl_path[] = {
 static struct ctl_table yama_sysctl_table[] = {
 	{
 		.procname       = "protected_sticky_symlinks",
-		.data           = &protected_sticky_symlinks,
+		.data           = &init_pid_ns.protected_sticky_symlinks,
 		.maxlen         = sizeof(int),
 		.mode           = 0644,
-		.proc_handler   = proc_dointvec_minmax,
+		.proc_handler   = proc_pid_dointvec_minmax,
 		.extra1         = &zero,
 		.extra2         = &one,
 	},
 	{
 		.procname       = "protected_nonaccess_hardlinks",
-		.data           = &protected_nonaccess_hardlinks,
+		.data           = &init_pid_ns.protected_nonaccess_hardlinks,
 		.maxlen         = sizeof(int),
 		.mode           = 0644,
-		.proc_handler   = proc_dointvec_minmax,
+		.proc_handler   = proc_pid_dointvec_minmax,
 		.extra1         = &zero,
 		.extra2         = &one,
 	},
 	{
 		.procname       = "ptrace_scope",
-		.data           = &ptrace_scope,
+		.data           = &init_pid_ns.ptrace_scope,
 		.maxlen         = sizeof(int),
 		.mode           = 0644,
-		.proc_handler   = proc_dointvec_minmax,
+		.proc_handler   = proc_pid_dointvec_minmax,
 		.extra1         = &zero,
 		.extra2         = &one,
 	},
---