Hi,
These changesets include some new LSM hooks, all of which have been sent
to lkml with no dissenting comments. Some of these hooks are the same
ones I sent for 2.5.58, but were not picked up. These include hooks for
syslog and sysctl, restores some previously lost hooks, and reworked the
hooks for the security structures for private files.
Please pull from: bk://lsm.bkbits.net/linus-2.5
thanks,
greg k-h
fs/dcache.c | 6 +++
fs/exportfs/expfs.c | 5 +--
fs/file_table.c | 35 +++++++++++++++++------
fs/namei.c | 18 +++--------
fs/nfsd/vfs.c | 9 +----
fs/super.c | 16 ++++++++++
include/linux/fs.h | 10 +++++-
include/linux/security.h | 71 +++++++++++++++++++++++++++++++++++++----------
kernel/ksyms.c | 6 ++-
kernel/printk.c | 7 +++-
kernel/sys.c | 21 ++++++++++---
kernel/sysctl.c | 5 +++
security/capability.c | 10 ++++++
security/dummy.c | 33 +++++++++++++++++----
14 files changed, 191 insertions(+), 61 deletions(-)
-----
[email protected], 2003-02-05 14:37:12+11:00, [email protected]
[PATCH] LSM: Add LSM syslog hook to 2.5.59
This patch adds the LSM security_syslog hook for controlling the
syslog(2) interface relative to 2.5.59 plus the previously posted
security_sysctl patch. In response to earlier comments by Christoph,
the existing capability check for syslog(2) is moved into the
capability security module hook function, and a corresponding dummy
security module hook function is defined that provides traditional
superuser behavior. The LSM hook is placed in do_syslog rather than
sys_syslog so that it is called when either the system call interface
or the /proc/kmsg interface is used. SELinux uses this hook to
control access to the kernel message ring and to the console log
level.
include/linux/security.h | 18 ++++++++++++++++++
kernel/printk.c | 7 +++++--
security/capability.c | 10 ++++++++++
security/dummy.c | 8 ++++++++
4 files changed, 41 insertions(+), 2 deletions(-)
------
[email protected], 2003-02-05 14:32:08+11:00, [email protected]
[PATCH] LSM: Add LSM sysctl hook to 2.5.59
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.
include/linux/security.h | 17 +++++++++++++++++
kernel/sysctl.c | 5 +++++
security/dummy.c | 6 ++++++
3 files changed, 28 insertions(+)
------
[email protected], 2003-02-04 15:07:23-08:00, [email protected]
Merge bk://lsm.bkbits.net/linus-2.5
into kernel.bkbits.net:/home/gregkh/linux/lsm-2.5
fs/dcache.c | 3 +++
fs/namei.c | 9 +++------
fs/super.c | 8 ++++++++
include/linux/fs.h | 5 ++++-
kernel/ksyms.c | 3 ++-
5 files changed, 20 insertions(+), 8 deletions(-)
------
[email protected], 2003-01-16 14:54:42-08:00, [email protected]
[PATCH] Restore LSM hook calls to setpriority and setpgid
This patch restores the LSM hook calls in setpriority and setpgid to
2.5.58. These hooks were previously added as of 2.5.27, but the hook
calls were subsequently lost as a result of other changes to the code
as of 2.5.37.
Ingo has signed off on this patch, and no one else has objected.
kernel/sys.c | 21 ++++++++++++++++-----
1 files changed, 16 insertions(+), 5 deletions(-)
------
[email protected], 2003-01-16 14:35:24-08:00, [email protected]
[PATCH] allocate and free security structures for private files
This patch adds a security_file_alloc call to init_private_file and
creates a close_private_file function to encapsulate the release of
private file structures. These changes ensure that security
structures for private files will be allocated and freed
appropriately. Per Andi Kleen's comments, the patch also renames
init_private_file to open_private_file to force updating of all
callers, since they will also need to be updated to use
close_private_file to avoid a leak of the security structure. Per
Christoph Hellwig's comments, the patch also replaces the 'mode'
argument with a 'flags' argument, computing the f_mode from the flags,
and it explicitly tests f_op prior to dereferencing, as in
dentry_open().
fs/exportfs/expfs.c | 5 ++---
fs/file_table.c | 35 +++++++++++++++++++++++++++--------
fs/nfsd/vfs.c | 9 +++------
include/linux/fs.h | 5 ++++-
kernel/ksyms.c | 3 ++-
5 files changed, 38 insertions(+), 19 deletions(-)
------
[email protected], 2003-01-16 14:23:59-08:00, [email protected]
[PATCH] Replace inode_post_lookup hook with d_instantiate hook
This patch removes the security_inode_post_lookup hook entirely and
adds a security_d_instantiate hook call to the d_instantiate function
and the d_splice_alias function. The inode_post_lookup hook was
subject to races since the inode is already accessible through the
dcache before it is called, didn't handle filesystems that directly
populate the dcache, and wasn't always called in the desired context
(e.g. for pipe, shmem, and devpts inodes). The d_instantiate hook
enables initialization of the inode security information. This hook
is used by SELinux and by DTE to setup the inode security state, and
eliminated the need for the inode_precondition function in SELinux.
fs/dcache.c | 3 +++
fs/namei.c | 9 +++------
include/linux/security.h | 25 ++++++++++---------------
security/dummy.c | 13 +++++++------
4 files changed, 23 insertions(+), 27 deletions(-)
------
[email protected], 2003-01-16 14:18:05-08:00, [email protected]
[PATCH] Add LSM hook to do_kern_mount
This patch adds a security_sb_kern_mount hook call to the do_kern_mount
function. This hook enables initialization of the superblock security
information of all superblock objects. Placing a hook in do_kern_mount
was originally suggested by Al Viro. This hook is used by SELinux to
setup the superblock security state and eliminated the need for the
superblock_precondition function.
fs/super.c | 8 ++++++++
include/linux/security.h | 11 +++++++++++
security/dummy.c | 6 ++++++
3 files changed, 25 insertions(+)
------
ChangeSet 1.952.1.1, 2003/01/16 14:18:05-08:00, [email protected]
[PATCH] Add LSM hook to do_kern_mount
This patch adds a security_sb_kern_mount hook call to the do_kern_mount
function. This hook enables initialization of the superblock security
information of all superblock objects. Placing a hook in do_kern_mount
was originally suggested by Al Viro. This hook is used by SELinux to
setup the superblock security state and eliminated the need for the
superblock_precondition function.
diff -Nru a/fs/super.c b/fs/super.c
--- a/fs/super.c Wed Feb 5 14:58:37 2003
+++ b/fs/super.c Wed Feb 5 14:58:37 2003
@@ -610,6 +610,7 @@
struct file_system_type *type = get_fs_type(fstype);
struct super_block *sb = ERR_PTR(-ENOMEM);
struct vfsmount *mnt;
+ int error;
if (!type)
return ERR_PTR(-ENODEV);
@@ -620,6 +621,13 @@
sb = type->get_sb(type, flags, name, data);
if (IS_ERR(sb))
goto out_mnt;
+ error = security_sb_kern_mount(sb);
+ if (error) {
+ up_write(&sb->s_umount);
+ deactivate_super(sb);
+ sb = ERR_PTR(error);
+ goto out_mnt;
+ }
mnt->mnt_sb = sb;
mnt->mnt_root = dget(sb->s_root);
mnt->mnt_mountpoint = sb->s_root;
diff -Nru a/include/linux/security.h b/include/linux/security.h
--- a/include/linux/security.h Wed Feb 5 14:58:37 2003
+++ b/include/linux/security.h Wed Feb 5 14:58:37 2003
@@ -814,6 +814,7 @@
int (*sb_alloc_security) (struct super_block * sb);
void (*sb_free_security) (struct super_block * sb);
+ int (*sb_kern_mount) (struct super_block *sb);
int (*sb_statfs) (struct super_block * sb);
int (*sb_mount) (char *dev_name, struct nameidata * nd,
char *type, unsigned long flags, void *data);
@@ -1034,6 +1035,11 @@
security_ops->sb_free_security (sb);
}
+static inline int security_sb_kern_mount (struct super_block *sb)
+{
+ return security_ops->sb_kern_mount (sb);
+}
+
static inline int security_sb_statfs (struct super_block *sb)
{
return security_ops->sb_statfs (sb);
@@ -1638,6 +1644,11 @@
static inline void security_sb_free (struct super_block *sb)
{ }
+
+static inline int security_sb_kern_mount (struct super_block *sb)
+{
+ return 0;
+}
static inline int security_sb_statfs (struct super_block *sb)
{
diff -Nru a/security/dummy.c b/security/dummy.c
--- a/security/dummy.c Wed Feb 5 14:58:37 2003
+++ b/security/dummy.c Wed Feb 5 14:58:37 2003
@@ -120,6 +120,11 @@
return;
}
+static int dummy_sb_kern_mount (struct super_block *sb)
+{
+ return 0;
+}
+
static int dummy_sb_statfs (struct super_block *sb)
{
return 0;
@@ -635,6 +640,7 @@
set_to_dummy_if_null(ops, bprm_check_security);
set_to_dummy_if_null(ops, sb_alloc_security);
set_to_dummy_if_null(ops, sb_free_security);
+ set_to_dummy_if_null(ops, sb_kern_mount);
set_to_dummy_if_null(ops, sb_statfs);
set_to_dummy_if_null(ops, sb_mount);
set_to_dummy_if_null(ops, sb_check_sb);
ChangeSet 1.952.1.4, 2003/01/16 14:54:42-08:00, [email protected]
[PATCH] Restore LSM hook calls to setpriority and setpgid
This patch restores the LSM hook calls in setpriority and setpgid to
2.5.58. These hooks were previously added as of 2.5.27, but the hook
calls were subsequently lost as a result of other changes to the code
as of 2.5.37.
Ingo has signed off on this patch, and no one else has objected.
diff -Nru a/kernel/sys.c b/kernel/sys.c
--- a/kernel/sys.c Wed Feb 5 14:58:27 2003
+++ b/kernel/sys.c Wed Feb 5 14:58:27 2003
@@ -212,18 +212,25 @@
static int set_one_prio(struct task_struct *p, int niceval, int error)
{
+ int no_nice;
+
if (p->uid != current->euid &&
p->uid != current->uid && !capable(CAP_SYS_NICE)) {
error = -EPERM;
goto out;
}
-
+ if (niceval < task_nice(p) && !capable(CAP_SYS_NICE)) {
+ error = -EACCES;
+ goto out;
+ }
+ no_nice = security_task_setnice(p, niceval);
+ if (no_nice) {
+ error = no_nice;
+ goto out;
+ }
if (error == -ESRCH)
error = 0;
- if (niceval < task_nice(p) && !capable(CAP_SYS_NICE))
- error = -EACCES;
- else
- set_user_nice(p, niceval);
+ set_user_nice(p, niceval);
out:
return error;
}
@@ -944,6 +951,10 @@
}
ok_pgid:
+ err = security_task_setpgid(p, pgid);
+ if (err)
+ goto out;
+
if (p->pgrp != pgid) {
detach_pid(p, PIDTYPE_PGID);
p->pgrp = pgid;
ChangeSet 1.952.1.3, 2003/01/16 14:35:24-08:00, [email protected]
[PATCH] allocate and free security structures for private files
This patch adds a security_file_alloc call to init_private_file and
creates a close_private_file function to encapsulate the release of
private file structures. These changes ensure that security
structures for private files will be allocated and freed
appropriately. Per Andi Kleen's comments, the patch also renames
init_private_file to open_private_file to force updating of all
callers, since they will also need to be updated to use
close_private_file to avoid a leak of the security structure. Per
Christoph Hellwig's comments, the patch also replaces the 'mode'
argument with a 'flags' argument, computing the f_mode from the flags,
and it explicitly tests f_op prior to dereferencing, as in
dentry_open().
diff -Nru a/fs/exportfs/expfs.c b/fs/exportfs/expfs.c
--- a/fs/exportfs/expfs.c Wed Feb 5 14:58:30 2003
+++ b/fs/exportfs/expfs.c Wed Feb 5 14:58:30 2003
@@ -353,7 +353,7 @@
/*
* Open the directory ...
*/
- error = init_private_file(&file, dentry, FMODE_READ);
+ error = open_private_file(&file, dentry, O_RDONLY);
if (error)
goto out;
error = -EINVAL;
@@ -381,8 +381,7 @@
}
out_close:
- if (file.f_op->release)
- file.f_op->release(dir, &file);
+ close_private_file(&file);
out:
return error;
}
diff -Nru a/fs/file_table.c b/fs/file_table.c
--- a/fs/file_table.c Wed Feb 5 14:58:30 2003
+++ b/fs/file_table.c Wed Feb 5 14:58:30 2003
@@ -93,23 +93,42 @@
/*
* Clear and initialize a (private) struct file for the given dentry,
- * and call the open function (if any). The caller must verify that
- * inode->i_fop is not NULL.
+ * allocate the security structure, and call the open function (if any).
+ * The file should be released using close_private_file.
*/
-int init_private_file(struct file *filp, struct dentry *dentry, int mode)
+int open_private_file(struct file *filp, struct dentry *dentry, int flags)
{
+ int error;
memset(filp, 0, sizeof(*filp));
eventpoll_init_file(filp);
- filp->f_mode = mode;
+ filp->f_flags = flags;
+ filp->f_mode = (flags+1) & O_ACCMODE;
atomic_set(&filp->f_count, 1);
filp->f_dentry = dentry;
filp->f_uid = current->fsuid;
filp->f_gid = current->fsgid;
filp->f_op = dentry->d_inode->i_fop;
- if (filp->f_op->open)
- return filp->f_op->open(dentry->d_inode, filp);
- else
- return 0;
+ error = security_file_alloc(filp);
+ if (!error)
+ if (filp->f_op && filp->f_op->open) {
+ error = filp->f_op->open(dentry->d_inode, filp);
+ if (error)
+ security_file_free(filp);
+ }
+ return error;
+}
+
+/*
+ * Release a private file by calling the release function (if any) and
+ * freeing the security structure.
+ */
+void close_private_file(struct file *file)
+{
+ struct inode * inode = file->f_dentry->d_inode;
+
+ if (file->f_op && file->f_op->release)
+ file->f_op->release(inode, file);
+ security_file_free(file);
}
void fput(struct file * file)
diff -Nru a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
--- a/fs/nfsd/vfs.c Wed Feb 5 14:58:30 2003
+++ b/fs/nfsd/vfs.c Wed Feb 5 14:58:30 2003
@@ -426,7 +426,7 @@
{
struct dentry *dentry;
struct inode *inode;
- int flags = O_RDONLY|O_LARGEFILE, mode = FMODE_READ, err;
+ int flags = O_RDONLY|O_LARGEFILE, err;
/*
* If we get here, then the client has already done an "open",
@@ -463,14 +463,12 @@
goto out_nfserr;
flags = O_WRONLY|O_LARGEFILE;
- mode = FMODE_WRITE;
DQUOT_INIT(inode);
}
- err = init_private_file(filp, dentry, mode);
+ err = open_private_file(filp, dentry, flags);
if (!err) {
- filp->f_flags = flags;
filp->f_vfsmnt = fhp->fh_export->ex_mnt;
} else if (access & MAY_WRITE)
put_write_access(inode);
@@ -491,8 +489,7 @@
struct dentry *dentry = filp->f_dentry;
struct inode *inode = dentry->d_inode;
- if (filp->f_op->release)
- filp->f_op->release(inode, filp);
+ close_private_file(filp);
if (filp->f_mode & FMODE_WRITE)
put_write_access(inode);
}
diff -Nru a/include/linux/fs.h b/include/linux/fs.h
--- a/include/linux/fs.h Wed Feb 5 14:58:30 2003
+++ b/include/linux/fs.h Wed Feb 5 14:58:30 2003
@@ -489,7 +489,10 @@
#define get_file(x) atomic_inc(&(x)->f_count)
#define file_count(x) atomic_read(&(x)->f_count)
-extern int init_private_file(struct file *, struct dentry *, int);
+/* Initialize and open a private file and allocate its security structure. */
+extern int open_private_file(struct file *, struct dentry *, int);
+/* Release a private file and free its security structure. */
+extern void close_private_file(struct file *file);
#define MAX_NON_LFS ((1UL<<31) - 1)
diff -Nru a/kernel/ksyms.c b/kernel/ksyms.c
--- a/kernel/ksyms.c Wed Feb 5 14:58:30 2003
+++ b/kernel/ksyms.c Wed Feb 5 14:58:30 2003
@@ -179,7 +179,8 @@
EXPORT_SYMBOL(end_buffer_io_sync);
EXPORT_SYMBOL(__mark_inode_dirty);
EXPORT_SYMBOL(get_empty_filp);
-EXPORT_SYMBOL(init_private_file);
+EXPORT_SYMBOL(open_private_file);
+EXPORT_SYMBOL(close_private_file);
EXPORT_SYMBOL(filp_open);
EXPORT_SYMBOL(filp_close);
EXPORT_SYMBOL(put_filp);
ChangeSet 1.952.1.2, 2003/01/16 14:23:59-08:00, [email protected]
[PATCH] Replace inode_post_lookup hook with d_instantiate hook
This patch removes the security_inode_post_lookup hook entirely and
adds a security_d_instantiate hook call to the d_instantiate function
and the d_splice_alias function. The inode_post_lookup hook was
subject to races since the inode is already accessible through the
dcache before it is called, didn't handle filesystems that directly
populate the dcache, and wasn't always called in the desired context
(e.g. for pipe, shmem, and devpts inodes). The d_instantiate hook
enables initialization of the inode security information. This hook
is used by SELinux and by DTE to setup the inode security state, and
eliminated the need for the inode_precondition function in SELinux.
diff -Nru a/fs/dcache.c b/fs/dcache.c
--- a/fs/dcache.c Wed Feb 5 14:58:34 2003
+++ b/fs/dcache.c Wed Feb 5 14:58:34 2003
@@ -25,6 +25,7 @@
#include <linux/module.h>
#include <linux/mount.h>
#include <asm/uaccess.h>
+#include <linux/security.h>
#define DCACHE_PARANOIA 1
/* #define DCACHE_DEBUG 1 */
@@ -699,6 +700,7 @@
void d_instantiate(struct dentry *entry, struct inode * inode)
{
if (!list_empty(&entry->d_alias)) BUG();
+ security_d_instantiate(entry, inode);
spin_lock(&dcache_lock);
if (inode)
list_add(&entry->d_alias, &inode->i_dentry);
@@ -825,6 +827,7 @@
struct dentry *new = NULL;
if (inode && S_ISDIR(inode->i_mode)) {
+ security_d_instantiate(dentry, inode);
spin_lock(&dcache_lock);
if (!list_empty(&inode->i_dentry)) {
new = list_entry(inode->i_dentry.next, struct dentry, d_alias);
diff -Nru a/fs/namei.c b/fs/namei.c
--- a/fs/namei.c Wed Feb 5 14:58:34 2003
+++ b/fs/namei.c Wed Feb 5 14:58:34 2003
@@ -372,10 +372,8 @@
result = dir->i_op->lookup(dir, dentry);
if (result)
dput(dentry);
- else {
+ else
result = dentry;
- security_inode_post_lookup(dir, result);
- }
}
up(&dir->i_sem);
return result;
@@ -916,10 +914,9 @@
if (!new)
goto out;
dentry = inode->i_op->lookup(inode, new);
- if (!dentry) {
+ if (!dentry)
dentry = new;
- security_inode_post_lookup(inode, dentry);
- } else
+ else
dput(new);
}
out:
diff -Nru a/include/linux/security.h b/include/linux/security.h
--- a/include/linux/security.h Wed Feb 5 14:58:34 2003
+++ b/include/linux/security.h Wed Feb 5 14:58:34 2003
@@ -339,10 +339,6 @@
* @mnt is the vfsmount where the dentry was looked up
* @dentry contains the dentry structure for the file.
* Return 0 if permission is granted.
- * @inode_post_lookup:
- * Set the security attributes for a file after it has been looked up.
- * @inode contains the inode structure for parent directory.
- * @d contains the dentry structure for the file.
* @inode_delete:
* @inode contains the inode structure for deleted inode.
* This hook is called when a deleted inode is released (i.e. an inode
@@ -868,7 +864,6 @@
int (*inode_permission_lite) (struct inode *inode, int mask);
int (*inode_setattr) (struct dentry *dentry, struct iattr *attr);
int (*inode_getattr) (struct vfsmount *mnt, struct dentry *dentry);
- void (*inode_post_lookup) (struct inode *inode, struct dentry *d);
void (*inode_delete) (struct inode *inode);
int (*inode_setxattr) (struct dentry *dentry, char *name, void *value,
size_t size, int flags);
@@ -953,6 +948,8 @@
struct security_operations *ops);
int (*unregister_security) (const char *name,
struct security_operations *ops);
+
+ void (*d_instantiate) (struct dentry * dentry, struct inode * inode);
};
/* global variables */
@@ -1246,12 +1243,6 @@
return security_ops->inode_getattr (mnt, dentry);
}
-static inline void security_inode_post_lookup (struct inode *inode,
- struct dentry *dentry)
-{
- security_ops->inode_post_lookup (inode, dentry);
-}
-
static inline void security_inode_delete (struct inode *inode)
{
security_ops->inode_delete (inode);
@@ -1549,6 +1540,11 @@
return security_ops->sem_semop(sma, sops, nsops, alter);
}
+static inline void security_d_instantiate (struct dentry *dentry, struct inode *inode)
+{
+ security_ops->d_instantiate (dentry, inode);
+}
+
/* prototypes */
extern int security_scaffolding_startup (void);
extern int register_security (struct security_operations *ops);
@@ -1828,10 +1824,6 @@
return 0;
}
-static inline void security_inode_post_lookup (struct inode *inode,
- struct dentry *dentry)
-{ }
-
static inline void security_inode_delete (struct inode *inode)
{ }
@@ -2114,6 +2106,9 @@
{
return 0;
}
+
+static inline void security_d_instantiate (struct dentry *dentry, struct inode *inode)
+{ }
#endif /* CONFIG_SECURITY */
diff -Nru a/security/dummy.c b/security/dummy.c
--- a/security/dummy.c Wed Feb 5 14:58:34 2003
+++ b/security/dummy.c Wed Feb 5 14:58:34 2003
@@ -311,11 +311,6 @@
return 0;
}
-static void dummy_inode_post_lookup (struct inode *ino, struct dentry *d)
-{
- return;
-}
-
static void dummy_inode_delete (struct inode *ino)
{
return;
@@ -612,6 +607,12 @@
return -EINVAL;
}
+static void dummy_d_instantiate (struct dentry *dentry, struct inode *inode)
+{
+ return;
+}
+
+
struct security_operations dummy_security_ops;
#define set_to_dummy_if_null(ops, function) \
@@ -674,7 +675,6 @@
set_to_dummy_if_null(ops, inode_permission_lite);
set_to_dummy_if_null(ops, inode_setattr);
set_to_dummy_if_null(ops, inode_getattr);
- set_to_dummy_if_null(ops, inode_post_lookup);
set_to_dummy_if_null(ops, inode_delete);
set_to_dummy_if_null(ops, inode_setxattr);
set_to_dummy_if_null(ops, inode_getxattr);
@@ -731,5 +731,6 @@
set_to_dummy_if_null(ops, sem_semop);
set_to_dummy_if_null(ops, register_security);
set_to_dummy_if_null(ops, unregister_security);
+ set_to_dummy_if_null(ops, d_instantiate);
}
ChangeSet 1.983, 2003/02/05 14:32:08+11:00, [email protected]
[PATCH] LSM: Add LSM sysctl hook to 2.5.59
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.
diff -Nru a/include/linux/security.h b/include/linux/security.h
--- a/include/linux/security.h Wed Feb 5 14:58:19 2003
+++ b/include/linux/security.h Wed Feb 5 14:58:19 2003
@@ -767,6 +767,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.
@@ -798,6 +804,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);
@@ -990,6 +997,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)
{
@@ -1595,6 +1607,11 @@
}
static inline int security_acct (struct file *file)
+{
+ return 0;
+}
+
+static inline int security_sysctl(ctl_table * table, int op)
{
return 0;
}
diff -Nru a/kernel/sysctl.c b/kernel/sysctl.c
--- a/kernel/sysctl.c Wed Feb 5 14:58:19 2003
+++ b/kernel/sysctl.c Wed Feb 5 14:58:19 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);
}
diff -Nru a/security/dummy.c b/security/dummy.c
--- a/security/dummy.c Wed Feb 5 14:58:19 2003
+++ b/security/dummy.c Wed Feb 5 14:58:19 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;
@@ -634,6 +639,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);
ChangeSet 1.984, 2003/02/05 14:37:12+11:00, [email protected]
[PATCH] LSM: Add LSM syslog hook to 2.5.59
This patch adds the LSM security_syslog hook for controlling the
syslog(2) interface relative to 2.5.59 plus the previously posted
security_sysctl patch. In response to earlier comments by Christoph,
the existing capability check for syslog(2) is moved into the
capability security module hook function, and a corresponding dummy
security module hook function is defined that provides traditional
superuser behavior. The LSM hook is placed in do_syslog rather than
sys_syslog so that it is called when either the system call interface
or the /proc/kmsg interface is used. SELinux uses this hook to
control access to the kernel message ring and to the console log
level.
diff -Nru a/include/linux/security.h b/include/linux/security.h
--- a/include/linux/security.h Wed Feb 5 14:58:15 2003
+++ b/include/linux/security.h Wed Feb 5 14:58:15 2003
@@ -47,6 +47,7 @@
extern int cap_task_post_setuid (uid_t old_ruid, uid_t old_euid, uid_t old_suid, int flags);
extern void cap_task_kmod_set_label (void);
extern void cap_task_reparent_to_init (struct task_struct *p);
+extern int cap_syslog (int type);
/*
* Values used in the task_security_ops calls
@@ -778,6 +779,12 @@
* @tsk contains the task_struct for the process.
* @cap contains the capability <include/linux/capability.h>.
* Return 0 if the capability is granted for @tsk.
+ * @syslog:
+ * Check permission before accessing the kernel message ring or changing
+ * logging to the console.
+ * See the syslog(2) manual page for an explanation of the @type values.
+ * @type contains the type of action.
+ * Return 0 if permission is granted.
*
* @register_security:
* allow module stacking.
@@ -808,6 +815,7 @@
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);
+ int (*syslog) (int type);
int (*bprm_alloc_security) (struct linux_binprm * bprm);
void (*bprm_free_security) (struct linux_binprm * bprm);
@@ -1013,6 +1021,11 @@
return security_ops->quota_on (file);
}
+static inline int security_syslog(int type)
+{
+ return security_ops->syslog(type);
+}
+
static inline int security_bprm_alloc (struct linux_binprm *bprm)
{
return security_ops->bprm_alloc_security (bprm);
@@ -1625,6 +1638,11 @@
static inline int security_quota_on (struct file * file)
{
return 0;
+}
+
+static inline int security_syslog(int type)
+{
+ return cap_syslog(type);
}
static inline int security_bprm_alloc (struct linux_binprm *bprm)
diff -Nru a/kernel/printk.c b/kernel/printk.c
--- a/kernel/printk.c Wed Feb 5 14:58:15 2003
+++ b/kernel/printk.c Wed Feb 5 14:58:15 2003
@@ -28,6 +28,7 @@
#include <linux/config.h>
#include <linux/delay.h>
#include <linux/smp.h>
+#include <linux/security.h>
#include <asm/uaccess.h>
@@ -161,6 +162,10 @@
char c;
int error = 0;
+ error = security_syslog(type);
+ if (error)
+ return error;
+
switch (type) {
case 0: /* Close log */
break;
@@ -273,8 +278,6 @@
asmlinkage long sys_syslog(int type, char * buf, int len)
{
- if ((type != 3) && !capable(CAP_SYS_ADMIN))
- return -EPERM;
return do_syslog(type, buf, len);
}
diff -Nru a/security/capability.c b/security/capability.c
--- a/security/capability.c Wed Feb 5 14:58:15 2003
+++ b/security/capability.c Wed Feb 5 14:58:15 2003
@@ -262,6 +262,13 @@
return;
}
+int cap_syslog (int type)
+{
+ if ((type != 3) && !capable(CAP_SYS_ADMIN))
+ return -EPERM;
+ return 0;
+}
+
EXPORT_SYMBOL(cap_capable);
EXPORT_SYMBOL(cap_ptrace);
EXPORT_SYMBOL(cap_capget);
@@ -272,6 +279,7 @@
EXPORT_SYMBOL(cap_task_post_setuid);
EXPORT_SYMBOL(cap_task_kmod_set_label);
EXPORT_SYMBOL(cap_task_reparent_to_init);
+EXPORT_SYMBOL(cap_syslog);
#ifdef CONFIG_SECURITY
@@ -289,6 +297,8 @@
.task_post_setuid = cap_task_post_setuid,
.task_kmod_set_label = cap_task_kmod_set_label,
.task_reparent_to_init = cap_task_reparent_to_init,
+
+ .syslog = cap_syslog,
};
#if defined(CONFIG_SECURITY_CAPABILITIES_MODULE)
diff -Nru a/security/dummy.c b/security/dummy.c
--- a/security/dummy.c Wed Feb 5 14:58:15 2003
+++ b/security/dummy.c Wed Feb 5 14:58:15 2003
@@ -90,6 +90,13 @@
return 0;
}
+static int dummy_syslog (int type)
+{
+ if ((type != 3) && current->euid)
+ return -EPERM;
+ return 0;
+}
+
static int dummy_bprm_alloc_security (struct linux_binprm *bprm)
{
return 0;
@@ -640,6 +647,7 @@
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, syslog);
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);
On Tue, Feb 04, 2003 at 08:15:38PM -0800, Greg KH wrote:
> Hi,
>
> These changesets include some new LSM hooks, all of which have been sent
> to lkml with no dissenting comments. Some of these hooks are the same
> ones I sent for 2.5.58, but were not picked up. These include hooks for
> syslog and sysctl, restores some previously lost hooks, and reworked the
> hooks for the security structures for private files.
I still don't see the issue of each LSM module having to duplicate the list
of sysctls beeing addressed. Coul you please work something out for that
before sending it for inclusion?
On Tue, Feb 04, 2003 at 08:16:11PM -0800, Greg KH wrote:
> diff -Nru a/fs/super.c b/fs/super.c
> --- a/fs/super.c Wed Feb 5 14:58:37 2003
> +++ b/fs/super.c Wed Feb 5 14:58:37 2003
> @@ -610,6 +610,7 @@
> struct file_system_type *type = get_fs_type(fstype);
> struct super_block *sb = ERR_PTR(-ENOMEM);
> struct vfsmount *mnt;
> + int error;
>
> if (!type)
> return ERR_PTR(-ENODEV);
> @@ -620,6 +621,13 @@
> sb = type->get_sb(type, flags, name, data);
> if (IS_ERR(sb))
> goto out_mnt;
> + error = security_sb_kern_mount(sb);
> + if (error) {
> + up_write(&sb->s_umount);
> + deactivate_super(sb);
> + sb = ERR_PTR(error);
> + goto out_mnt;
> + }
it would be nice if you could follow the syle in this function/file
and put the error handling code out of line. This is a general
complaint, btw - the LSM hooks seldomly follow the style of the
code around :(
Christoph Hellwig wrote:
> I still don't see the issue of each LSM module having to duplicate the list
> of sysctls beeing addressed. Coul you please work something out for that
> before sending it for inclusion?
I already responded to this concern in
http://marc.theaimsgroup.com/?l=linux-kernel&m=104316038729345&w=2 and
http://marc.theaimsgroup.com/?l=linux-security-module&m=104316278400987&w=2.
At most, a field might be added to the ctl_table structure so that the kernel
can provide a hint to security modules as to its view of the sensitivity of
a given sysctl variable, but this does not require any change to the sysctl
hook interface.
--
Stephen Smalley, NSA
[email protected]
On Wed, Feb 05, 2003 at 08:45:16AM -0500, Stephen D. Smalley wrote:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=104316038729345&w=2 and
> http://marc.theaimsgroup.com/?l=linux-security-module&m=104316278400987&w=2.
> At most, a field might be added to the ctl_table structure so that the kernel
> can provide a hint to security modules as to its view of the sensitivity of
> a given sysctl variable, but this does not require any change to the sysctl
> hook interface.
Of course that needs further changes!
(a) actually implement that field, and
(b) change the prototype of the hook to int (*sysctl)(int op, enum sensitivity);
Christoph Hellwig wrote:
> Of course that needs further changes!
>
> (a) actually implement that field, and
> (b) change the prototype of the hook to int (*sysctl)(int op, enum sensitivity);
No. If one were to add such a field, then it would be accessible
through the ctl_table structure that is already passed to the hook.
You would not replace the ctl_table parameter with the kernel's
sensitivity hint, since the security module must be able to make its
own determination as to the protection requirements based on its
particular security model and attributes. If you only pass the
kernel's view of the sensitivity, then you are hardcoding a specific
policy into the kernel and severely limiting the flexibility of the
security module. Since the kernel's hint is necessarily independent of
any particular security model/attributes, it will only provide a
coarse-grained partitioning, e.g. you are unlikely to be able to
uniquely distinguish the modprobe variable if you want to specifically
limit a particular process to modifying it. The existing hook
interface does not need to change.
Implementing a sensitivity hint field in the ctl_table structure would
be trivial, but determining a set of policy-neutral hint values that
capture important confidentiality, integrity, and functional
characteristics and mapping the existing set of sysctl variables to
those hint values is a longer term task. The hook provides useful
functionality now, apart from such hints, and should not need to wait
on them. In the short term, there may be a certain amount of
duplication of information among security modules regarding sensitive
sysctl variables, but that information can actually help to feed back
into the process of determining the right general set of hint values
necessary to support multiple security models and the mappings for
the existing sysctl variables.
--
Stephen Smalley, NSA
[email protected]
On Wed, Feb 05, 2003 at 10:00:23AM -0500, Stephen D. Smalley wrote:
> No. If one were to add such a field, then it would be accessible
> through the ctl_table structure that is already passed to the hook.
It would. But it shouldn't be passed in for the first time.
> You would not replace the ctl_table parameter with the kernel's
> sensitivity hint, since the security module must be able to make its
> own determination as to the protection requirements based on its
> particular security model and attributes. If you only pass the
> kernel's view of the sensitivity, then you are hardcoding a specific
> policy into the kernel and severely limiting the flexibility of the
> security module.
Yes, and exactly that's the whole point of it! The problem with LSM
is that it tries to be overly flexible and thus adds random hooks that
expose internal details all over the place. Just stop that silly no policy
approach and life will get a lot simpler. There's no reason to implement
everything and a kitchen sink in LSM.
Since the kernel's hint is necessarily independent of
> any particular security model/attributes, it will only provide a
> coarse-grained partitioning, e.g. you are unlikely to be able to
> uniquely distinguish the modprobe variable if you want to specifically
> limit a particular process to modifying it. The existing hook
> interface does not need to change.
If you need attributes attached to the sysctl nodes just diable sysctl by
number and use the existing filesystem based hooks.
> No. If one were to add such a field, then it would be accessible
> through the ctl_table structure that is already passed to the hook.
> You would not replace the ctl_table parameter with the kernel's
> sensitivity hint, since the security module must be able to make its
can all this LSM nonsese be CONFIG'ed out of the kernel as promised?
Christoph Hellwig wrote:
> Yes, and exactly that's the whole point of it! The problem with LSM
> is that it tries to be overly flexible and thus adds random hooks that
> expose internal details all over the place. Just stop that silly no policy
> approach and life will get a lot simpler. There's no reason to implement
> everything and a kitchen sink in LSM.
The sysctl hook simply provides a way for a security module to
implement a security check for access to sysctl variables. It provides
a classic kernel object (ctl_table) x operation interface, with the
subject implicitly passed via current, just like permission() for
inodes. A security module can leave the hook unimplemented (no
restrictions beyond DAC), or implement a purely process-based
restriction or implement fine-grained controls to individual sysctls.
Sysctls are already exposed to userspace via sysctl(2) and/or
/proc/sys, so I'm not sure what the concern is there. Nothing
complicated here.
As to your argument about LSM's flexibility, LSM simply followed the
guidance on what would be accepted into 2.5. The original
SELinux/Flask architecture was more tightly integrated and had
well-defined boundaries while still providing substantial flexibility,
but the response to the SELinux presentation was to move towards
something more like LSM. Seems pointless to argue about it now, except
as suggestions for future directions for LSM in 2.7.
> If you need attributes attached to the sysctl nodes just diable sysctl by
> number and use the existing filesystem based hooks.
Sorry, I don't see why this is preferable to implementing a single
security hook in ctl_perm that is invoked for both sysctl(2) and
/proc/sys access, providing a consistent access control regardless of
the interface. Your approach is more prone to vulnerability (failing to
disable the sysctl(2) interface), and breaking application compatibility.
--
Stephen Smalley, NSA
[email protected]
On Wed, Feb 05, 2003 at 11:47:05AM -0500, Stephen D. Smalley wrote:
> a classic kernel object (ctl_table) x operation interface, with the
> subject implicitly passed via current, just like permission() for
> inodes. A security module can leave the hook unimplemented (no
> restrictions beyond DAC), or implement a purely process-based
> restriction or implement fine-grained controls to individual sysctls.
> Sysctls are already exposed to userspace via sysctl(2) and/or
> /proc/sys, so I'm not sure what the concern is there. Nothing
> complicated here.
The wrong thing here is that you pass in the object itself, not
it's ACC-relevant attributes.
>
> As to your argument about LSM's flexibility, LSM simply followed the
> guidance on what would be accepted into 2.5. The original
> SELinux/Flask architecture was more tightly integrated and had
> well-defined boundaries while still providing substantial flexibility,
> but the response to the SELinux presentation was to move towards
> something more like LSM. Seems pointless to argue about it now, except
> as suggestions for future directions for LSM in 2.7.
No it seems not pointless. You add tons of undesigned cruft to 2.5 that
will have to be maintained through all of 2.6. unless Linus hopefully
pulls the plug soon enough. You still haven't even submitted a single
example that actually uses LSM into mainline.
Yes, I'm pissed that we get this crap all over the place, making code
harder to follow and that without any actual benefit to the mainline tree.
Please come up with something better for 2.7 and leave 2.5 alone, this will
help anyone.
Mark Hahn wrote:
> can all this LSM nonsese be CONFIG'ed out of the kernel as promised?
Yes. CONFIG_SECURITY=n makes it all go away. But if your mind isn't
completely closed on the topic, you might want to read some of the
following published papers before concluding that it is nonsense:
1) The Inevitability of Failure: The Flawed Assumption of Security in
Modern Computing Environments, available online from
http://www.nsa.gov/selinux/inevit-abs.html.
2) The published papers about SELinux from the 2001 FREENIX and 2001
OLS, available online from http://www.nsa.gov/selinux/docs.html.
3) The published papers about LSM from the 2002 Usenix Security and
2002 OLS, available online from http://lsm.immunix.org/lsm_doc.html.
--
Stephen Smalley, NSA
[email protected]
On Wed, Feb 05, 2003 at 04:49:48PM +0000, Christoph Hellwig wrote:
> No it seems not pointless. You add tons of undesigned cruft to 2.5 that
> will have to be maintained through all of 2.6. unless Linus hopefully
> pulls the plug soon enough.
I'm tired of reading this crap every time I submit a LSM patch.
I'll say it for the last time... LSM was designed and didn't just plop
into existence. The group has published numerous design documents both
explaining the decisions and rational behind the design and
implementation of the project. They are available at lsm.immunix.org,
as you probably already know. I know you don't like the implementation
we currently have, but as no one has stepped up with a different
implementation, that has been designed and tested to work for an
extremely wide range of different security models, I suggest you stop
this kind of attack.
However, concrete criticism of specific implementation details, like you
have done in the past is welcome, and encouraged. I'll look into your
comment about coding style issues that you mentioned earlier in this
thread.
> You still haven't even submitted a single example that actually uses
> LSM into mainline.
Um, what's security/root_plug.c then? :)
greg k-h
On Wed, Feb 05, 2003 at 02:07:55PM -0800, Greg KH wrote:
> On Wed, Feb 05, 2003 at 04:49:48PM +0000, Christoph Hellwig wrote:
> > No it seems not pointless. You add tons of undesigned cruft to 2.5 that
> > will have to be maintained through all of 2.6. unless Linus hopefully
> > pulls the plug soon enough.
>
> I'm tired of reading this crap every time I submit a LSM patch.
And I'm tired of this hooks creaping all over the kernel like a cancer...
> I'll say it for the last time... LSM was designed and didn't just plop
> into existence. The group has published numerous design documents both
> explaining the decisions and rational behind the design and
> implementation of the project. They are available at lsm.immunix.org,
> as you probably already know. I know you don't like the implementation
> we currently have, but as no one has stepped up with a different
> implementation, that has been designed and tested to work for an
> extremely wide range of different security models, I suggest you stop
> this kind of attack.
Sorry, but I care for the Linux kernel and think adding this stuff all
over the place will not help us in the long term. In fact I'm pretty sure
that > C2 grade security in a general purpose Operating System is a really
bad idea. My first choice as a replacement would be throwing it out
of the kernel entirely. As for less invasive and more though out design
if for whatever reason we still need to keep this we had tons of discussion
here on the lists and on irc.
The main point is that LSM in the current shape, with every single policy
detail left to the modules (compare that say to the linux filesystem code
where we have lots of very different filesystems and still have as much as
possible policy decision in the core code, this is one of the really strong
points of Linux!) is a very bad idea and I _really_ don't want to see
it in the next major stable release.
And no, I don't complain on every single patch, just those that are overly
ugly.
> > You still haven't even submitted a single example that actually uses
> > LSM into mainline.
>
> Um, what's security/root_plug.c then? :)
It's a small hack. But if you think it's representative for LSM I'm
fine with that and I'll submit a patch removing every hook except of
the single one actually used by it.
On Wed, Feb 05, 2003 at 11:39:46PM +0100, Russell Coker wrote:
> Now as for the issue of code to use the hooks, SE Linux uses almost all the
> hooks and I'm sure that Steve can send in the appropriate patch at any
> time...
Of course he could send it. Whether it has a chance of beeing accepted
is an entirely different question, though..
On Wed, 5 Feb 2003 23:30, Christoph Hellwig wrote:
> The main point is that LSM in the current shape, with every single policy
> detail left to the modules (compare that say to the linux filesystem code
> where we have lots of very different filesystems and still have as much as
> possible policy decision in the core code, this is one of the really strong
> points of Linux!) is a very bad idea and I _really_ don't want to see
> it in the next major stable release.
My understanding is that LSM was created at the request of Linus because there
were several groups of people who had different patches for security policy
in "core code". Linus apparently didn't like that idea and requested a
framework so that Linux would not be tied to one particular security model.
Someone please correct me if my understanding of LSM history is incorrect.
Now as for the issue of code to use the hooks, SE Linux uses almost all the
hooks and I'm sure that Steve can send in the appropriate patch at any
time...
--
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 wrote:
> The wrong thing here is that you pass in the object itself, not
> it's ACC-relevant attributes.
That's no different than permission(), and it is the style of interface
suggested by Linus originally for LSM. SELinux did provide an
interface more akin to what you describe (passing the security
identifiers of the process and relevant objects and a value indicating
the operation). But SELinux was also more tightly integrated into the
kernel. The original guidance for LSM was to simply pass the objects
and to use separate hooks for different operations, moving the
processing entirely into the module.
Bringing this all up now is definitely pointless. LSM wasn't developed
in secret, and you could have made your case for a different
approach/interface at the very beginning. If you had made a case early
on, and had gotten Linus to sign off on it, then we certainly wouldn't
have objected to such an approach.
> No it seems not pointless. You add tons of undesigned cruft to 2.5 that
> will have to be maintained through all of 2.6. unless Linus hopefully
> pulls the plug soon enough. You still haven't even submitted a single
> example that actually uses LSM into mainline.
Not undesigned, but designed to meet guidance with which you disagree.
There is a difference.
The capabilities module is one example, albeit a limited one. As for
modules like SELinux, it seems better to wait until all of the
necessary hooks have either been accepted or definitively rejected
before submitting an adapted form of the module for mainline. After
this set of changes, the only thing remaining is the networking hooks,
which have already gone through a feedback cycle with the networking
maintainers and are being pruned and revised accordingly.
--
Stephen Smalley, NSA
[email protected]
On Thu, Feb 06, 2003 at 10:02:37AM -0500, Stephen D. Smalley wrote:
> The capabilities module is one example, albeit a limited one. As for
> modules like SELinux, it seems better to wait until all of the
> necessary hooks have either been accepted or definitively rejected
> before submitting an adapted form of the module for mainline. After
> this set of changes, the only thing remaining is the networking hooks,
> which have already gone through a feedback cycle with the networking
> maintainers and are being pruned and revised accordingly.
Well, selinux is still far from a mergeable shape and even needed additional
patches to the LSM tree last time I checked. This think of submitting hooks
for code that obviously isn't even intende to be merged in mainline is what
I really dislike, and it's the root for many problems with LSM.
There has been a history in Linux to only implement what actually needed
now instead of "clever" overdesigns that intend to look into the future,
LSM is a gross voilation of that principle. Just look at the modules in
the LSM source tree: the only full featured security policy in addition
to the traditional Linux model is LSM, all the other stuff is just some
additionl checks here and there.
I'm very serious about submitting a patch to Linus to remove all hooks not
used by any intree module once 2.6.0-test.
Life would be a lot simpler if you got the core flask engine in a mergeable
shapre earlier and we could have merged the hooks for actually using it
incrementally during 2.5, discussing the pros and contras for each hook
given an actual example - but the current way of adding extremly generic
hooks (despite the naming they are in no ways tied to enforcing security
models at all) without showing and discussing the code behind them simply
makes that impossible.
So yes, my suggestion is to backout the whole LSM mess for 2.6, merge
a sample policy core (i.e. a cleaned up flask/selinux) in 2.7.<early> and
then add one hook after another and discussing the architecture openly
where it belongs (here on lkml!).
On Thu, 2003-02-06 at 15:18, Christoph Hellwig wrote:
> Life would be a lot simpler if you got the core flask engine in a mergeable
> shapre earlier and we could have merged the hooks for actually using it
> incrementally during 2.5, discussing the pros and contras for each hook
I'm not sure we can until the flask engine patent problems with secure
computing are completely resolved and understood.
Getting it all resolved and in the base 2.7 early, with any cleanup, fixing
needed would be a good step forward
Christoph Hellwig wrote:
>Well, selinux is still far from a mergeable shape and even needed additional
>patches to the LSM tree last time I checked. This think of submitting hooks
>for code that obviously isn't even intende to be merged in mainline is what
>I really dislike, and it's the root for many problems with LSM.
You keep bringing up SELinux. Maybe you dislike SELinux; I don't know.
In any case, LSM is not there just to support SELinux. It's intended
to support a broad range of security modules and security policies.
LSM is bigger than just SELinux.
[it would be really nice if you at least Cc'ed me when replying to my mails..
*sigh*]
On Thu, Feb 06, 2003 at 05:16:39PM +0000, David Wagner wrote:
> Christoph Hellwig wrote:
> >Well, selinux is still far from a mergeable shape and even needed additional
> >patches to the LSM tree last time I checked. This think of submitting hooks
> >for code that obviously isn't even intende to be merged in mainline is what
> >I really dislike, and it's the root for many problems with LSM.
>
> You keep bringing up SELinux. Maybe you dislike SELinux; I don't know.
> In any case, LSM is not there just to support SELinux. It's intended
> to support a broad range of security modules and security policies.
> LSM is bigger than just SELinux.
I bring up selinux because it's the only module in the lsm patches that I
consider more than just a bunch of hacks. So, no it's not a dislike but
they only thing I actually consider worth mentioning.
On Thu, 6 Feb 2003, Christoph Hellwig wrote:
> Well, selinux is still far from a mergeable shape and even needed additional
> patches to the LSM tree last time I checked. This think of submitting hooks
> for code that obviously isn't even intende to be merged in mainline is what
> I really dislike, and it's the root for many problems with LSM.
I disagree. The code submitted BOTH addresses the current needs and
"vaguely anticipated future needs" (which I shall define as VAFN). I've
applied this code to my "personal security solution" and found it
*largely* to address my needs. Wanna see my code? *NO* I have other
plans for my code, but I still think LSM supports me more than the 2.4
kernel does and, therefore, *I* believe it is a move in the right
direction for the kernel.
>
> There has been a history in Linux to only implement what actually needed
> now instead of "clever" overdesigns that intend to look into the future,
> LSM is a gross voilation of that principle. Just look at the modules in
> the LSM source tree: the only full featured security policy in addition
> to the traditional Linux model is LSM, all the other stuff is just some
> additionl checks here and there.
>
This is correct, except in its overall evaluation of Linux. Linux has
accepted only "actually needed" code, but it has FURTHER accepted
"actually needed but GENERALLY useful code." If one can accept code that
already has a purpose AND support other "'clever' overdesigns that intend
to look into the future" which are "not-opposed-to-current-thinking", one
has moved one's project closer to an ideal.
You can narrow AND widen, and Linux is the *best* example of that policy,
to date. There's no dishonor in accepting solutions that do what they
advertise AND allow what they have not advertised... provided they not
allow things widely defined as "evil."
> I'm very serious about submitting a patch to Linus to remove all hooks not
> used by any intree module once 2.6.0-test.
This would be unfortunate. Narrow is good when one approaches a narrow
target, but LSM targets a wide target: Linux Security.
>
> Life would be a lot simpler if you got the core flask engine in a mergeable
> shapre earlier and we could have merged the hooks for actually using it
> incrementally during 2.5, discussing the pros and contras for each hook
> given an actual example - but the current way of adding extremly generic
> hooks (despite the naming they are in no ways tied to enforcing security
> models at all) without showing and discussing the code behind them simply
> makes that impossible.
>
Open your mind. LSM supports both all current solutions for object-level
security AND provides a valid basis for moving Linux toward providing, AS
AN OPTION, true security. Personally, I don't think LSM is the "be all
and end all" of a security interface, at this point, but I *do* think it's
the best first-draft of a system that can lead to that end.
Give me THREE design attributes that would make it better. Bet you can't
come up with ONE.
LSM is NOT the *perfect* solution. But I defy you to find a better
"first step" toward the solution of making Linux a "secure operating
system". Nobody says it's cheap and the idea of making it a config-out
solution addresses that.
What's your REAL problem? Somebody stepping on your territory?
J. Melvin Jones
*-------------------------------------------------------
* J. Melvin Jones http://www.jmjones.com/
* Webmaster, System Administrator, Network Administrator
* ------------------------------------------------------
[email protected] writes:
> What's your REAL problem? Somebody stepping on your territory?
Come on, don't be an ass.
Perhaps there are people on this mailing list who play silly territorial
games, but I don't think Christoph is one of them. If he suggests that
there's a problem with something, the likely reason is that there's a
problem.
-Miles
--
Come now, if we were really planning to harm you, would we be waiting here,
beside the path, in the very darkest part of the forest?
On Fri, Feb 07, 2003 at 09:20:08PM -0500, [email protected] wrote:
> I disagree. The code submitted BOTH addresses the current needs and
> "vaguely anticipated future needs" (which I shall define as VAFN).
What is the "current needs" given that selinux is the only module actually
using it and it's neither in a mergeable shape nor is it legally clear
whether it can be merged?
> Open your mind. LSM supports both all current solutions for object-level
> security AND provides a valid basis for moving Linux toward providing, AS
> AN OPTION, true security. Personally, I don't think LSM is the "be all
> and end all" of a security interface, at this point, but I *do* think it's
> the best first-draft of a system that can lead to that end.
you don't get tru security by adding hooks. security needs a careful
design and more strict access control policy can but don't have to be part
of that design.
> What's your REAL problem? Somebody stepping on your territory?
The real problem is adding mess to the kernel.
Christoph Hellwig wrote:
>you don't get tru security by adding hooks. security needs a careful
>design and more strict access control policy can but don't have to be part
>of that design.
>
LSM does have a careful design. The design goal was to permit loadable
kernel modules to mediate access to critical kernel objects by user
level processes. By providing such a facility, LSM enables arbitrary
security policies and policy management engines to be implemented as
loadable modules. This solves the "make one size fit all" problem of
diverse interests lobbying Linus to adopt one security model or another
as the Linux standard. The LSM design saves Linus from having to make
such a choice by allowing end-users to make their own choice, meeting a
goal stated by Linus nearly two years ago.
>The real problem is adding mess to the kernel.
>
Christoph's problem is likely that he doesn't like the design. Fair
enough, can't please everyone, but a lot of effort went into that
design. I also suspect that Christoph does not approve of Linus' design
goal either, but he's never said that when I was looking.
Crispin
--
Crispin Cowan, Ph.D.
Chief Scientist, WireX http://wirex.com/~crispin/
Security Hardened Linux Distribution: http://immunix.org
Just say ".Nyet"
> From: Crispin Cowan
>
> Christoph Hellwig wrote:
>
> LSM does have a careful design. The design goal was to permit loadable
> kernel modules to mediate access to critical kernel objects by user
> level processes. By providing such a facility, LSM enables arbitrary
> security policies and policy management engines to be implemented as
> loadable modules. This solves the "make one size fit all" problem of
> diverse interests lobbying Linus to adopt one security model or another
> as the Linux standard. The LSM design saves Linus from having to make
> such a choice by allowing end-users to make their own choice, meeting a
> goal stated by Linus nearly two years ago.
====
A security model that mediates access to security objects by
logging all access and blocking access if logging cannot continue is
unsupportable in any straight forward, efficient and/or non-kludgy, ugly
way.
LSM is a collection of hack & hooks thrown together in an ad-hoc
manner to support those people who were able to lobby their specific
security policies. Some security people were banned from the kernel
devel. summit because their thoughts were deemed 'dangerous': fear was they
were too persuasive about ideas that were deemed 'ignorant' and would
fool those poor kernel lambs at the summit.
Also unsupported: The "no-security" model -- where all security
is thrown out (to save memory space and cycles) that was desired for embedded work.
LSM also doesn't support standard LSPP-B1 style graded security
where mandatory access checks are logged as security violations before
DAC checks are even looked at for an object.
At one point a plan was proposed (by Casey Schaufler, SGI) and
_\implemented\_ (team members & prjct lead Linda Walsh) to move all
security checks out of the kernel into a 'default policy' module.
The code to implement this was submitted to the LSM list in June 1991.
This plan was shot down as "too radical". It wasn't what the "kernel
programmers" wanted. "They" would never accept it and therefore, LSM wouldn't accept it without prior approval from the "kernel
programmers".
When such approval was sought, the seeking party was drawn and quartered
for having the temerity to actually ask the question (since asking the question pointed out the failings of LSM to meet its original
design
goals).
>
> >The real problem is adding mess to the kernel.
> >
> Christoph's problem is likely that he doesn't like the design. Fair
> enough, can't please everyone, but a lot of effort went into that
> design.
---
True...alot of effort went into building the Titanic as well.
The modular security model was implemented via macros and cleaned
up the logic of the kernel code by moving toward single exit points
that could allow consistent release of acquired data structures and locks
depending on where failure occurred. That alone made the code more
readily understandable and maintainable. Removing security policy
from the code into separate modules also made validation of security
considerably easier.
So...of course, it wasn't wanted.
LSM may implement some number of policies, but it is neither robust
nor easy to use. Only recently was it decided not to require that every
security module to know about every hook. That was also suggested almost
2 years ago because the current setup makes the implementation of
security policies *MUCH* more complicated...and, theoretically, inherently
less provably secure.
l. walsh
LA Walsh wrote:
>>From: Crispin Cowan
>>
>>LSM does have a careful design.... meeting a
>>goal stated by Linus nearly two years ago.
>>
>>
> A security model that mediates access to security objects by
>logging all access and blocking access if logging cannot continue is
>unsupportable in any straight forward, efficient and/or non-kludgy, ugly
>way.
>
Because Linus asked for access control support, not audit logging
support, it is not surprising that logging models don't fit so well.
> Some security people were banned from the kernel
>devel. summit because their thoughts were deemed 'dangerous': fear was they
>were too persuasive about ideas that were deemed 'ignorant' and would
>fool those poor kernel lambs at the summit.
>
Internal SGI politics.
> Also unsupported: The "no-security" model -- where all security
>is thrown out (to save memory space and cycles) that was desired for embedded work.
>
False: capabilities is now a removable module, which is what Linus asked
for.
> LSM also doesn't support standard LSPP-B1 style graded security
>where mandatory access checks are logged as security violations before
>DAC checks are even looked at for an object.
>
Because doing so would have required approx. 6-10X as many LSM hooks as
the current LSM. Speak up if you think LSM should be 10X bigger to be
able to support Common Criteria standards compliant audit logging ...
> At one point a plan was proposed (by Casey Schaufler, SGI) and
>_\implemented\_ (team members & prjct lead Linda Walsh) to move all
>security checks out of the kernel into a 'default policy' module.
>The code to implement this was submitted to the LSM list in June 1991.
>
And I actually like that plan. But I still believe it to be too radical
for 2.6. It has many nice properties, but is much more invasive to the
kernel. I think it is a very interesting idea for 2.7, and should be
floated past the maintainers who will be impacted to see if it has a
hope in hell.
Crispin
--
Crispin Cowan, Ph.D.
Chief Scientist, WireX http://wirex.com/~crispin/
Security Hardened Linux Distribution: http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html
Just say ".Nyet"
LA Walsh wrote:
> At one point a plan was proposed (by Casey Schaufler, SGI) and
>_\implemented\_ (team members & prjct lead Linda Walsh) to move all
>security checks out of the kernel into a 'default policy' module.
>The code to implement this was submitted to the LSM list in June 1991.
>
er - are you quite certain about that date?
;-)
Joe
Christoph Hellwig wrote:
>[...] given that selinux is the only module actually using it [...]
No, it's not. I keep you telling you LSM is not just about SELinux,
but I'm happy to say it again, if necessary.
>you don't get tru security by adding hooks.
Of course not. Noone is saying that the LSM hooks alone give security;
rather, they enable you to install a module that gives security.
>security needs a careful design
You keep saying this. People keep telling you that LSM does have a
careful design. I suspect you mean that you don't like the design we
chose, for whatever reason -- but that's a different sort of beast,
isn't it?
If you have constructive suggestions, I'm listening.
On Mon, Feb 10, 2003 at 05:59:19AM +0000, David Wagner wrote:
> Christoph Hellwig wrote:
> >[...] given that selinux is the only module actually using it [...]
>
> No, it's not. I keep you telling you LSM is not just about SELinux,
> but I'm happy to say it again, if necessary.
So show me a different module using most of the hooks, it's that simple!
> On Wed Apr 11 2001 - 18:28:50 PDT
> Crispin Cowan, Ph.D (Chief Scientist, WireX) claims:
>
> Because Linus asked for access control support, not audit logging
> support, it is not surprising that logging models don't fit so well.
Oh really? On Wed Apr 11 2001 - 18:28:50 PDT
From: Crispin Cowan ([email protected]) told us:
"Linus ...observes that there are many different security
approaches, each with their own advocates. He doesn't want
to arbitrate which of them should be "the" Linux security
approach, and would rather that Linux can support any of
them.
That is the purpose of this project: to allow Linux to
support a variety of security models"
---
You recognize that as your writing? Perhaps with the context of
the full post, below, it will help. Even more so, Linus's emails that
defined the "charter" are also included below.
Maybe I'm delusional, but you are contradicting yourself. In
common terms, this is called lying. Either Linus didn't say he wanted
something "truly generic" (his words), and you made up the email from
Linus or you are trying to change what he said to suite your current
purposes. You suckered in more than a few people with promises from below and then changed things cause you and other lsm members
were too
afraid that the right thing wouldn't fly with "the kernel programmers".
Security isn't just an afterthought you can patch on and cross
your fingers and hope it won't break. It has to be designed in.
Lsm came closest to that when we put the code on the table (2001, not 1991)
to fundamentally redesign linux security for today's needs. Instead, we
end up with dribbled in patches of mediocrity that put us one step
closer to the byzantine, "Microsoftesque" OS model.
By some basic, unwritten, design short-comings (not present in the original plan), you have something that is neither
"simple" nor
"generic".
Complete text is written below if anyone cares to see how much
lsm has strayed and compromised away from the original charter.
Special.
-l
-------------------------------------------------------------------
From: Crispin Cowan ([email protected])
Date: Wed Apr 11 2001 - 18:28:50 PDT
--------------------------------------------------------------------------------
Greetings. Thanks for your patience at the lack of traffic on the first day of
this list. Subscriptions grew rapidly from nil to 202 in the last 24 hours, and
has now tapered off. I held back posting introductory materials so that I
wouldn't have to post them three or four times :-)
Naturally, everyone is curious what this project is about in general: why use a
generic security module interface? And in particular, what has changed in Linus'
view of security extensions. Rather than attempt to speak for Linus, I will
quote what he said in a private forum, and we can proceed from there.
It is Linus' comments that spurred me to want to start this undertaking. He
observes that there are many different security approaches, each with their own
advocates. He doesn't want to arbitrate which of them should be "the" Linux
security approach, and would rather that Linux can support any of them.
That is the purpose of this project: to allow Linux to support a variety of
security models, so that security developers don't have to have the "my dog's
bigger than your dog" argument, and users can choose the security model that
suits their needs.
Crispin
--
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution: http://immunix.org
------------------------------------------------------------------------
Linus Torvalds wrote:
> On Fri, 6 Apr 2001, Peter G. Neumann wrote:
> >
> > No mention of security or reliability. Is that an omission of
> > Edupage or of the gurus?
>
> I think it's another commentary on security not being "interesting".
>
> We had a NSA person give a talk about selinux, and I personally wouldn't
> mind having a better infrastructure in place in the kernel for things like
> that. HOWEVER, my problem as a system maintainer is that I don't see
> people agreeing about the right solution.
>
> The embedded people don't really want security management (or rather, to
> them, the simple "root is all" approach is fine, and takes up less space
> than more complex schemes with the selinux kind of security managers etc).
>
> And even the security people aren't really sure which _sort_ of security
> support they want (or rather - they all KNOW which kind of security
> management they want, but there are as many different opinions as there
> are people).
>
> So I'm not interested in any one particular approach, TE/DTE/MLS or
> whatever. I can't even discuss the difference intelligently anyway (or
> even play at it), but what I can tell is that there is no "one right way".
> And that's without even getting into the issue of what the policy should
> be for them.
>
> Which means that what _I_ would require from something that gets
> integrated into Linux is either:
>
> - true simplicity. "euid == 0" is this. capabilities are an approximation
> of this, and it turns out that almost nobody even uses capabilities
> just because they are complex enough to administer that they are of
> dubious value in many cases. The notion of an extended "suid" bit (with
> an ELF header of capabilities) has been bandied around for a long time,
> and the fact is that it would be a total maintenance nightmare. And
> that's the _simple_ case.
>
> This is where Linux is now, and this is where we'll remain, unless we
> get the alternative:
>
> - truly generic. No "MLS" vs "TE" vs "uid==0" vs "capability" at ALL.
> Something where the "uid == 0" version of security is just one case
> (which the embedded people might use), or where SELinux would be just a
> matter of loading the SELinux module and installing _that_ security
> model.
>
> Quite frankly, nobody seems to be interested in actually trying to do the
> latter. Everybody has their _own_ particular flavour that they want to
> push, and don't realize that I cannot accept that as a maintainer.
>
> I would, for example, be willing to entertain the notion of having a
> (global or per-process or whatever) pointer to a "security checks"
> structure:
>
> struct security_checks_struct {
> int (*execve)(struct task_struct *tsk,struct binprm *new);
> int (*file_open)(struct file *);
> int (*raise_capability)(...
> ...
> ... selinux had about 140 points they wanted to hook into ..
> ... others probably have a few more.
> ...
> };
>
> and then just have a opaque per-security-model security ID thing scattered
> around in critical places (the obvious being the thread structure, files,
> directory cache, inodes, etc). And instead of having _any_ policy at all,
> the kernel would just call the security procedure. Which might choose to
> fail (-EFASCIST) or might choose to return success but silently downgrade
> the security of the process that does the action, or whatever.
>
> Please understand that from _my_ perspective as a technical OS guy, I
> don't actually care about what the policy is, or who makes it up. I only
> care about not painting Linux into a corner. And I care about it being
> efficient and _conceptually_ simple (it doesn't matter to me if any
> particular security decision is really hard to make or not).
>
> I can live with the overhead of a function pointer access. As Don Knuth
> said: every problem in computer science can be solved with an added level
> of indirection. I'm not interested in the fight between different security
> people. I want the indirection that gets _me_ out of that picture, and
> then the market can fight out which policy and implementation actually
> ends up getting _used_.
>
> Linus
------------------------------------------------------------------------
Linus Torvalds wrote:
> On Sat, 7 Apr 2001, David Wagner wrote:
>
> > > I would, for example, be willing to entertain the notion of having a
> > > (global or per-process or whatever) pointer to a "security checks"
> > > structure:
> > >
> > > struct security_checks_struct {
> ...
> > > and then just have a opaque per-security-model security ID thing scattered
> > > around in critical places (the obvious being the thread structure, files,
> > > directory cache, inodes, etc).
> >
> > Let me suggest a few design issues for consideration:
> >
> > - State.
>
> Absolutely. This is the "opaque per-security-model security ID thing". You
> absolutely _have_ to have state for a lot of interesting security models.
> In fact, even simple capabilities are "state" - the only common stateless
> security model is the "euid == 0" one, where the "state" is actually just
> super-imposed on the user ID (ie it's really stateful too, it's just that
> the state is shared with "non-security" issues).
>
> > - Passive vs. active filtering.
>
> Again, passive filtering doesn't actually work. UNIX already has one
> mandated way of active filtering, namely the execve() case for suid
> executables. I would absolutely prefer to see that as just another case of
> filtering, not as some special case.
>
> Which implies that all the other functions might as well also do active
> changes to the security model. Things like "uhhuh, he opened a file that
> was marked secure, we must thus mark the whole process secure and make
> sure that all current and future file descriptors are trusted".
>
> Just returning an error code is not enough. Active side effects are a
> natural and important part of many security models.
>
> > - Composition of policies.
> > How are policy extensions combined? Can we have wuftpd restricted
> > according to SELinux policy, sendmail according to Janus policy, ...
>
> This is problematic.
>
> The problem is the "security ID". If you allow concurrent security
> policies, they need to have ways of agreeing on the meaning of the
> security ID, or the system needs to support the notion of multiple
> concurrent security ID's (and associate them with the right policy). And
> THAT is hard. It's probably hard enough to not be worth it, and most
> people who want the flexibility would be probably be willing to code up
> the "supercase" in the security manager, instead of trying to mix security
> models dynamically.
>
> This is especially true as the interactions could be "interesting", and
> probably very hard indeed to validate.
>
> In short, my personal opinion would be a big NO, simply from a system
> design standpoint. With one small modifier:
>
> I did suggest a "per-process" security pointer. The reason is that even if
> the system doesn't actually enforce any policy, there obviously _has_ to
> be a default policy. The policy could be anything, from "allow everything"
> to "allow nothing", although the latter would make it really hard to
> bootstrap a system ;)
>
> For obvious reasons, the natural "default policy" is the one that Linux
> already has: capabilities. As that is "nearly stateless" (and can be
> considered essentially stateless if you just leave the current capability
> bits in the process space and do not try to move them into the new "opaque
> security ID" part of the process), that default policy can co-exist with
> any other policy by virtue of not ever actually touching the "opaque
> security ID".
>
> And allowing that co-existence (by having the security action stucture
> pointer be per-process) makes it _much_ easier to have a graceful
> transition to the new scheme. As an example:
>
> - the system comes up in "legacy" mode with the capabilities (but you
> might as well think of it as "root user can do anything", because that
> is hot 99.999% of people end up using the capabilities).
>
> - the "security environment" is started. Unlike all existing models, this
> "security environment" doesn't actually have to have _any_ practical
> compatibility at all with the legacy mode, as those things can be
> handled ourside the security environment using the proper legacy tools.
>
> - the system manager might choose, for example, to leave the
> old-fashioned getty system for the local console, using the default
> capability system. This way the manager might log in at the system
> console (but nowhere else), and be completely _outside_ the secure
> area.
>
> Imagine the implications: your "security manager" doesn't need to actually
> worry about system management at all, because you might have the policy
> that all system management _must_ be done at the physical system console.
> As such, your security policies may not even have the _notion_ of allowing
> for "raised capabilities", and as such there is absolutely no way anybody
> could get higher capabilities than those they started with.
>
> Most traditional security systems need to have _some_ way of getting
> higher privileges for true system management. By using the above
> "per-process security management" setup, you kind of get it for free. You
> might run all your services inside a security model that simply does not
> _have_ a way out. Not for management, not for anything. Because management
> is done completely ourside the security model.
>
> Useful? Sounds useful to me. It also sounds simple to implement, and gives
> you perfect backwards compatibility without the security manager having to
> even worry about it - because the security manager wouldn't even be
> involved in the legacy stuff.
>
> > - What to interpose on?
> > Here are a few suggestions for possibilities: interposition on all
> > system calls; interposition on all VFS calls; on sockets. What else?
>
> Not at a system call level. It gets too intrusive, and too many people
> (including me) start to worry a _lot_ if you lose even one cycle in the
> system call path. Linux system calls are lightweight, and I like them that
> way.
>
> Also note that the traditional notion of "accounting system calls" is just
> _stupid_. It's the wrong abstraction level. Some system calls do many
> things (think "getxuid()"). Other system calls give direct user-space
> access to objects, so you can only see that you had access to the object,
> you can't actually see _what_ the user did anyway (think "mmap").
>
> You interpose on well-defined abstraction levels. Anything else is a waste
> of time, and useless. Why should you care if the user does a system call:
> sometimes the user can do the same thing by hand, and the system call is
> nothing but a convenience. The extreme case of this would be the whole
> TCP/IP stack: the user _could_ just open a raw packet socket and do its
> own TCP/IP stack totally in user mode. Or think about "gettimeofday()":
> it could be a system call on some architectures, and avaiable in user mode
> on others.
>
> And even when you have meaningful system calls like "write", why interpose
> on that. Nobody cares if you write to /dev/null, while if you write to
> /etc/passwd people might take a second look. You need to get in at the
> _meaningful_ level.
>
> And the system call interface is meaningless in itself. I suspect the only
> reason people focus on hooking into system calls is that it tends to be
> "easy", and a simpel specification - you can ask a summer intern to add
> the hook to monitor every system call. That doesn't make it meaningful.
>
> So add the hooks at the proper level - and make sure they really _are_
> necessary, because people start worrying about performance if you have too
> many function calls, even if they would default to being an immediate
> return in the common case. A cycle here and a cycle there adds up. I'm
> willing to add better security infrastructure, but that doesn't mean that
> I'd be willing to be stupid.
>
> (I know about accounting. And I disagree. What the HELL is the point in
> accounting how many system calls some process made? What does that tell
> you? It tells you _nothing_. Yet every single OS for some reason has hooks
> to accound system calls. That's STUPID.)
>
> Interesting objects to add security ID's to: processes, files, pathnames
> ("dentry" in Linux-speak), inodes (which includes a lot of different cases
> like sockets etc), routes, devices, etc. But _not_ system calls. You add
> the hooks to the actual places that look up (and especially modify) the
> data structures you've tagged.
>
> I'd be surprised if there are many more than 5-10 different object types
> you'd need to tag, and more than maybe 200 places where you'd need to
> intercept then. Total infrastrucure patch size should be on the order of a
> few thousand lines.
>
> (Remember: I'm not interested in the actual security _manager_, which may
> of course be arbitrarily complex in itself. The code _there_ to keep track
> of whatever security tags etc could be hairy and much bigger. But once it
> is encapsulated well enough, that part is no longer an issue from a system
> design perspective).
>
> Linus
--------------------------------------------------------------------------------
* LA Walsh ([email protected]) wrote:
> Maybe I'm delusional, but you are contradicting yourself. In
Re-read Linus' original spec with the following things in mind:
- we don't interpose at the system call level, rather the kernel object level
- we tag about 8 objects
- we have about 150 callbacks
- we don't move the capabilities bits from the task struct to the opaque id
- we allow active filtering
- we discourage generic policy composition
- we support models such as MLS, TE, DTE, RBAC, Capabilities, PBAC/TBAC
(whatver you want to call it), etc.
The fact that we don't support CAPP or LSPP standard compliant systems
which require MAC checks before DAC checks for _auditing_ is outside the
scope of this access control system.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
On Sun, Feb 09, 2003 at 07:40:17PM -0800, Crispin Cowan wrote:
> > Also unsupported: The "no-security" model -- where all security
> >is thrown out (to save memory space and cycles) that was desired for embedded work.
> >
> False: capabilities is now a removable module, which is what Linus asked
> for.
It's not. You put a bit of capability logic into a LSM module, but all
the specific calls to capable are still around and turned into an LSM hook -
often near another hook.
> >_\implemented\_ (team members & prjct lead Linda Walsh) to move all
> >security checks out of the kernel into a 'default policy' module.
> >The code to implement this was submitted to the LSM list in June 1991.
> >
> And I actually like that plan. But I still believe it to be too radical
> for 2.6.
It's too later for 2.6 _now_. If you started doing this in early 2.5
we'd have a much less messy ACC architecture by now.
> It has many nice properties, but is much more invasive to the
> kernel. I think it is a very interesting idea for 2.7, and should be
> floated past the maintainers who will be impacted to see if it has a
> hope in hell.
*nod* and until we get that gets implemented we should remove the current
mess..
'Christoph Hellwig' wrote:
>On Sun, Feb 09, 2003 at 07:40:17PM -0800, Crispin Cowan wrote:
>
>
>>[move security logic out to a module] It has many nice properties, but is much more invasive to the
>>kernel. I think it is a very interesting idea for 2.7, and should be
>>floated past the maintainers who will be impacted to see if it has a
>>hope in hell.
>>
>>
>*nod* and until we get that gets implemented we should remove the current
>mess..
>
Am I parsing this correctly, that we actually agree on something? :-)
I.e. that the idea of moving all the security logic to a module has merit.
Naturally, I disagree that we should remove the current LSM. The current
version was designed to be what Linus asked for. Many LSM people like
the idea of moving all the security logic out to a module, as it makes
the interface much cleaner. But it is also waaay beyond the scope of
what Linus asked for. It involves re-factoring so much code that we did
not think it could be done correctly on the first try, never mind trying
to get many code maintainers to accept much larger patches.
Crispin
--
Crispin Cowan, Ph.D.
Chief Scientist, WireX http://wirex.com/~crispin/
Security Hardened Linux Distribution: http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html
Just say ".Nyet"
On Mon, Feb 10, 2003 at 12:33:12AM -0800, Crispin Cowan wrote:
> Am I parsing this correctly, that we actually agree on something? :-)
> I.e. that the idea of moving all the security logic to a module has merit.
Yes. If we want so support security models more complicated than plain
UNIX DAC (an especially more than one of those) there's no way around
moving all access control out of the core kernel.
> Naturally, I disagree that we should remove the current LSM. The current
> version was designed to be what Linus asked for. Many LSM people like
> the idea of moving all the security logic out to a module, as it makes
> the interface much cleaner. But it is also waaay beyond the scope of
> what Linus asked for. It involves re-factoring so much code that we did
> not think it could be done correctly on the first try, never mind trying
> to get many code maintainers to accept much larger patches.
Well, usually adding changes to the core kernel in a proper way needs
major refactoring of code - the approach of adding a small, "non-invasive"
hack here and there leads to the typical mess seen in commercial operating
systems, and in Linux we've avoided that mostly so far.
As far keeping the current LSM hooks: I'm very unhappy with the design
of the, that's one point. The other point I'm extremly unhappy with
adding them without adding it's users. I'll shut up and be quite until
2.7 opens if you get a meaningfull LSM module merged that actually uses
those hooks. If you don't get one in by 2.6-test I will send patches
to remove those unused hooks.
On Mon, 2003-02-10 at 03:40, Crispin Cowan wrote:
> Because Linus asked for access control support, not audit logging
> support, it is not surprising that logging models don't fit so well.
The snare folks are moving bit by bit from their original hacks to
a clean audit hook model. That may give you the hooks you want for
auditing in 2.7. Thats seperate to the security stuff and you may
want one and not the other.
Christoph Hellwig wrote:
> Well, selinux is still far from a mergeable shape and even needed additional
> patches to the LSM tree last time I checked. This think of submitting hooks
> for code that obviously isn't even intende to be merged in mainline is what
> I really dislike, and it's the root for many problems with LSM.
It is true that SELinux is not yet in mergeable shape, but we do intend
to address those issues. With regard to additional patches, SELinux
has at times diverged slightly from the main LSM patch, but we do feed
back changes. At present, the only significant change in the
additional patch has to do with early initialization of SELinux so that
we can properly set up the security state of kernel objects when they
are created rather than needing to retroactively set up the state of
objects created before module initialization. That issue has come up
in general for security modules on the LSM list, and we would need to
submit a general solution for it along with the submission of SELinux
for mainline. Hence, you are correct that there is work to be done
before SELinux can be merged, but you are wrong to assume that we do
not intend to do that work or to submit SELinux.
> There has been a history in Linux to only implement what actually needed
> now instead of "clever" overdesigns that intend to look into the future,
> LSM is a gross voilation of that principle. Just look at the modules in
> the LSM source tree: the only full featured security policy in addition
> to the traditional Linux model is LSM, all the other stuff is just some
> additionl checks here and there.
I assume that you mean "SELinux" above. It is true that SELinux is the
dominant user of the LSM hooks at present. We would have been happy to
submit SELinux as a direct kernel patch rather than adding a further
level of indirection via LSM, but that wasn't the guidance we were
given.
> I'm very serious about submitting a patch to Linus to remove all hooks not
> used by any intree module once 2.6.0-test.
Any idea on how much time that gives us (to rework SELinux and submit
it)? Some of the necessary changes are simply engineering issues, but
others require further dialogue, e.g. getting the API into an
acceptable form, revisiting the approaches used to label and control
access to pseudo filesystems.
> Life would be a lot simpler if you got the core flask engine in a mergeable
> shapre earlier and we could have merged the hooks for actually using it
> incrementally during 2.5, discussing the pros and contras for each hook
> given an actual example - but the current way of adding extremly generic
> hooks (despite the naming they are in no ways tied to enforcing security
> models at all) without showing and discussing the code behind them simply
> makes that impossible.
We would have preferred this route as well, but again it wasn't the
guidance that we were given. We were told to work on something
LSM-like, then told to wait to initially submit it until after certain
other changes went into 2.5.
> So yes, my suggestion is to backout the whole LSM mess for 2.6, merge
> a sample policy core (i.e. a cleaned up flask/selinux) in 2.7.<early> and
> then add one hook after another and discussing the architecture openly
> where it belongs (here on lkml!).
Leaving 2.6 with no infrastructure for access control extensions at all?
Is this really preferable to keeping LSM in 2.5/2.6, and then migrating
to a more directly integrated architecture in 2.7?
--
Stephen Smalley, NSA
[email protected]
Crispin Cowan wrote:
>
> LA Walsh wrote:
>
> >>From: Crispin Cowan
> >>
> >>LSM does have a careful design.... meeting a
> >>goal stated by Linus nearly two years ago.
> >>
> >>
> > A security model that mediates access to security objects by
> >logging all access and blocking access if logging cannot continue is
> >unsupportable in any straight forward, efficient and/or non-kludgy, ugly
> >way.
> >
> Because Linus asked for access control support, not audit logging
> support, it is not surprising that logging models don't fit so well.
>
> > Some security people were banned from the kernel
> >devel. summit because their thoughts were deemed 'dangerous': fear was they
> >were too persuasive about ideas that were deemed 'ignorant' and would
> >fool those poor kernel lambs at the summit.
> >
> Internal SGI politics.
Just a gentle reminder that Ms. Walsh is not an SGI employee
and that any opinions she may express regarding the Linux
development process are her own, and may not reflect the
views or understandings of SGI or any other individuals
involved.
In particular, dragging SGI into this discussion is
inappropriate and unnecessary. SGI is currently not
active in this effort, and makes no claims regarding
it's appropriateness to any particular purpose.
Please leave SGI, in spirit and name, out of
this discussion.
--
Casey Schaufler Manager, Trust Technology, SGI
[email protected] voice: 650.933.1634
[email protected] Pager: 877.557.3184
Linda Walsh wrote:
> A security model that mediates access to security objects by
> logging all access and blocking access if logging cannot continue is
> unsupportable in any straight forward, efficient and/or non-kludgy, ugly
> way.
Could this possibly be a result of the above being a fundamentally
flawed security model? Not to mention it being primarily an auditing
model rather than a real access control model. It also seems a bit
problematic regardless of your kernel security framework; what does
"logging cannot continue" truly mean? Do you have to verify that the
log record made it to disk before you can proceed with the operation?
<insane ranting about evil conspiracies ignored>
> Also unsupported: The "no-security" model -- where all security
> is thrown out (to save memory space and cycles) that was desired for embedded
work.
The capabilities logic was moved into a module, and you have the option
of building a kernel with traditional superuser logic (dummy security
module) rather than capabilities. It is true that the capability bits
haven't yet been moved into the opaque security field, as explained in
the documentation, but this can be changed if desired (but there are
consequences to such a change; see the discussion in lsm.tmpl) . It is
also true that the capable() calls haven't been moved, but there is
little to be gained by it except possibly where there is a
corresponding LSM hook, and that is a straightforward refinement of the
existing LSM patch.
> LSM also doesn't support standard LSPP-B1 style graded security
> where mandatory access checks are logged as security violations before
> DAC checks are even looked at for an object.
An auditing issue, not an access control issue. As previously
discussed, there is no channel as long as both checks return the
same error (and doing otherwise is a compatibility problem).
> At one point a plan was proposed (by Casey Schaufler, SGI) and
> _\implemented\_ (team members & prjct lead Linda Walsh) to move all
> security checks out of the kernel into a 'default policy' module.
> The code to implement this was submitted to the LSM list in June 1991.
1991? I don't think so. But feel free to point people to your patch if
you like. Moving all of the DAC logic into a module is _not_ necessary
to add support for strong access controls. And modularizing that logic
has interesting implications; what happens to your applications when
you turn off the kernel DAC logic and replace it with something
arbitrary?
--
Stephen Smalley, NSA
[email protected]
> > Some security people were banned from the kernel
> >devel. summit because their thoughts were deemed
> 'dangerous': fear was they
> >were too persuasive about ideas that were deemed 'ignorant' and would
> >fool those poor kernel lambs at the summit.
> >
> Internal SGI politics.
---
Nope... external -- the conference organizer was the one selecting and specifically disallowing certain attendees. It
appeared important to weed out anyone who didn't think like him.
>
> > Also unsupported: The "no-security" model -- where all security
> >is thrown out (to save memory space and cycles) that was
> desired for embedded work.
> >
> False: capabilities is now a removable module, which is what
> Linus asked
> for.
---
FALSE? Are you telling us that you believe the only security in the kernel concerns capabilities? Most security people
would acknowledge that Discretionary Access Control (DAC) by user-id and privilege control via
the binary "(UID==0)" would qualify as a "security" model. Even the "Mandatory Access Control" bits, "immutable" and "append-only",
are a security model. Capabilities are an almost insignificant part of security compared to the code for DAC and UID==0 checks.
Your statement
is misdirecting like a response to a question about a car: "How does
it run? Reliability? Look at those tires! You won't see tires like
that anywhere!"
>
> > LSM also doesn't support standard LSPP-B1 style graded security
> >where mandatory access checks are logged as security
> violations before
> >DAC checks are even looked at for an object.
> >
> Because doing so would have required approx. 6-10X as many
> LSM hooks as
> the current LSM. Speak up if you think LSM should be 10X bigger to be
> able to support Common Criteria standards compliant audit logging ...
---
I don't have current figures, but in the 2.4.2 kernel from Apr, 01,
I noted that the LSM patch yielded 179 patches to 35 source files
in 68 different procedures of which 33 are system calls."
The 2.4.2 audit patch had about 130 different procedure's "hooked" with
maybe twice that many data collection calls depending on the route taken through the code. Additionally exit calls were required
for each
procedure (with exact number depending on how many different exit points
existed/procedure). This was before any work combining exit targets that often simplified code to 'unroll' state.
On IRIX, compiler pragmas like "execute_frequency_hint NEVER"
made sure that mainline cache wasn't harmed in the normal case and
required that even code computing audit masks was done 'out of line'.
On a P4, this could be similar to hinting to the processor what to
optimize it's pipeline for -- meaning virtually no execution impact when audit was compiled in but turned off because the pipeline
would already be started on the post branch code. But these intricacies are a matter of
compiler technology.
A pre-LSM version of audit existed and completely compiled out when not explicitly selected as a kernel build option. When
enabled, _FULL_ auditing of a kernel build on a 2PIIx400 machine measured about 10% overhead, typically, for the 2.4.[12] series
(single HD, ~3-5Mb/s record
rate). Compiled in but turned off, impact was *questionably* measurable (<.3%) and turned on but "no events" was still in noise
range (<1%) with typical monitoring sets being <3% overhead. This was with no specific performance tuning -- just SMP stress
testing.
> > At one point a plan was proposed (by Casey Schaufler, SGI) and
> >_\implemented\_ (team members & prjct lead Linda Walsh) to move all
> >security checks out of the kernel into a 'default policy' module.
> >The code to implement this was submitted to the LSM list in
> June [2001].
> >
> And I actually like that plan. But I still believe it to be
> too radical for 2.6.
---
The kernel was at version 2.4.[2-4]. At that time, 2.5 didn't even exist. Whether or not it would be too much for 2.6
wasn't even on the table. The code had been tested and was ready but rejected -- because,
you said, the "kernel developers" would never accept it. You proposed
a 2-stage process to Casey that lsm would first get it's head inside
the tent with hooks for the existing policies already in lsm, then
in the 2nd stage, you'd push for audit hooks. I felt that the 2nd stage
would be pushed off until some vague, nebulous date, too far in the future to be of any use to SGI. Casey disagreed and went
forward supporting you.
Over a year later, after going through contortions to get audit to work with
(in spite of?) lsm hooks by hooking all system calls (fulfilling Linus's stereotype of "stupid" designs) to get around lsm's
shortcomings, the
project was shelved. It had taken too long. As for performance? Even
questions, about performance, were declared "off-limits".
> It has many nice properties, but is much more
> invasive to the
> kernel.
---
"More invasive". Sorta like water is more invasive to our
bodies than Helium. Almost any security text will claim that security
has to be built in at the lowest levels -- even as far as designing it
in from the beginning to be successful. You would expect good security
to _not_ be integral to a secure kernel?
> I think it is a very interesting idea for 2.7, and should be
> floated past the maintainers who will be impacted to see if it has a
> hope in hell.
---
I tried to float it past several maintainers in July 01 after
multiple people on the lsm list said they wouldn't consider it without
"pre-buyin" of the "kernel developers". When I attempted to question
"them", a response to the question was reposted to the lkml. You
complained to Casey who removed me from the project to mollify you in
hopes you would make good on your promises to include audit in the vague,
nebulous, "too-late", stage 2.
You blew away a working implementation of a completely modular
security prototype because your first priority was to your specific
security policy -- not to what Linus had desired in having a "truly generic"
policy. This type of bias, along with the considerable weight given
to the needs of SELinux (then the "darling" of linux security -- before
it was pointed out that it used privately held patents that would likely prohibit any commercial use of the security model) only
highlights problems when corporate and commercial interests are placed ahead of good design.
-l
This
LA Walsh wrote:
>> > Some security people were banned from the kernel
>> >devel. summit because their thoughts were deemed
>> 'dangerous': fear was they
>> >were too persuasive about ideas that were deemed 'ignorant' and would
>> >fool those poor kernel lambs at the summit.
>
>> Internal SGI politics.
>
> Nope... external -- the conference organizer was the one selecting and
>specifically disallowing certain attendees. It
>appeared important to weed out anyone who didn't think like him.
I'm not sure that's relevant. We discussed these issues at length on
the LSM mailing list months ago. You had the opportunity (and took
it) to make the case for your proposal on the LSM mailing list, but in
the end, it was deemed not persuasive by most list members. The LSM
mailing list came to rough consensus on the right technical decision.
I know you didn't like the outcome of that decision, but there were good
technical reasons for the decisions we made. To say that you didn't
have a chance to present your ideas is a misrepresentation of the truth.
Part of distributed decision-making is conceding gracefully when the
consensus doesn't go your way. We've all had to do this from time
to time. In short, we've had this discussion already, and nothing has
changed since then.
On Sun, 9 Feb 2003, Crispin Cowan wrote:
> And I actually like that plan. But I still believe it to be too radical
> for 2.6. It has many nice properties, but is much more invasive to the
> kernel. I think it is a very interesting idea for 2.7, and should be
> floated past the maintainers who will be impacted to see if it has a
> hope in hell.
Too radical? After the modules rewrite how could anything short of a
rewrite in another language be too radical. At least a unified set of
security hooks would be a feature which would be immediately useful and
easy to understand. The benefits of the module changes are not as obvious.
With MS pushing their own security initiative, which seems to be building
computers which only run their os, this would have been a really good
feature from a mindshare perspective.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
> From: Stephen D. Smalley [mailto:[email protected]]
> Linda Walsh wrote:
> > A security model that mediates access to security objects by
> > logging all access and blocking access if logging cannot continue is
> > unsupportable in any straight forward, efficient and/or
> non-kludgy, ugly way.
>
> Could this possibly be a result of the above being a fundamentally
> flawed security model?
---
Perhaps you should discuss this with your employer, since it
was the DoD and NSA that came up with the policy.
> Not to mention it being primarily an auditing
> model rather than a real access control model. It also seems a bit
> problematic regardless of your kernel security framework; what does
> "logging cannot continue" truly mean?
---
For someone working in security, I'm surprised you aren't familiar
with the Controlled Access Protection Profile (CAPP). It's a superset of
the old DoD "Orange Book" "C2" standard.
The above policy, which you say isn't a "real access control model"
falls under the "Controlled Access" PP's definition of Access Control.
Are you saying the CAPP isn't "really" an Access Control specification for
an OS? It is onthe "Common Criteria's" OS list
(http://www.commoncriteria.org/ccc/protection_profiles/ppinfo.jsp?id=4&status=Certified).
Of course if 15-country recognition isn't enough, there's your employer's own Trusted Product page
(http://www.radium.ncsc.mil/tpep/).
The CAPP specifies detail used in evaluating whether or not one "truly"
meets the requirement. Maybe you can find someone around where
you work who is more familiar with CC security evaluations who can
give you more information.
> Do you have to verify that the
> log record made it to disk before you can proceed with the operation?
---
I'll refer you to section 5.1 of the above document. It describes
the required audit policies, one of which, includes the _option_ of
stopping the machine.
Is it fundamentally flawed security for a bank to have an ATM shut down if it can no longer log or record transactions?
> <insane ranting about evil conspiracies ignored>
---
<we don't like what she is saying...quick, call her a witch, a
heretic, lets portray her as, bwahaha, i-n-s-a-n-e!> "Evil?" I don't
recall that word. I'm fuzzy on the whole good-evil thing. Whattya mean 'evil?'
> > Also unsupported: The "no-security" model -- where all security
> > is thrown out (to save memory space and cycles) that was
> desired for embedded
> work.
>
> The capabilities logic was moved into a module, and you have
> the option
> of building a kernel with traditional superuser logic (dummy security
> module) rather than capabilities.
---
Geez...am I the only one who sees SuperUser and DAC as security
models? Maybe <eyes grow maniacally wild>, I really am i-n-s-a-n-e...
> An auditing issue, not an access control issue.
---
So you are asking us to believe, for example, that bank transaction
logs have nothing to do with bank or account security. That in no way do
such logs/records provide any sort of control on access? I disagree.
> As previously
> discussed, there is no channel as long as both checks return the
> same error (and doing otherwise is a compatibility problem).
---
No channel? Who's talking about channels? Did I mention channels?
Nep. I have my Intrusion Detection system set to go off only on
mandatory policy violations. I don't care about penny-ante DAC violations,
they are a dime a dozen, but attempts to override mandatory constraints?
That's suspicious on my machine. I'd like to know exactly what you
were trying to do when you attempted to open /usr/sbin for write.
> Moving all of the DAC logic into a module is _not_ necessary
> to add support for strong access controls.
---
Neither is electricity. Lock the computer in a vault, encase it
in 50 feet of concrete! *Way* secure. Oh...you want it to be
'usable'? Maybe we want to make the system a bit more accessible and
configurable?
> And modularizing that logic
> has interesting implications; what happens to your applications when
> you turn off the kernel DAC logic and replace it with something
> arbitrary?
---
You tell me. The idea is configurability: "truly generic". It
depends on what policy you define. I'm not about to guess
what would happen to "applications" (which? Random?) that _you_ put on
your own system that has a security policy that _you_ define.
On Mon, Feb 10, 2003 at 05:14:50PM -0500, Bill Davidsen wrote:
> Too radical? After the modules rewrite how could anything short of a
> rewrite in another language be too radical.
The modules rewrite highlighted a *lot* of bugs, which had nothing
to do with modules whatsoever. It was unfortunate for Rusty that his
work got merged the same time as a lot of other changes went in
which broke a lot of stuff (The cli/sti stuff springs to mind).
It also highlighted another bunch of bugs which were *real problems*
like using code marked __init after it was freed.
The "This doesn't compile, Rusty sucks" brigade then appeared,
not taking a second to realise that said driver was fscked regardless
of Rusty's code being merged.
Sure the modules rewrite wasn't painless, and like everything that
gets merged, there were bugs, but give the guy a break already.[1]
If there are still problems with modules, let Rusty know about it.
If not, please STFU already, its getting tiring hearing the same
old FUD.
Dave
[1] Or would you prefer he renamed the firewall tools again? (SRustyCNR)
--
| Dave Jones. http://www.codemonkey.org.uk
On Mon, Feb 10, 2003 at 11:55:41AM -0500, Stephen D. Smalley wrote:
>
> Christoph Hellwig wrote:
> > Well, selinux is still far from a mergeable shape and even needed additional
> > patches to the LSM tree last time I checked. This think of submitting hooks
> > for code that obviously isn't even intende to be merged in mainline is what
> > I really dislike, and it's the root for many problems with LSM.
>
> back changes. At present, the only significant change in the
> additional patch has to do with early initialization of SELinux so that
> we can properly set up the security state of kernel objects when they
> are created rather than needing to retroactively set up the state of
> objects created before module initialization.
And that for examples is a very important and needed change. Security
modules as loadable modules are a bad idea as you don't have a consistand
labelling state - just look at the older selinux versions with all the
precondition mess. But it should be generalized to a new initcall level
instead of the current explicit call to the selinux routine..
> > There has been a history in Linux to only implement what actually needed
> > now instead of "clever" overdesigns that intend to look into the future,
> > LSM is a gross voilation of that principle. Just look at the modules in
> > the LSM source tree: the only full featured security policy in addition
> > to the traditional Linux model is LSM, all the other stuff is just some
> > additionl checks here and there.
>
> I assume that you mean "SELinux" above.
Yes, sorry.
> It is true that SELinux is the
> dominant user of the LSM hooks at present. We would have been happy to
> submit SELinux as a direct kernel patch rather than adding a further
> level of indirection via LSM, but that wasn't the guidance we were
> given.
The problem is not really the indirection but the submission of the
indirection without it's users.
> > I'm very serious about submitting a patch to Linus to remove all hooks not
> > used by any intree module once 2.6.0-test.
>
> Any idea on how much time that gives us (to rework SELinux and submit
> it)?
Unfortunately I don't decide about the linux 2.6 freeze - ask Linus.
> Some of the necessary changes are simply engineering issues, but
> others require further dialogue, e.g. getting the API into an
> acceptable form, revisiting the approaches used to label and control
> access to pseudo filesystems.
+ moving to extended attributes instead of magic files for storing the
labels on filesystems
+ getting the patent issue sorted out
> Leaving 2.6 with no infrastructure for access control extensions at all?
> Is this really preferable to keeping LSM in 2.5/2.6, and then migrating
> to a more directly integrated architecture in 2.7?
Personally I prefer to not have infrastructure in over having broken
infrastructure. Looks at what the devfs mess caused in 2.4 and how much
was removed or is beeing removed/rewritten again in 2.5. Life would have
been a lot simpler if it never got in during 2.4. Similarly I don't see the
problem why the current lsm users can't keep using patches during 2.6.
Hi,
On Tue, 11 Feb 2003, Dave Jones wrote:
> > Too radical? After the modules rewrite how could anything short of a
> > rewrite in another language be too radical.
>
> The modules rewrite highlighted a *lot* of bugs, which had nothing
> to do with modules whatsoever. It was unfortunate for Rusty that his
> work got merged the same time as a lot of other changes went in
> which broke a lot of stuff (The cli/sti stuff springs to mind).
> It also highlighted another bunch of bugs which were *real problems*
> like using code marked __init after it was freed.
All this could have been done without a complete rewrite.
> The "This doesn't compile, Rusty sucks" brigade then appeared,
> not taking a second to realise that said driver was fscked regardless
> of Rusty's code being merged.
>
> Sure the modules rewrite wasn't painless, and like everything that
> gets merged, there were bugs, but give the guy a break already.[1]
> If there are still problems with modules, let Rusty know about it.
> If not, please STFU already, its getting tiring hearing the same
> old FUD.
Dave, it's really not that simple. Sure, there were bugs misattributed to
the modules rewrite, but these are usually easy to identify and can be
forwarded to the right culprit.
This leaves us with the real module problems and the biggest is an
unresponsive modules maintainer, when it comes to serious criticism. I'm
not the only one, whose questions are ignored. Rusty somehow assumes
nobody would understand his brilliant ideas (1), so we have to live
"executive summaries" (2). Sorry, but this is fucking arrogant and this
slowly really pisses me off.
The modules rewrite has some serious problems and so far I haven't found
an explaination, how they will be addressed. Feel free to flame me if the
solutions is so obvious that my little mind couldn't grasp it.
The biggest problem which doesn't let me look forward to 2.6 regarding
modules are the user visible changes - the new module tools. Why wasn't it
possible to update modutils? The new modprobe.conf is far less powerful
and I don't really want to know what tricks distributions will come up
with to keep modules.conf and modprobe.conf in sync.
request_module() is still broken, because modprobe/insmod does not
synchronise multiple calls. The module tools are still experimental at
best. I posted a patch to keep both tools working (no reaction of course).
I could go on with various other (serious) design problems, but I
mentioned most of them already in other mails, again without any reaction
from Rusty. I'd really like to know, why I'm not worth an answer anymore.
I'd really like to help, but ignoring me doesn't solve anything, I
wouldn't be that insistent, if I wouldn't see some real problems, I don't
do this just to annoy Rusty. Either these problems are real, then they
should be addressed somehow or I'm wrong, but then I'd like to know why
and I had no problem to admit mistakes. If there are multiple possible
solutions, we should at least consider all possible advantages/
disadvantages.
I'm really annoyed with this situation and if Rusty doesn't want to
cooperate, I slowly think it's the best solution to just revert the whole
mess and just port the few good things. The old module support isn't
perfect, but at least we know its problems and can address them one by
one.
bye, Roman
(1) http://marc.theaimsgroup.com/?l=linux-kernel&m=104440182324752&w=2
(2) http://marc.theaimsgroup.com/?l=linux-kernel&m=104261939523782&w=2
On Tue, 11 Feb 2003, Dave Jones wrote:
> On Mon, Feb 10, 2003 at 05:14:50PM -0500, Bill Davidsen wrote:
>
> > Too radical? After the modules rewrite how could anything short of a
> > rewrite in another language be too radical.
>
> The modules rewrite highlighted a *lot* of bugs, which had nothing
> to do with modules whatsoever. It was unfortunate for Rusty that his
> work got merged the same time as a lot of other changes went in
> which broke a lot of stuff (The cli/sti stuff springs to mind).
> It also highlighted another bunch of bugs which were *real problems*
> like using code marked __init after it was freed.
I think I see a knee-jerk reaction here. I commented on the magnitude and
pervasiveness of the change, not the way it was done. I could write an
essay about the way it was done, but that wasn't what I was talking about,
just the low impact of lsm vs. modules.
I also mentioned that lsm would be an understandable major new feature,
encouraging a variety of applications (as iptables did for firewall
generators and load balancers). The new module code only gives rise to
busywork porting drivers and utilities to the new way of doing that same
old same old. If there's some neat new useful capability with modules I
must have missed that post.
Yes, the idea that lsm is too radical to go into Linux does frost my ass,
and I'm not pretending it doesn't. But don't change the topic to "let's
not pick on Rusty," because I wasn't, at least in that post ;-)
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
> > > Some security people were banned from the kernel
> > >devel. summit because their thoughts were deemed
> 'dangerous': fear was they
> > >were too persuasive about ideas that were deemed
> 'ignorant' and would
> > >fool those poor kernel lambs at the summit.
> > >
> > Internal SGI politics.
---
Actually...the above incident had nothing (to my knowledge)
to do with SGI politics but with Linux 'community' politics. However,
politics and Machiavelli have never been my forte (I tend to be too
straightforward/open), so in agreement with Mr. Schaufler, below,
what would I know regarding such?
> Just a gentle reminder that Ms. Walsh is not an SGI employee
> and that any opinions she may express regarding the Linux
> development process are her own, and may not reflect the
> views or understandings of SGI or any other individuals
> involved.
In the same spirit, just a gentle reminder, Mr. Schaufler is a manager
at a commercial company that receives most of its revenue from IRIX
based machines. His group recently released CAPP and LSPP approved
versions (yeay!) of SGI's proprietary IRIX Operating System. Given
the proven success of Trusted IRIX in the security market, his views
and actions may not reflect the best interests of the Linux Security
Community or any of the individuals involved.
My interest is that of a software designer who has been too interested
in product quality, design and performance and has been chastened
because such issues don't bring in revenue and are not commercial company
goals. Anything effort above the "_minimum_ needed to get by" was often
considered insubordinate and recalcitrant. In a commercial company,
capitalistically motivated, this is true. Commercial giants in the
software world have demonstrated that quality issues rate well below
features and schedule.
> SGI is currently not
> active in this effort, and makes no claims regarding
> it's appropriateness to any particular purpose.
---
Exactly. :-)
-l
> From: David Wagner
> LA Walsh wrote:
> > Maybe I'm delusional, but you are contradicting yourself. In
> >common terms, this is called lying.
>
> No, he's not; even if he were, no, it's not. Can't we do
> without the personal attacks and just stick to technical topics?
---
I'm sorry if you feel it was a personal attack. It seemed
the appropriate noun for someone to whom this discrepancy in charter
has been pointed out to before and who worked to silence those
pointing out the discrepancy in public.
That cast it into the light of deliberate conflicting statements
which I used the common word "lie", but perhaps more politically
correct would have been to say that I was confused by the apparent
contradiction of the two statements.
One says 'simple'/'generic', the other says 'access checks only
as implemented as patches on top of the questionable and vague
policies that already exist. One deliberate design decision was to
make the hooks "non-authoritative" which makes the resulting
security policies as clean and easy to read as mud. It also made
writing a clean/simple security policy impossible, with "kludges"
suggested like "well just always override DAC checks with priviledges"
and then do the real checks in the 'restrictive-only' LSM calls.
Please explain to me how this is simple or generic.
It's completely inappropriate for a security structure where
increased complexity yields increased failure and lower ability
to prove (confidence).
> > Security isn't just an afterthought you can patch on and cross
> >your fingers and hope it won't break. It has to be designed in.
>
> People keep telling you that LSM does have a careful design for
> security. I suspect what you really mean is that you don't like
> the design we chose -- but that's different.
---
Please read what I said carefully. I didn't say that the
"patched on security" wasn't carefully designed. I made no claims
about how carefully it was designed. Carefulness of design avails
you not, if the design isn't appropriate for the problem space.
-l
Alan Cox wrote:
> On Thu, 2003-02-06 at 15:18, Christoph Hellwig wrote:
> > Life would be a lot simpler if you got the core flask engine in a
mergeable
> > shapre earlier and we could have merged the hooks for actually using it
> > incrementally during 2.5, discussing the pros and contras for each hook
>
> I'm not sure we can until the flask engine patent problems with secure
> computing are completely resolved and understood.
Despite recent speculation concerning patents, we remain confident that
we had the necessary rights to release SELinux in the manner and under
the conditions in which we did and that SELinux may be used, copied,
distributed, and modified in accordance with the terms and conditions of
the GPL.
--
Peter Loscocco
SELinux Project Leader
National Security Agency
> > > I'm very serious about submitting a patch to Linus to
> remove all hooks not
> > > used by any intree module once 2.6.0-test.
> >
> > Any idea on how much time that gives us (to rework SELinux
> and submit
> > it)?
>
Hi,
My comments are from user of LSM point of view and not one of its designers. Actually, we have been using LSM for now about a year to develop our own security module in DSI project (security for clustered server, http://sourceforge.net/projects/disec).
I believe that one major advantage of LSM is that it avoids the one size fits all approach. LSM allows to different people to come up with different mechanisms to implement security according to their needs.
And different Linux users have different needs. For example in DSI project, we used LSM to implement our own security approach for clustered servers. For example, having tight restrictions on response time, we rather concentrate on performance impact of security and distributed access control inside a cluster than file access control (running mainly diskless machines).
I believe this is very acceptable, because it allows the user to choose the security module that fits best its needs. The security needs are not the same for military/banking/telecom/gaming/... businesses. And till the moment that we have a config tool (file or else) that can allow these people to configure fine grained access control according to their needs (for example like how we configure iptables), I believe that LSM is necessary to give these people a chance of developing their own solution.
Further more, I believe that LSM encourages the developers in the community to take initiatives related to security in Linux. This way, it helps developing different security approaches. This at the end, even if we choose to go with only one approach and drop others, will help the diversity of existing solutions and the possibility of choosing among a set of solutions (hopefully the best one will be chosen). IMHO, to let people be able to come up with different security approaches, we have
to let LSM be part of the kernel in order to encourage people to
develop their approach.
That was my 2 cents.
Regards,
Makan Pourzandi
-------------------------------------------------------
Makan Pourzandi
Ericsson Research Canada
http://sourceforge.net/projects/disec/
-------------------------------------------------------
This email does not represent or express the opinions of Ericsson
Corporation.
"Makan Pourzandi (LMC)" a ?crit :
> > > > I'm very serious about submitting a patch to Linus to
> > remove all hooks not
> > > > used by any intree module once 2.6.0-test.
> > >
> > > Any idea on how much time that gives us (to rework SELinux
> > and submit
> > > it)?
> >
>
> Further more, I believe that LSM encourages the developers in the community to take initiatives related to security in Linux. This way, it helps developing different security approaches. This at the end, even if we choose to go with only one approach and drop others, will help the diversity of existing solutions and the possibility of choosing among a set of solutions (hopefully the best one will be chosen). IMHO, to let people be able to come up with different security approaches, we have
> to let LSM be part of the kernel in order to encourage people to
> develop their approach.
>
> That was my 2 cents.
>
> Regards,
> Makan Pourzandi
Hi,
I'm the leader of a project, developping a sandbox (processes confinement environment) for Linux based on LSM.
Our approach is dedicated for peer-to-peer global computing environments. I totally agree with Makan about the
diversity of developpement : we dont have the same goals than SELinux. The LSM project followed two phases :
in a first one, everybody was thinking about what could be good to integrate in LSM and now (the second phase),
a few people think about what they can remove because they dont use it. We need a flexible and reasonably complete
framework to implement solutions. I recall that it was the original request from Linus : a generic framework to decide
which kind of security solutions are the best. If LSM fits only one or two policy requirements, the choice does not
exist. For finishing : PLEASE, stop reducing LSM possibilities : it cost a lot to develop things for a hook and then
redevelopping it for a classical syscall interposition.
bests
Fr?d?ric Magniette (University of Orsay/CNRS)
[argg, any chance you two could get RFC-complaint mailers?]
On Wed, Feb 12, 2003 at 07:11:09PM +0000, magniett wrote:
> exist. For finishing : PLEASE, stop reducing LSM possibilities : it cost a lot to develop things for a hook and then
> redevelopping it for a classical syscall interposition.
There's no one taking away the LSM patches. Anyway life would be a lot
simpler if you actually announced the stuff you do on lkml instead of hiding
behind the moon. The only chance hook you need will stay is that you
discuss them publically here.
Where's the pointer to your code?
do you have any technical argument on the current implementation of
security hooks? the whole discussion is on removing the current mess
until a proper design can be implemented.
'Christoph Hellwig' wrote:
>[argg, any chance you two could get RFC-complaint mailers?]
>
>On Wed, Feb 12, 2003 at 07:11:09PM +0000, magniett wrote:
>
>
>>exist. For finishing : PLEASE, stop reducing LSM possibilities : it cost a lot to develop things for a hook and then
>>redevelopping it for a classical syscall interposition.
>>
>>
>There's no one taking away the LSM patches. Anyway life would be a lot
>simpler if you actually announced the stuff you do on lkml instead of hiding
>behind the moon. The only chance hook you need will stay is that you
>discuss them publically here.
>
For the second time in a week, I agree with HCH: If you are developing
an LSM module, then by all means please make it publicly known. Whether
we host your source or not, we want to at least link to your site from
http://lsm.immunix.org/lsm_modules.html
WRT "taking away LSM patches": HCH wants to remove hooks that "no one
uses" and also complains about LSM being a big ugly undesigned hack
lacking abstraction. LSM does have an abstract design: it mediates
access to major internal kernel objects (processes, inodes, etc.) by
user-space processes, throwing access requests out to the LSM module. If
you remove some of these hooks because they don't have a *present*
module using them, then you break the abstraction.
People tell me that preserving functionality for the sake of abstraction
is "not the Linux way". Ok, sure, but you degrade the quality of
abstraction if you aggressively prune the interface.
But it would be much better to short-circuit that debate, and have
extant modules that use the hooks than to try to defend them on the
basis of abstraction. So if your sekrit module uses a hook, post here,
or your hook may go away.
Crispin
--
Crispin Cowan, Ph.D.
Chief Scientist, WireX http://wirex.com/~crispin/
Security Hardened Linux Distribution: http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html
Just say ".Nyet"
On Wed, Feb 12, 2003 at 02:22:34PM -0800, Crispin Cowan wrote:
> WRT "taking away LSM patches": HCH wants to remove hooks that "no one
> uses" and also complains about LSM being a big ugly undesigned hack
> lacking abstraction.
> LSM does have an abstract design: it mediates
> access to major internal kernel objects (processes, inodes, etc.) by
> user-space processes, throwing access requests out to the LSM module.
We seem to use the term design differently. And maybe my english
wording wasn't perfect (I'm no native speaker..). My objection is that
LSM by itself does not enforce the tightest bit of security policy
design. Your "design" is putting in hooks before object accesses
without making them tied to enforcing some security policy.
Now I hear people scream "but we want $BIGNUM totally different security
policies", but that;'s not what I want to take away. Look at the Linux
VFS, it enforces quite a lot of stuff, and still we have tons of entirely
different filesystems. Of course that could also have worked by putting
a function vector directly below the syscall level, similar to say the SVR3
filesystem switch. But that means a) we duplicate tons of code because
filesystems are filesystem and there's stuff they will have to duplicate
anyway. and b) there's stuff we just can't handle that way properly.
(see the cross-directory rename issue still present in most non-linux
unices).
Now getting a LSM-replacement in place that is as well-designed,
feature-rich and still rather slick as the Linux VFS won't happen
over night. But if you see how we got that code is that we had
example filesystems that showed would should go into common code.
That's one of the reason why I think merging LSM-like hooks without
examples (three or four general purpose policies best) doesn't make
much sense. We need to see what we can abstract out and how.
And here we see _the_ problem with the LSM process. LSM wasn't
developed as part of the broad kernel community (lkml) but on
a rather small, almost private list. People added hooks not because
they generally make sense but because their module needed it.
When reading this thread some people (e.g. David [*]) still seem that
changes should be done for LSM's sake - but that's entirely wrong.
The point of getting LSM or something similar in is for the sake
of the _linux_ _kernel_ getting usefull features, not for enabling
some small community writing out of tree modules.
> If
> you remove some of these hooks because they don't have a *present*
> module using them, then you break the abstraction.
An abstraction that isn't used is worthless.
Christoph
[*] and btw, question in mails sent to a list I'm not subscribed to in
reply to mails from me won't get answered, sorry.
On Wednesday 12 February 2003 05:05 pm, 'Christoph Hellwig' wrote:
> On Wed, Feb 12, 2003 at 02:22:34PM -0800, Crispin Cowan wrote:
> > WRT "taking away LSM patches": HCH wants to remove hooks that "no one
> > uses" and also complains about LSM being a big ugly undesigned hack
> > lacking abstraction.
> >
> > LSM does have an abstract design: it mediates
> > access to major internal kernel objects (processes, inodes, etc.) by
> > user-space processes, throwing access requests out to the LSM module.
>
> We seem to use the term design differently. And maybe my english
> wording wasn't perfect (I'm no native speaker..). My objection is that
> LSM by itself does not enforce the tightest bit of security policy
> design. Your "design" is putting in hooks before object accesses
> without making them tied to enforcing some security policy.
>
> Now I hear people scream "but we want $BIGNUM totally different security
> policies", but that;'s not what I want to take away. Look at the Linux
> VFS, it enforces quite a lot of stuff, and still we have tons of entirely
> different filesystems. Of course that could also have worked by putting
> a function vector directly below the syscall level, similar to say the SVR3
> filesystem switch. But that means a) we duplicate tons of code because
> filesystems are filesystem and there's stuff they will have to duplicate
> anyway. and b) there's stuff we just can't handle that way properly.
> (see the cross-directory rename issue still present in most non-linux
> unices).
>
> Now getting a LSM-replacement in place that is as well-designed,
> feature-rich and still rather slick as the Linux VFS won't happen
> over night. But if you see how we got that code is that we had
> example filesystems that showed would should go into common code.
Actually - one of the requirements was to be able to REMOVE all hooks to
create a system with NO added overhead. The VFS does add overhead, but the
flexibility dictated that it be accepted.
> That's one of the reason why I think merging LSM-like hooks without
> examples (three or four general purpose policies best) doesn't make
> much sense. We need to see what we can abstract out and how.
>
> And here we see _the_ problem with the LSM process. LSM wasn't
> developed as part of the broad kernel community (lkml) but on
> a rather small, almost private list. People added hooks not because
> they generally make sense but because their module needed it.
> When reading this thread some people (e.g. David [*]) still seem that
> changes should be done for LSM's sake - but that's entirely wrong.
> The point of getting LSM or something similar in is for the sake
> of the _linux_ _kernel_ getting usefull features, not for enabling
> some small community writing out of tree modules.
That wasn't true either - as I recall, the group that started working on LSM
was strongly suggested to take it off the list until "show me the code" could
be done.
> > If
> > you remove some of these hooks because they don't have a *present*
> > module using them, then you break the abstraction.
>
> An abstraction that isn't used is worthless.
Ummmm. Not all of the SCSI options are used either. Does that make the SCSI
layer worthless?
--
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
On Wed, 12 Feb 2003, 'Christoph Hellwig' wrote:
> And here we see _the_ problem with the LSM process. LSM wasn't
> developed as part of the broad kernel community (lkml) but on
> a rather small, almost private list.
Many of the things that you are saying in this discussion are untrue.
The bulk of the development process was carried out for more than two
years on the LSM development mailing list, which is fully public and open
to anyone. It is not "almost private", whatever that is supposed to mean.
Should those thousands of emails have ended up on lkml instead? Before
you answer, try reading the first thousand (which I actually did when
joining the project).
As for "rather small", hundreds of people were involved in discussion
during the initial development phase (Chris Wright generated some stats on
this last year). These people included numerous long time kernel
developers, commercial developers, well known security researchers and
anyone else who was interested enough to join.
There were specific LSM discussions at two kernel summits, while multiple
OLS presentations have been given on LSM. These events were further
covered by numerous online media sites. LSM information was posted
several times to lkml, before and after the initial codebase was
developed. If you didn't notice any of these things before you started
complaining recently, please don't blame the LSM developers.
I do agree that we should have worked more closely with maintainers from
the beginning, but this was not out of trying to be secretive (of which we
have been accused quite a few times). This happened out of believing that
we should reach a design consensus and write some code via the before
bothering any maintainers. This approach was clearly flawed, and efforts
have since been made to rectify this for ongoing development.
(Note that this process occured publicly on the LSM development mailing
list, and that code was checked in as it was developed to publicly
accessible bk repositories).
And I also agree that it would have been better if more people in general
discussed LSM on lkml. For whatever reason, they did not. I can point
you to many instances of LSM posts being made to lkml with zero response.
The first LSM patch sent to lkml was actually applied by Linus with no
discussion from anyone else, _very_ much to our surprise. We definitely
expected significant discussion from lkml subscribers and a highly
probable subsequent phase of rework before it would be accepted into
mainline.
> People added hooks not because they generally make sense but because
> their module needed it.
SELinux was used as a model for LSM because SELinux is _itself_ a
generalized access control framework (arising from over a decade of
research). SELinux already supported MAC, TE, RBAC, IBAC and MLS, and was
one of the few existing Linux security projects with significant coverage
across the kernel. Thus, it was an ideal basis for use as a model for the
initial design of the LSM hook placement and abstraction strategy. Many
other projects were used as models as well. In fact, I reviewed in detail
_every_ single Linux security project I could find when implementing the
networking hooks.
Claims of a "secret" and non-generalized design process are baseless.
- James
--
James Morris
<[email protected]>
'Christoph Hellwig' wrote:
> And here we see _the_ problem with the LSM process.
I personally don't agree with the subject line,
as I don't believe that anything "went wrong" with
LSM. True, it's not what I want, but then my contribution
wasn't what it needed to be to make it such, either.
I often disagreed with the directions, and was sometimes
surprised, but that kind of thing happens in a large
group environment. My sage wisdom was considered
more often than not, even if it was discarded unused
from time to time.
I've been retrofitting security policy into U2X systems
since the 1980's, first Orange Book and now Common
Criteria, and it's HARD. LSM is a fine first whack.
No one should dispair that it fails to meet a particular
need exactly, or that those meany maintainers won't
accept your hook without seeing the code that uses it.
Alan Cox described the Linux development process as
climbing over a fence with everyones hands in each others
pockets, and I think that describes LSM pretty well.
Advanced security features are unpopular, and
all evidience points to them remaining so. We, as
a development community, have yet to convince the
great insecure masses that they want to see audit
trails, user clearances, and time of day controls
in "their" kernels. Heck, we have yet to convince
each other! But buck up, I fully expect we'll do
better next round, and better the time after that,
as well.
LSM isn't finished because Linux isn't finished
and as a group we security developers are a
tenacious (stubborn? pig headed maybe?) lot.
--
Casey Schaufler Manager, Trust Technology, SGI
[email protected] voice: 650.933.1634
[email protected] Pager: 877.557.3184
>> There's no one taking away the LSM patches. Anyway life would be a
>> lot simpler if you actually announced the stuff you do on lkml
>> instead of hiding behind the moon. The only chance hook you need
>> will stay is that you discuss them publically here.
>
> For the second time in a week, I agree with HCH: If you are developing
> an LSM module, then by all means please make it publicly known.
> Whether we host your source or not, we want to at least link to your
> site from http://lsm.immunix.org/lsm_modules.html
Ericsson's project is called DSI (http://www.risq.ericsson.ca/dsi/), and
the code is at SourceForge: http://sourceforge.net/projects/disec/.
CGL v2 specs will incorporate some parts of DSI, but not the whole.
--MiKu
James Morris wrote:
>On Wed, 12 Feb 2003, 'Christoph Hellwig' wrote:
>
>>And here we see _the_ problem with the LSM process. LSM wasn't
>>developed as part of the broad kernel community (lkml) but on
>>a rather small, almost private list.
>>
>>
>Many of the things that you are saying in this discussion are untrue.
>
>The bulk of the development process was carried out for more than two
>years on the LSM development mailing list, which is fully public and open
>to anyone. It is not "almost private", whatever that is supposed to mean.
>
For the record:
* The LSM code patches have always been publicly available for
anonymous checkout via BK from http://lsm.immunix.org/
* The LSM mailing list is managed by Mailman and is open for anyone
to subscribe
<http://mail.wirex.com/mailman/listinfo/linux-security-module>,
unsubscribe, or view the archives
<http://mail.wirex.com/pipermail/linux-security-module/>.
* The LSM mailing list is also independently archived elsewhere
<http://marc.theaimsgroup.com/?l=linux-security-module&r=1&w=2>.
* For the first year or so, the LSM mailing list was "closed" in
that posts from non-subscribers were trapped for moderation. I
always approved such posts if they were topical, and used the
moderation only to filter spam.
* Subsequent to that, I was told that this is "not the linux way"
and the mailing list was made "open" so that anyone can post, and
Spamassassin was installed to filter spam (which doesn't quite
work perfectly
<http://mail.wirex.com/pipermail/linux-security-module/2002-October:/3658.html>).
It has never, ever been "private" any more than any of the other
subsystem -devel lists are "private."
>As for "rather small", hundreds of people were involved in discussion
>during the initial development phase (Chris Wright generated some stats on
>this last year).
>
A few days after I opened the list, it had 300 subscribers. Today it has
607 subscribers. There have been 4183 posts.
>There were specific LSM discussions at two kernel summits, while multiple
>OLS presentations have been given on LSM.
>
To me, the most gratifying result to come out of OLS 2002
<http://www.linuxsymposium.org/2002/> (apart from Linus accepting the
first patch :-) was the Ericsson project
<http://www.linuxsymposium.org/2002/view_txt.php?text=abstract&talk=44>.
What makes this project so impressive is that AFAIK Ericsson never asked
the LSM mailing list a single question. They just took the documents and
the code, and implemented their module. To me, *that* is evidence that
the abstraction is usable: that an independent 3rd party can code to it
without help.
>I do agree that we should have worked more closely with maintainers from
>the beginning, but this was not out of trying to be secretive (of which we
>have been accused quite a few times). This happened out of believing that
>we should reach a design consensus and write some code via the before
>bothering any maintainers. This approach was clearly flawed, and efforts
>have since been made to rectify this for ongoing development.
>
And in fact we did seek input from Theodore Ts'o in the summer of 2001.
Most of that guidance was verbal, and it happened 18 months ago, so my
memory is imperfect, but I think he advised us to keep the invasiveness
minimal, and to avoid adding features that were just there to support
audit. Others at that lunch were Chris Wright (WireX) and Pete Loscocco
(SELinux).
What I've learned from the LSM merge process is that we need to get
piecewise buy-in from each major subsystem maintainer that will be
impacted. For instance, the network hooks did not go in as smoothly as
we would have liked. Thanks to hard work from James Morris and helpful
feedback from David Miller, they did go in after substantial revisions.
Next time, we will float a paper design past subsystem maintainers ahead
of time.
>Claims of a "secret" and non-generalized design process are baseless.
>
Here here.
Crispin
--
Crispin Cowan, Ph.D.
Chief Scientist, WireX http://wirex.com/~crispin/
Recruiting for Linux kernel and glibc developers: http://immunix.org/jobs.html
'Christoph Hellwig' wrote:
>On Wed, Feb 12, 2003 at 02:22:34PM -0800, Crispin Cowan wrote:
>
>>LSM does have an abstract design: it mediates
>>access to major internal kernel objects (processes, inodes, etc.) by
>>user-space processes, throwing access requests out to the LSM module.
>>
>>
>We seem to use the term design differently. And maybe my english
>wording wasn't perfect (I'm no native speaker..). My objection is that
>LSM by itself does not enforce the tightest bit of security policy
>design. Your "design" is putting in hooks before object accesses
>without making them tied to enforcing some security policy.
>
You're right, we're using English differently :-) I don't know what the
above paragraph means. I can guess, but that's where the trouble is
coming from. Based on the guessing:
* Yes, LSM by itself does not enforce security policy.
* Yes, the desing is to put hooks in front of important objects, and
ask the modules if that access is ok.
The effect of this is to push security policy out to the modules. This
is what Linus asked for, so that he would not have to maintain security
policy or security policy engines.
>When reading this thread some people (e.g. David [*]) still seem that
>changes should be done for LSM's sake - but that's entirely wrong.
>The point of getting LSM or something similar in is for the sake
>of the _linux_ _kernel_ getting usefull features, not for enabling
>some small community writing out of tree modules.
>
You have often made this point about "for the Linux kernel's sake" vs.
some other motivation, and it bothers me. It suggests that you somehow
care about the Linux kernel more than I do. No, I care about the Linux
kernel a lot. More over, I don't see how "who cares about the kernel
more" is pertinent.
That aside, the Linux kernel per se is not some entity to be pleased
like a stone god. Linux exists for its users. LSM is designed to benefit
Linux kernel users. Some benefit by being able to add security features
that they could not get before, because they are not capable of patching
their own kernels. Some benefit by being able to produce experimental
security modules without having to patch & track the Linux kernel. Some
benefit by being able to unload security stuff and go for a leaner
configuration.
LSM is not about pleasing a small number of module vendors. It is about
benefiting a large number of potential users.
Crispin
--
Crispin Cowan, Ph.D.
Chief Scientist, WireX http://wirex.com/~crispin/
Security Hardened Linux Distribution: http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html
Just say ".Nyet"
Pete Zaitcev wrote:
>I used to be super irritated by separate lists. Now I'm a member
>of linux-usb-devel, uml-devel, sparclinux, and god knows what else.
>Yes, they are unavoidable. Still, it is important to keep linux-kernel
>at least somewhat informed. IMHO.
>
LKML was kept at least somewhat informed, IMHO:
* LSM announced April 11, 2001
<http://marc.theaimsgroup.com/?l=linux-kernel&m=98695004126478&w=4>
* Should there be separate lists for module development?
<http://marc.theaimsgroup.com/?l=linux-kernel&m=98695659813419&w=4>
o Probably
<http://marc.theaimsgroup.com/?l=linux-kernel&m=98701977623500&w=4>
* Discussion of the "DAC-out" design option appears in LKML July 12,
2001
<http://marc.theaimsgroup.com/?l=linux-kernel&m=99497020101496&w=4>
* LSM entangled in discussion of whether binary-only modules should
be permitted, September 24, 2001
<http://marc.theaimsgroup.com/?l=linux-kernel&m=100134989121896&w=4>
* Syscall 223 provisionally reserved for LSM
<http://marc.theaimsgroup.com/?l=linux-kernel&m=100255709403906&w=4>
* LSM mentioned as related to extended attributes project
<http://marc.theaimsgroup.com/?l=linux-kernel&m=100509197600341&w=4>
* Does LSM conflict with accessfs? January 16, 2002
<http://marc.theaimsgroup.com/?l=linux-kernel&m=101120760212957&w=4>
o No, it does not
<http://marc.theaimsgroup.com/?l=linux-kernel&m=101138310816232&w=4>
* LSM in Guillaume's big list of 2.5 stuff, January 23, 2002
<http://marc.theaimsgroup.com/?l=linux-kernel&m=101176727007672&w=4>
* LSM in Marc-Christian Petersen's forked kernel, May 21, 2002
<http://marc.theaimsgroup.com/?l=linux-kernel&m=102201919806027&w=4>
* LSM interfacing to extended attributes, June 28, 2002
<http://marc.theaimsgroup.com/?l=linux-kernel&m=102527059400830&w=4>
* First LSM patch into Linus' tree, July 16, 2002
<http://marc.theaimsgroup.com/?l=linux-kernel&m=102677797911383&w=4>
o There are lots of these subsequently, so I won't cite them all
* Racing with module load/unload affects LSM too, September 12, 2002
<http://marc.theaimsgroup.com/?l=linux-kernel&m=103181033207587&w=4>
* HCH takes issue with LSM, September 26, 2002
<http://marc.theaimsgroup.com/?l=linux-kernel&m=103307580006067&w=4>
* LSM hook style changes from low-cost hooks to no-cost configurable
hooks, October 16, 2002
<http://marc.theaimsgroup.com/?l=linux-kernel&m=103472694817532&w=4>
* LSM and GPL requirement for modules, October 17, 2002
<http://marc.theaimsgroup.com/?l=linux-kernel&m=103486544115996&w=4>
* Remove the LSM sys_security call, October 17, 2002
<http://marc.theaimsgroup.com/?l=linux-kernel&m=103488104604175&w=4>
* LSM changed so that module does not have to provision every hook
by providing a default action, December 1, 2002
<http://marc.theaimsgroup.com/?l=linux-kernel&m=103872797618899&w=4>
* The start of this flame-war, February 5, 2002
<http://marc.theaimsgroup.com/?l=linux-kernel&m=104441899708408&w=4>
Crispin
--
Crispin Cowan, Ph.D.
Chief Scientist, WireX http://wirex.com/~crispin/
Recruiting for Linux kernel and glibc developers: http://immunix.org/jobs.html
* Christoph Hellwig ([email protected]) wrote:
>
> And that for examples is a very important and needed change. Security
> modules as loadable modules are a bad idea as you don't have a consistand
> labelling state - just look at the older selinux versions with all the
> precondition mess. But it should be generalized to a new initcall level
> instead of the current explicit call to the selinux routine..
I wrote such a patch last summer. I'll rebase it to current and post it
(most likely when i return from .se). It needs to be separte from
normal initcalls since they all happen too late.
-chris