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
[email protected]
On Fri, Jan 17, 2003 at 04:54:37PM -0500, Stephen D. Smalley wrote:
>
> 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.
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?
On Mon, 20 Jan 2003 01:08, Christoph Hellwig wrote:
> On Fri, Jan 17, 2003 at 04:54:37PM -0500, Stephen D. Smalley wrote:
> > 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.
>
> 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?
What exactly do you mean by "live with DAC" in this context? If you mean
"allow UID==0 processes to do whatever they like" then it's not going to work
for any sort of chroot setup.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
On Mon, Jan 20, 2003 at 01:39:39AM +0100, Russell Coker wrote:
> > What's the reason you can't just live with DAC for sysctls?
>
> What exactly do you mean by "live with DAC" in this context? If you mean
> "allow UID==0 processes to do whatever they like" then it's not going to work
> for any sort of chroot setup.
This means check the unix file permissions / ACLs only overriden by
CAP_FOWNER processes.
On Mon, 20 Jan 2003 01:43, Christoph Hellwig wrote:
> On Mon, Jan 20, 2003 at 01:39:39AM +0100, Russell Coker wrote:
> > > What's the reason you can't just live with DAC for sysctls?
> >
> > What exactly do you mean by "live with DAC" in this context? If you mean
> > "allow UID==0 processes to do whatever they like" then it's not going to
> > work for any sort of chroot setup.
>
> This means check the unix file permissions / ACLs only overriden by
> CAP_FOWNER processes.
I don't think that would do for my chroot environments. I want to have root
owned processes running in a chroot with no ability to escape or to affect
the outside environment (and proc is mounted in the chroot).
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
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
[email protected]