public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [RFC][PATCH] Add LSM sysctl hook to 2.5.59
@ 2003-01-17 21:54 Stephen D. Smalley
  2003-01-20  0:08 ` Christoph Hellwig
  0 siblings, 1 reply; 6+ messages in thread
From: Stephen D. Smalley @ 2003-01-17 21:54 UTC (permalink / raw)
  To: linux-kernel; +Cc: linux-security-module, sds


This patch adds a LSM sysctl hook for controlling access to
sysctl variables to 2.5.59, split out from the lsm-2.5 BitKeeper tree.
SELinux uses this hook to control such accesses in accordance with the
security policy configuration.

If anyone has any objections to this change, please let me know.

 include/linux/security.h |   17 +++++++++++++++++
 kernel/sysctl.c          |    5 +++++
 security/dummy.c         |    6 ++++++
 3 files changed, 28 insertions(+)
-----

===== include/linux/security.h 1.9 vs edited =====
--- 1.9/include/linux/security.h	Wed Dec 18 09:10:50 2002
+++ edited/include/linux/security.h	Fri Jan 17 14:49:12 2003
@@ -771,6 +771,12 @@
  *	is NULL.
  *	@file contains the file structure for the accounting file (may be NULL).
  *	Return 0 if permission is granted.
+ * @sysctl:
+ *	Check permission before accessing the @table sysctl variable in the
+ *	manner specified by @op.
+ *	@table contains the ctl_table structure for the sysctl variable.
+ *	@op contains the operation (001 = search, 002 = write, 004 = read).
+ *	Return 0 if permission is granted.
  * @capable:
  *	Check whether the @tsk process has the @cap capability.
  *	@tsk contains the task_struct for the process.
@@ -802,6 +808,7 @@
 			    kernel_cap_t * inheritable,
 			    kernel_cap_t * permitted);
 	int (*acct) (struct file * file);
+	int (*sysctl) (ctl_table * table, int op);
 	int (*capable) (struct task_struct * tsk, int cap);
 	int (*quotactl) (int cmds, int type, int id, struct super_block * sb);
 	int (*quota_on) (struct file * f);
@@ -992,6 +999,11 @@
 	return security_ops->acct (file);
 }
 
+static inline int security_sysctl(ctl_table * table, int op)
+{
+	return security_ops->sysctl(table, op);
+}
+
 static inline int security_quotactl (int cmds, int type, int id,
 				     struct super_block *sb)
 {
@@ -1593,6 +1605,11 @@
 }
 
 static inline int security_acct (struct file *file)
+{
+	return 0;
+}
+
+static inline int security_sysctl(ctl_table * table, int op)
 {
 	return 0;
 }
===== kernel/sysctl.c 1.37 vs edited =====
--- 1.37/kernel/sysctl.c	Thu Dec  5 11:06:54 2002
+++ edited/kernel/sysctl.c	Fri Jan 17 14:49:15 2003
@@ -33,6 +33,7 @@
 #include <linux/highuid.h>
 #include <linux/writeback.h>
 #include <linux/hugetlb.h>
+#include <linux/security.h>
 #include <asm/uaccess.h>
 
 #ifdef CONFIG_ROOT_NFS
@@ -432,6 +433,10 @@
 
 static inline int ctl_perm(ctl_table *table, int op)
 {
+	int error;
+	error = security_sysctl(table, op);
+	if (error)
+		return error;
 	return test_perm(table->mode, op);
 }
 
===== security/dummy.c 1.14 vs edited =====
--- 1.14/security/dummy.c	Wed Dec 18 09:11:56 2002
+++ edited/security/dummy.c	Fri Jan 17 14:49:15 2003
@@ -75,6 +75,11 @@
 	return -EPERM;
 }
 
+static int dummy_sysctl (ctl_table * table, int op)
+{
+	return 0;
+}
+
 static int dummy_quotactl (int cmds, int type, int id, struct super_block *sb)
 {
 	return 0;
@@ -628,6 +633,7 @@
 	set_to_dummy_if_null(ops, capable);
 	set_to_dummy_if_null(ops, quotactl);
 	set_to_dummy_if_null(ops, quota_on);
+	set_to_dummy_if_null(ops, sysctl);
 	set_to_dummy_if_null(ops, bprm_alloc_security);
 	set_to_dummy_if_null(ops, bprm_free_security);
 	set_to_dummy_if_null(ops, bprm_compute_creds);



--
Stephen Smalley, NSA
sds@epoch.ncsc.mil


^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [RFC][PATCH] Add LSM sysctl hook to 2.5.59
@ 2003-01-21 14:51 Stephen D. Smalley
  0 siblings, 0 replies; 6+ messages in thread
From: Stephen D. Smalley @ 2003-01-21 14:51 UTC (permalink / raw)
  To: hch; +Cc: linux-kernel, linux-security-module, sds


Christoph Hellwig writes:
> I'm not very happy with this hook.  This means every single security
> module needs a list of all sensitive sysctl variables, i.e. we duplicate
> information in (possible a large number of) different places.
> 
> What's the reason you can't just live with DAC for sysctls?

For the same reason that we can't just live with DAC for file
permissions, signal permissions, etc. DAC mechanisms are fundamentally
inadequate for strong security.  They do not take into account
security-relevant information such as the role of the user, the
function and trustworthiness of the program, and the sensitivity and
integrity of the data.  They do not permit enforcement of a consistent
system-wide security policy.  They do not provide any protection
against malicious software.  These issues are discussed in the paper
available from http://www.nsa.gov/selinux/freenix01-abs.html.

Exempting sysctl variables from control by the mandatory security
policy leaves a rather significant vulnerability in your base system
security.  Do you truly want every process that runs with the root euid
to have access to your sysctl variables?  Even the Linux capabilities
would be too coarse-grained to be useful, but I don't think they are
relevant here, as neither ctl_perm nor proc_sys_permission check
capabilities (they both call test_perm, which is hardcoded to evaluate
the sysctl variable mode with a fixed notion of a root owner and group
attribute).

The sysctl hook does not mandate that a security module writer maintain
a list of sensitive sysctls.  Some security modules may simply choose
to implement a process-based restriction (e.g. only processes in the
FOO domain can modify sysctl variables).  But the hook does allow a
security module writer to optionally provide finer-grained control
based on the individual sysctl, e.g. to protect the modprobe variable
more carefully.  SELinux uses this finer-grained support.  The sysctl
variables can be mapped into equivalence classes based on the hierarchy
in the security policy configuration, so you don't have to maintain a
list of every individual sysctl variable.

It might be helpful to security module writers if the kernel gave a
hint as to its view of the "sensitivity" of a given sysctl variable,
but the actual protection of the sysctl variables is likely to vary
somewhat depending on the particular security policy/module.

--
Stephen Smalley, NSA
sds@epoch.ncsc.mil


^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-01-21 14:35 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-01-17 21:54 [RFC][PATCH] Add LSM sysctl hook to 2.5.59 Stephen D. Smalley
2003-01-20  0:08 ` Christoph Hellwig
2003-01-20  0:39   ` Russell Coker
2003-01-20  0:43     ` Christoph Hellwig
2003-01-20  1:05       ` Russell Coker
  -- strict thread matches above, loose matches on Subject: below --
2003-01-21 14:51 Stephen D. Smalley

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox