I've been auditing the LSM stuff a bit more..
They have registered an implemented a syscall, sys_security
that does nothing but switch into the individual modules
based on the first argument, i.e. it's ioctl() switching
on the security module instead of device node. Yuck.
Patch below removes it (no intree users), maybe selinux/etc
folks should send their actual syscall for review instead..
--- 1.1/Documentation/DocBook/lsm.tmpl Tue Oct 8 23:48:29 2002
+++ edited/Documentation/DocBook/lsm.tmpl Thu Oct 17 20:40:19 2002
@@ -203,29 +203,6 @@
permission when accessing an inode.
</para>
-<para>
-LSM adds a general <function>security</function> system call that
-simply invokes the <function>sys_security</function> hook. This
-system call and hook permits security modules to implement new system
-calls for security-aware applications. The interface is similar to
-socketcall, but also has an <parameter>id</parameter> to help identify
-the security module whose call is being invoked.
-To eliminate the need for a central registry of ids,
-the recommended convention for creating the hexadecimal id value is:
-<programlisting>
-<![CDATA[
- echo "Name_of_module" | md5sum | cut -c -8
-]]>
-</programlisting>
-C code will need to prefix this result with ``0x''.
-For example, the id for ``SGI Trusted Linux'' could be used in C as:
-<programlisting>
-<![CDATA[
- #define SYS_SECURITY_MODID 0xc4c7be22
-]]>
-</programlisting>
-</para>
-
</sect1>
<sect1 id="cap"><title>LSM Capabilities Module</title>
--- 1.2/arch/alpha/kernel/systbls.S Tue Oct 15 15:12:07 2002
+++ edited/arch/alpha/kernel/systbls.S Thu Oct 17 20:27:19 2002
@@ -398,7 +398,7 @@
.quad sys_getdents64
.quad sys_gettid
.quad sys_readahead
- .quad sys_ni_syscall /* 380, sys_security */
+ .quad sys_ni_syscall /* 380 */
.quad sys_tkill
.quad sys_setxattr
.quad sys_lsetxattr
--- 1.7/arch/arm/kernel/calls.S Tue Jul 30 00:08:08 2002
+++ edited/arch/arm/kernel/calls.S Thu Oct 17 20:23:02 2002
@@ -237,7 +237,7 @@
/* 220 */ .long sys_madvise
.long sys_fcntl64
.long sys_ni_syscall /* TUX */
- .long sys_security
+ .long sys_ni_syscall
.long sys_gettid
/* 225 */ .long sys_readahead
.long sys_setxattr
--- 1.38/arch/i386/kernel/entry.S Tue Oct 15 23:45:51 2002
+++ edited/arch/i386/kernel/entry.S Thu Oct 17 20:23:47 2002
@@ -706,7 +706,7 @@
.long sys_getdents64 /* 220 */
.long sys_fcntl64
.long sys_ni_syscall /* reserved for TUX */
- .long sys_security /* reserved for Security */
+ .long sys_ni_syscall
.long sys_gettid
.long sys_readahead /* 225 */
.long sys_setxattr
--- 1.21/arch/ia64/kernel/entry.S Wed Sep 18 08:22:09 2002
+++ edited/arch/ia64/kernel/entry.S Thu Oct 17 20:23:54 2002
@@ -1241,7 +1241,7 @@
data8 sys_futex // 1230
data8 sys_sched_setaffinity
data8 sys_sched_getaffinity
- data8 sys_security
+ data8 sys_ni_syscall
data8 sys_alloc_hugepages
data8 sys_free_hugepages // 1235
data8 sys_exit_group
--- 1.28/arch/ppc/kernel/misc.S Mon Oct 7 09:26:07 2002
+++ edited/arch/ppc/kernel/misc.S Thu Oct 17 20:25:12 2002
@@ -1293,7 +1293,7 @@
.long sys_futex
.long sys_sched_setaffinity
.long sys_sched_getaffinity
- .long sys_security
+ .long sys_ni_syscall
.long sys_ni_syscall /* 225 - reserved for Tux */
.long sys_sendfile64
.long sys_io_setup
--- 1.28/arch/ppc64/kernel/misc.S Fri Oct 11 09:09:17 2002
+++ edited/arch/ppc64/kernel/misc.S Thu Oct 17 20:25:33 2002
@@ -729,7 +729,7 @@
.llong .sys_futex
.llong .sys32_sched_setaffinity
.llong .sys32_sched_getaffinity
- .llong .sys_security
+ .llong .sys_ni_syscall
.llong .sys_ni_syscall /* 225 - reserved for tux */
.llong .sys32_sendfile64
.llong .sys_ni_syscall /* reserved for sys_io_setup */
@@ -972,7 +972,7 @@
.llong .sys_futex
.llong .sys_sched_setaffinity
.llong .sys_sched_getaffinity
- .llong .sys_security
+ .llong .sys_ni_syscall
.llong .sys_ni_syscall /* 225 - reserved for tux */
.llong .sys_ni_syscall /* 32bit only sendfile64 */
.llong .sys_io_setup
--- 1.20/arch/s390/kernel/entry.S Wed Oct 9 16:01:41 2002
+++ edited/arch/s390/kernel/entry.S Thu Oct 17 20:24:06 2002
@@ -588,7 +588,7 @@
.long sys_futex
.long sys_sched_setaffinity
.long sys_sched_getaffinity /* 240 */
- .long sys_security
+ .long sys_ni_syscall
.long sys_ni_syscall /* reserved for TUX */
.long sys_io_setup
.long sys_io_destroy
--- 1.18/arch/s390x/kernel/entry.S Wed Oct 9 16:01:41 2002
+++ edited/arch/s390x/kernel/entry.S Thu Oct 17 20:24:13 2002
@@ -617,7 +617,7 @@
.long SYSCALL(sys_futex,sys32_futex_wrapper)
.long SYSCALL(sys_sched_setaffinity,sys32_sched_setaffinity_wrapper)
.long SYSCALL(sys_sched_getaffinity,sys32_sched_getaffinity_wrapper) /* 240 */
- .long SYSCALL(sys_security,sys_ni_syscall)
+ .long SYSCALL(sys_ni_syscall,sys_ni_syscall)
.long SYSCALL(sys_ni_syscall,sys_ni_syscall) /* reserved for TUX */
.long SYSCALL(sys_io_setup,sys_ni_syscall)
.long SYSCALL(sys_io_destroy,sys_ni_syscall)
--- 1.13/arch/sparc/kernel/systbls.S Wed Oct 16 11:07:05 2002
+++ edited/arch/sparc/kernel/systbls.S Thu Oct 17 20:25:50 2002
@@ -49,7 +49,7 @@
/*140*/ .long sys_sendfile64, sys_nis_syscall, sys_futex, sys_gettid, sys_getrlimit
/*145*/ .long sys_setrlimit, sys_pivot_root, sys_prctl, sys_pciconfig_read, sys_pciconfig_write
/*150*/ .long sys_nis_syscall, sys_nis_syscall, sys_nis_syscall, sys_poll, sys_getdents64
-/*155*/ .long sys_fcntl64, sys_security, sys_statfs, sys_fstatfs, sys_oldumount
+/*155*/ .long sys_fcntl64, sys_ni_syscall, sys_statfs, sys_fstatfs, sys_oldumount
/*160*/ .long sys_sched_setaffinity, sys_sched_getaffinity, sys_getdomainname, sys_setdomainname, sys_nis_syscall
/*165*/ .long sys_quotactl, sys_nis_syscall, sys_mount, sys_ustat, sys_setxattr
/*170*/ .long sys_lsetxattr, sys_fsetxattr, sys_getxattr, sys_lgetxattr, sys_getdents
--- 1.18/arch/sparc64/kernel/systbls.S Wed Oct 16 11:07:05 2002
+++ edited/arch/sparc64/kernel/systbls.S Thu Oct 17 20:26:12 2002
@@ -50,7 +50,7 @@
/*140*/ .word sys32_sendfile64, sys_nis_syscall, sys_futex, sys_gettid, sys32_getrlimit
.word sys32_setrlimit, sys_pivot_root, sys32_prctl, sys32_pciconfig_read, sys32_pciconfig_write
/*150*/ .word sys_nis_syscall, sys_nis_syscall, sys_nis_syscall, sys_poll, sys_getdents64
- .word sys32_fcntl64, sys_security, sys32_statfs, sys32_fstatfs, sys_oldumount
+ .word sys32_fcntl64, sys_ni_syscall, sys32_statfs, sys32_fstatfs, sys_oldumount
/*160*/ .word sys32_sched_setaffinity, sys32_sched_getaffinity, sys_getdomainname, sys_setdomainname, sys_nis_syscall
.word sys_quotactl, sys_nis_syscall, sys32_mount, sys_ustat, sys_setxattr
/*170*/ .word sys_lsetxattr, sys_fsetxattr, sys_getxattr, sys_lgetxattr, sys32_getdents
@@ -109,7 +109,7 @@
/*140*/ .word sys_sendfile64, sys_getpeername, sys_futex, sys_gettid, sys_getrlimit
.word sys_setrlimit, sys_pivot_root, sys_prctl, sys_pciconfig_read, sys_pciconfig_write
/*150*/ .word sys_getsockname, sys_nis_syscall, sys_nis_syscall, sys_poll, sys_getdents64
- .word sys_nis_syscall, sys_security, sys_statfs, sys_fstatfs, sys_oldumount
+ .word sys_nis_syscall, sys_ni_syscall, sys_statfs, sys_fstatfs, sys_oldumount
/*160*/ .word sys_sched_setaffinity, sys_sched_getaffinity, sys_getdomainname, sys_setdomainname, sys_utrap_install
.word sys_quotactl, sys_nis_syscall, sys_mount, sys_ustat, sys_setxattr
/*170*/ .word sys_lsetxattr, sys_fsetxattr, sys_getxattr, sys_lgetxattr, sys_getdents
--- 1.2/arch/um/kernel/sys_call_table.c Mon Sep 23 18:52:51 2002
+++ edited/arch/um/kernel/sys_call_table.c Thu Oct 17 20:26:40 2002
@@ -215,7 +215,6 @@
extern syscall_handler_t sys_madvise;
extern syscall_handler_t sys_fcntl64;
extern syscall_handler_t sys_getdents64;
-extern syscall_handler_t sys_security;
extern syscall_handler_t sys_gettid;
extern syscall_handler_t sys_readahead;
extern syscall_handler_t sys_tkill;
@@ -451,7 +450,6 @@
[ __NR_fstat64 ] = sys_fstat64,
[ __NR_fcntl64 ] = sys_fcntl64,
[ __NR_getdents64 ] = sys_getdents64,
- [ __NR_security ] = sys_security,
[ __NR_gettid ] = sys_gettid,
[ __NR_readahead ] = sys_readahead,
[ __NR_setxattr ] = sys_ni_syscall,
--- 1.12/include/asm-alpha/unistd.h Wed Oct 9 03:37:43 2002
+++ edited/include/asm-alpha/unistd.h Thu Oct 17 20:32:16 2002
@@ -317,7 +317,7 @@
#define __NR_getdents64 377
#define __NR_gettid 378
#define __NR_readahead 379
-#define __NR_security 380 /* syscall for security modules */
+/* 380 is unused */
#define __NR_tkill 381
#define __NR_setxattr 382
#define __NR_lsetxattr 383
--- 1.13/include/asm-arm/unistd.h Fri Oct 4 22:52:32 2002
+++ edited/include/asm-arm/unistd.h Thu Oct 17 20:29:02 2002
@@ -247,7 +247,7 @@
#define __NR_madvise (__NR_SYSCALL_BASE+220)
#define __NR_fcntl64 (__NR_SYSCALL_BASE+221)
/* 222 for tux */
-#define __NR_security (__NR_SYSCALL_BASE+223)
+ /* 223 is unused */
#define __NR_gettid (__NR_SYSCALL_BASE+224)
#define __NR_readahead (__NR_SYSCALL_BASE+225)
#define __NR_setxattr (__NR_SYSCALL_BASE+226)
--- 1.9/include/asm-cris/unistd.h Fri Oct 4 23:03:40 2002
+++ edited/include/asm-cris/unistd.h Thu Oct 17 20:29:09 2002
@@ -227,7 +227,7 @@
#define __NR_madvise 219
#define __NR_getdents64 220
#define __NR_fcntl64 221
-#define __NR_security 223 /* syscall for security modules */
+/* 223 is unused */
#define __NR_gettid 224
#define __NR_readahead 225
#define __NR_tkill 226
--- 1.17/include/asm-i386/unistd.h Tue Oct 15 23:45:52 2002
+++ edited/include/asm-i386/unistd.h Thu Oct 17 20:29:16 2002
@@ -227,7 +227,7 @@
#define __NR_madvise1 219 /* delete when C lib stub is removed */
#define __NR_getdents64 220
#define __NR_fcntl64 221
-#define __NR_security 223 /* syscall for security modules */
+/* 223 is unused */
#define __NR_gettid 224
#define __NR_readahead 225
#define __NR_setxattr 226
--- 1.15/include/asm-ia64/unistd.h Fri Oct 4 22:56:14 2002
+++ edited/include/asm-ia64/unistd.h Thu Oct 17 20:29:34 2002
@@ -222,7 +222,7 @@
#define __NR_futex 1230
#define __NR_sched_setaffinity 1231
#define __NR_sched_getaffinity 1232
-#define __NR_security 1233
+/* 1233 currently unused */
#define __NR_alloc_hugepages 1234
#define __NR_free_hugepages 1235
#define __NR_exit_group 1236
--- 1.16/include/asm-ppc/unistd.h Fri Oct 4 22:53:51 2002
+++ edited/include/asm-ppc/unistd.h Thu Oct 17 20:29:49 2002
@@ -228,7 +228,7 @@
#define __NR_futex 221
#define __NR_sched_setaffinity 222
#define __NR_sched_getaffinity 223
-#define __NR_security 224
+/* 224 currently unused */
#define __NR_tuxcall 225
#define __NR_sendfile64 226
#define __NR_io_setup 227
--- 1.10/include/asm-ppc64/unistd.h Fri Oct 4 22:53:45 2002
+++ edited/include/asm-ppc64/unistd.h Thu Oct 17 20:29:57 2002
@@ -233,7 +233,7 @@
#define __NR_futex 221
#define __NR_sched_setaffinity 222
#define __NR_sched_getaffinity 223
-#define __NR_security 224
+/* 224 currently unused */
#define __NR_tuxcall 225
#define __NR_sendfile64 226
#define __NR_io_setup 227
--- 1.9/include/asm-s390/unistd.h Fri Oct 4 22:53:57 2002
+++ edited/include/asm-s390/unistd.h Thu Oct 17 20:30:21 2002
@@ -231,7 +231,9 @@
#define __NR_futex 238
#define __NR_sched_setaffinity 239
#define __NR_sched_getaffinity 240
-#define __NR_security 241 /* syscall for security modules */
+/*
+ * Number 241 is currently unused
+ */
/*
* Number 242 is reserved for tux
*/
--- 1.10/include/asm-s390x/unistd.h Fri Oct 4 22:54:02 2002
+++ edited/include/asm-s390x/unistd.h Thu Oct 17 20:30:31 2002
@@ -198,7 +198,9 @@
#define __NR_futex 238
#define __NR_sched_setaffinity 239
#define __NR_sched_getaffinity 240
-#define __NR_security 241 /* syscall for security modules */
+/*
+ * Number 241 is currently unused
+ */
/*
* Number 242 is reserved for tux
*/
--- 1.16/include/asm-sparc/unistd.h Wed Oct 16 11:07:05 2002
+++ edited/include/asm-sparc/unistd.h Thu Oct 17 20:31:14 2002
@@ -171,7 +171,7 @@
#define __NR_poll 153 /* Common */
#define __NR_getdents64 154 /* Linux specific */
#define __NR_fcntl64 155 /* Linux sparc32 Specific */
-#define __NR_security 156 /* getdirentries under SunOS */
+/* #define __NR_getdirentires 156 SunOS Specific */
#define __NR_statfs 157 /* Common */
#define __NR_fstatfs 158 /* Common */
#define __NR_umount 159 /* Common */
--- 1.15/include/asm-sparc64/unistd.h Wed Oct 16 11:07:05 2002
+++ edited/include/asm-sparc64/unistd.h Thu Oct 17 20:31:44 2002
@@ -171,7 +171,7 @@
#define __NR_poll 153 /* Common */
#define __NR_getdents64 154 /* Linux specific */
/* #define __NR_fcntl64 155 Linux sparc32 Specific */
-#define __NR_security 156 /* getdirentries under SunOS */
+/* #define __NR_getdirentries 156 SunOS Specific */
#define __NR_statfs 157 /* Common */
#define __NR_fstatfs 158 /* Common */
#define __NR_umount 159 /* Common */
--- 1.7/include/asm-x86_64/unistd.h Sat Oct 12 01:52:39 2002
+++ edited/include/asm-x86_64/unistd.h Thu Oct 17 20:32:12 2002
@@ -426,8 +426,7 @@
#define __NR_tuxcall 184 /* reserved for tux */
__SYSCALL(__NR_tuxcall, sys_ni_syscall)
-#define __NR_security 185 /* reserved for LSM/security */
-__SYSCALL(__NR_security, sys_ni_syscall)
+/* 165 currently unused */
#define __NR_gettid 186
__SYSCALL(__NR_gettid, sys_gettid)
--- 1.4/include/linux/security.h Tue Oct 8 11:20:18 2002
+++ edited/include/linux/security.h Thu Oct 17 20:21:00 2002
@@ -671,21 +671,6 @@
* @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.
- * @sys_security:
- * Security modules may use this hook to implement new system calls for
- * security-aware applications. The interface is similar to socketcall,
- * but with an @id parameter to help identify the security module whose
- * call is being invoked. The module is responsible for interpreting the
- * parameters, and must copy in the @args array from user space if it is
- * used.
- * The recommended convention for creating the hexadecimal @id value is
- * echo "Name_of_module" | md5sum | cut -c -8; by using this convention,
- * there is no need for a central registry.
- * @id contains the security module identifier.
- * @call contains the call value.
- * @args contains the call arguments (user space pointer).
- * The module should return -ENOSYS if it does not implement any new
- * system calls.
*
* @register_security:
* allow module stacking.
@@ -713,8 +698,6 @@
kernel_cap_t * permitted);
int (*acct) (struct file * file);
int (*capable) (struct task_struct * tsk, int cap);
- int (*sys_security) (unsigned int id, unsigned call,
- unsigned long *args);
int (*quotactl) (int cmds, int type, int id, struct super_block * sb);
int (*quota_on) (struct file * f);
--- 1.6/security/capability.c Tue Oct 8 11:01:30 2002
+++ edited/security/capability.c Thu Oct 17 20:21:40 2002
@@ -31,12 +31,6 @@
return -EPERM;
}
-static int cap_sys_security (unsigned int id, unsigned int call,
- unsigned long *args)
-{
- return -ENOSYS;
-}
-
static int cap_quotactl (int cmds, int type, int id, struct super_block *sb)
{
return 0;
@@ -731,7 +725,6 @@
.capset_set = cap_capset_set,
.acct = cap_acct,
.capable = cap_capable,
- .sys_security = cap_sys_security,
.quotactl = cap_quotactl,
.quota_on = cap_quota_on,
--- 1.7/security/dummy.c Tue Oct 8 11:01:30 2002
+++ edited/security/dummy.c Thu Oct 17 20:21:31 2002
@@ -61,12 +61,6 @@
return -EPERM;
}
-static int dummy_sys_security (unsigned int id, unsigned int call,
- unsigned long *args)
-{
- return -ENOSYS;
-}
-
static int dummy_quotactl (int cmds, int type, int id, struct super_block *sb)
{
return 0;
@@ -546,7 +540,6 @@
.capset_set = dummy_capset_set,
.acct = dummy_acct,
.capable = dummy_capable,
- .sys_security = dummy_sys_security,
.quotactl = dummy_quotactl,
.quota_on = dummy_quota_on,
--- 1.2/security/security.c Wed Aug 28 22:52:56 2002
+++ edited/security/security.c Thu Oct 17 20:21:20 2002
@@ -223,24 +223,6 @@
return 1;
}
-/**
- * sys_security - security syscall multiplexor.
- * @id: module id
- * @call: call identifier
- * @args: arg list for call
- *
- * Similar to sys_socketcall. Can use id to help identify which module user
- * app is talking to. The recommended convention for creating the
- * hexadecimal id value is:
- * 'echo "Name_of_module" | md5sum | cut -c -8'.
- * By following this convention, there's no need for a central registry.
- */
-asmlinkage long sys_security (unsigned int id, unsigned int call,
- unsigned long *args)
-{
- return security_ops->sys_security (id, call, args);
-}
-
EXPORT_SYMBOL_GPL(register_security);
EXPORT_SYMBOL_GPL(unregister_security);
EXPORT_SYMBOL_GPL(mod_reg_security);
On Thu, Oct 17, 2002 at 07:50:16PM +0100, Christoph Hellwig wrote:
> I've been auditing the LSM stuff a bit more..
>
> They have registered an implemented a syscall, sys_security
> that does nothing but switch into the individual modules
> based on the first argument, i.e. it's ioctl() switching
> on the security module instead of device node. Yuck.
>
> Patch below removes it (no intree users), maybe selinux/etc
> folks should send their actual syscall for review instead..
No, don't remove this!
Yes, it's a big switch, but what do you propose otherwise? SELinux
would need a _lot_ of different security calls, which would be fine, but
we don't want to force every security module to try to go through the
process of getting their own syscalls.
And other subsystems in the kernel do the same thing with their syscall,
like networking, so there is a past history of this usage.
Linus, please do not apply.
thanks,
greg k-h
On Thu, Oct 17, 2002 at 11:53:52AM -0700, Greg KH wrote:
> No, don't remove this!
> Yes, it's a big switch, but what do you propose otherwise? SELinux
> would need a _lot_ of different security calls, which would be fine, but
> we don't want to force every security module to try to go through the
> process of getting their own syscalls.
They should register their syscalls with the kernel properly. Look
at what e.g. the streams people did after the sys_call_table
removal. It's enough that IRIX suffers from the syssgi syndrome, no
need to copy redo their mistakes in Linux.
> And other subsystems in the kernel do the same thing with their syscall,
> like networking, so there is a past history of this usage.
But they don't allow any random module to implement it. And anyone
asked today says the horrible sys_Scoketcall and sys_ipc cludges
were a mistake.
> Linus, please do not apply.
Well, getting it applyed was the intent of sending out this mail..
On Thu, Oct 17, 2002 at 07:58:38PM +0100, Christoph Hellwig wrote:
> On Thu, Oct 17, 2002 at 11:53:52AM -0700, Greg KH wrote:
> > No, don't remove this!
>
> > Yes, it's a big switch, but what do you propose otherwise? SELinux
> > would need a _lot_ of different security calls, which would be fine, but
> > we don't want to force every security module to try to go through the
> > process of getting their own syscalls.
>
> They should register their syscalls with the kernel properly. Look
> at what e.g. the streams people did after the sys_call_table
> removal. It's enough that IRIX suffers from the syssgi syndrome, no
> need to copy redo their mistakes in Linux.
Hm, as I'm not a SELinux developer, I can't tell you how many different
syscalls they need, or what they are for, sorry.
But this will require every security module project to petition for a
syscall, which would be a pain, and is the whole point of having this
sys_security call.
> > And other subsystems in the kernel do the same thing with their syscall,
> > like networking, so there is a past history of this usage.
>
> But they don't allow any random module to implement it. And anyone
> asked today says the horrible sys_Scoketcall and sys_ipc cludges
> were a mistake.
How would they be done differently now? Multiple different syscalls?
I do know that Dave Miller has also complained about the sys_security
call in the past, and the difficulties along the same lines as the
ioctl 32bit problem. If we were to go to individual syscalls for every
security function, this would go away.
In the end, it's Linus's call.
thanks,
greg k-h
p.s. you might want to copy the lsm mailing list in your messages, so
those people there are aware of your comments.
On Thu, 17 Oct 2002, Greg KH wrote:
> Yes, it's a big switch, but what do you propose otherwise? SELinux
> would need a _lot_ of different security calls, which would be fine, but
... or somebody willing to <gasp> try and come up with decent API.
Had you reviewed their extra syscalls, BTW? Do it - and remove
sharp objects before that...
> we don't want to force every security module to try to go through the
> process of getting their own syscalls.
... or, heaven forbid, actually designing interfaces instead of putting
together piles of kludges. Can't have it...
> And other subsystems in the kernel do the same thing with their syscall,
> like networking, so there is a past history of this usage.
Overloadable by arbitrary protocol family driver? Where?
On Thu, Oct 17, 2002 at 12:07:23PM -0700, Greg KH wrote:
> But this will require every security module project to petition for a
> syscall, which would be a pain, and is the whole point of having this
> sys_security call.
And the whole point of the reemoval is to not make adding syscalls
easy. Adding a syscall needs review and most often you actually want
a saner interface.
> How would they be done differently now? Multiple different syscalls?
Yes.
>
> I do know that Dave Miller has also complained about the sys_security
> call in the past, and the difficulties along the same lines as the
> ioctl 32bit problem. If we were to go to individual syscalls for every
> security function, this would go away.
Yes, doing the 32bit translation for a call where you don't actually
know what the arguments mean is impossible. See the 32bit ioctl
compatiblity mess.
On Thu, Oct 17, 2002 at 01:10:31PM -0700, Greg KH wrote:
> > > How would they be done differently now? Multiple different syscalls?
> >
> > Yes.
>
> Hm, in looking at the SELinux documentation, here's a list of the
> syscalls they need:
> http://www.nsa.gov/selinux/docs2.html
>
> That's a lot of syscalls :)
I know. but hiding them doesn't make them any better..
On Thu, Oct 17, 2002 at 09:04:02PM +0100, Christoph Hellwig wrote:
> On Thu, Oct 17, 2002 at 12:07:23PM -0700, Greg KH wrote:
> > But this will require every security module project to petition for a
> > syscall, which would be a pain, and is the whole point of having this
> > sys_security call.
>
> And the whole point of the reemoval is to not make adding syscalls
> easy. Adding a syscall needs review and most often you actually want
> a saner interface.
Ok, I think it's time for someone who actually cares about the security
syscall to step up here to try to defend the existing interface. I'm
pretty sure Ericsson, HP, SELinux, and WireX all use this, so they need
to be the ones defending it.
> > How would they be done differently now? Multiple different syscalls?
>
> Yes.
Hm, in looking at the SELinux documentation, here's a list of the
syscalls they need:
http://www.nsa.gov/selinux/docs2.html
That's a lot of syscalls :)
thanks,
greg k-h
On Thu, 17 Oct 2002 21:07, Greg KH wrote:
> On Thu, Oct 17, 2002 at 07:58:38PM +0100, Christoph Hellwig wrote:
> > > Yes, it's a big switch, but what do you propose otherwise? SELinux
> > > would need a _lot_ of different security calls, which would be fine,
> > > but we don't want to force every security module to try to go through
> > > the process of getting their own syscalls.
> >
> > They should register their syscalls with the kernel properly. Look
> > at what e.g. the streams people did after the sys_call_table
> > removal. It's enough that IRIX suffers from the syssgi syndrome, no
> > need to copy redo their mistakes in Linux.
>
> Hm, as I'm not a SELinux developer, I can't tell you how many different
> syscalls they need, or what they are for, sorry.
I'm not involved with the kernel coding, but I've been doing quite a bit of
user-land SE Linux development (and the first cut at strace support).
SE Linux has currently 52 system calls. One system call was added recently,
and other system calls may need to be added. SE Linux is still in a state of
development.
Now if every SE system call was to be a full Linux system call then LANANA
would be involved in the discussions every time that a new SE call was added,
which would not be desired by the SE Linux people or the LANANA people. So
this means having a switch statement for the different SE calls.
So if we accept that it's a maximum of one system call per security module,
then it's only a small step to do the same for LSM.
Do we expect that SE Linux or other security system calls will be such a
performance bottleneck that an extra switch or two will hurt?
> But this will require every security module project to petition for a
> syscall, which would be a pain, and is the whole point of having this
> sys_security call.
Also it would mean that developmental projects would be more difficult. If
you are doing some experimental coding that's not ready for release then
there might be a number of kernels released during the development cycle
before you petition for a number. In this case you may be forced to change
the syscall number if someone else gets the number you were working with.
Then when we share patches of experimental software there will be issues of
syscall conflicts. With the current LSM setup of a 2^32 LSM calls, you can
choose a number somewhat arbitarily and be fairly sure that it won't conflict
and that you can later register the same number with the LSM people.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
On Thu, Oct 17, 2002 at 10:20:21PM +0200, Russell Coker wrote:
> Now if every SE system call was to be a full Linux system call then LANANA
> would be involved in the discussions every time that a new SE call was added,
> which would not be desired by the SE Linux people or the LANANA people. So
> this means having a switch statement for the different SE calls.
Then stabilize your interface before going into production use. Why
should selinux (or lsm) get special treatment?
> Do we expect that SE Linux or other security system calls will be such a
> performance bottleneck that an extra switch or two will hurt?
It's not the performance issues, it's about getting a proper syscall table
instead of deep nesting without knowing what it actually does.
Look at e.g. the horrors of doing a proper 32->64bit translation
of those syscalls.
> Also it would mean that developmental projects would be more difficult.
Yes. In general you should avoid adding syscalls anyway. If we
wanted to make it easy we'd have created loadable syscalls from the very
beginning.
From: Greg KH <[email protected]>
Date: Thu, 17 Oct 2002 11:53:52 -0700
No, don't remove this!
Yes, it's a big switch, but what do you propose otherwise? SELinux
would need a _lot_ of different security calls, which would be fine, but
we don't want to force every security module to try to go through the
process of getting their own syscalls.
And other subsystems in the kernel do the same thing with their syscall,
like networking, so there is a past history of this usage.
Well, here is another issue about opaque interfaces, how are we
supposed to audit whether 32-bit/64-bit execution environments
will be able to work correctly?
If there is no description available of what the types are going
through these system calls, it cannot be handled properly.
It is one thing if some existing legacy user interface we can't make
go away creates this kind of problem, but when we add new system calls
we ought to be much much more careful.
I brought this up months ago, and I believe someone (perhaps you :),
said "oh I'll bring that up with the folks, thanks" and I've seen
no action taken since.
Are the LSM modules that exist now using portable types in the objects
passed into sys_security? Note that pointers and things like "long"
are not allowed as types, for example, those would need to be translated.
The more I look at LSM the more and more I dislike it, it sticks it's
fingers everywhere. Who is going to use this stuff? %99.999 of users
will never load a security module, and the distribution makers are
going to enable this NOP overhead for _everyone_ just so a few telcos
or government installations can get their LSM bits?
This doesn't make any sense to me, including LSM appears to be quite
against one of the basic maxims of Linux kernel ideology if you ask me
:-) (said maxim is: If %99 of users won't use it, they better not
even notice it is there or be affected by it in any way)
On Thu, Oct 17, 2002 at 10:20:21PM +0200, Russell Coker wrote:
> With the current LSM setup of a 2^32 LSM calls, you can
> choose a number somewhat arbitarily and be fairly sure that it won't conflict
> and that you can later register the same number with the LSM people.
You do not have to "register" a syscall number with the LSM people. We
don't care. Use whatever you want for your sys_security call. If you
want to be nice, read the documentation and use a module id that is
unique.
Personally I hate the "module id" idea, but that's just me...
thanks,
greg k-h
On Thu, Oct 17, 2002 at 01:18:30PM -0700, David S. Miller wrote:
> From: Greg KH <[email protected]>
> Date: Thu, 17 Oct 2002 11:53:52 -0700
>
> No, don't remove this!
> Yes, it's a big switch, but what do you propose otherwise? SELinux
> would need a _lot_ of different security calls, which would be fine, but
> we don't want to force every security module to try to go through the
> process of getting their own syscalls.
>
> And other subsystems in the kernel do the same thing with their syscall,
> like networking, so there is a past history of this usage.
>
> Well, here is another issue about opaque interfaces, how are we
> supposed to audit whether 32-bit/64-bit execution environments
> will be able to work correctly?
>
> If there is no description available of what the types are going
> through these system calls, it cannot be handled properly.
>
> It is one thing if some existing legacy user interface we can't make
> go away creates this kind of problem, but when we add new system calls
> we ought to be much much more careful.
>
> I brought this up months ago, and I believe someone (perhaps you :),
> said "oh I'll bring that up with the folks, thanks" and I've seen
> no action taken since.
Yes, you pointed this out to me, and I said that. Very sorry, I got
busy with other things and I didn't follow through, my fault.
> Are the LSM modules that exist now using portable types in the objects
> passed into sys_security? Note that pointers and things like "long"
> are not allowed as types, for example, those would need to be translated.
Yes, you are correct, they better be implemented properly, or they will
not work.
> The more I look at LSM the more and more I dislike it, it sticks it's
> fingers everywhere. Who is going to use this stuff? %99.999 of users
> will never load a security module, and the distribution makers are
> going to enable this NOP overhead for _everyone_ just so a few telcos
> or government installations can get their LSM bits?
Um, I know a few distro makers that are going to implement this and are
seriously conserding shipping SELinux soon. Debian included :)
And (ignoring the network hooks) there is not a measurable overhead for
these hooks. We have documented this many times (OLS paper, USENIX
paper, etc.) With the patch I'm about to submit, disabling the option
makes them go away entirely.
thanks,
greg k-h
Greg KH wrote:
> Hm, in looking at the SELinux documentation, here's a list of the
> syscalls they need:
> http://www.nsa.gov/selinux/docs2.html
>
> That's a lot of syscalls :)
Any idea if security identifiers change with each syscall?
If not, a lot of the xxx_secure syscalls could go away...
On Thu, 17 Oct 2002 22:10, Greg KH wrote:
> Hm, in looking at the SELinux documentation, here's a list of the
> syscalls they need:
> http://www.nsa.gov/selinux/docs2.html
>
> That's a lot of syscalls :)
That documentation only includes references to the system calls that have man
pages. From a quick review ichsid() is missing so there's at least 1 more
system call than is listed there.
--
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
From: Greg KH <[email protected]>
Date: Thu, 17 Oct 2002 13:36:52 -0700
> Are the LSM modules that exist now using portable types in the objects
> passed into sys_security? Note that pointers and things like "long"
> are not allowed as types, for example, those would need to be translated.
Yes, you are correct, they better be implemented properly, or they will
not work.
How am I supposed to know what the things are being passed in
via these opaque "unsigned long" parameters?
Could they be pointers? If so, game over already, and this needs
to be fixed NOW.
And (ignoring the network hooks) there is not a measurable overhead for
these hooks. We have documented this many times (OLS paper, USENIX
paper, etc.) With the patch I'm about to submit, disabling the option
makes them go away entirely.
Look at the code that gets output, look at the 32K of kernel image
I get even though I have no intention of _ever_ loading a security
module.
So if distribution makers enable CONFIG_SECURITY, EVERY USER eats
this 32K. That _SUCKS_.
And I severely contest your overhead argument, look at the assembler
code being output, the kernel parts where the hooks are placed are
different. Lots of places that used to be leaf functions are no
longer leaf functions due to the security_ops invocation being there
now. Register allocation is also going to be quite different
different.
In short, it's bloat, and if you refuse to realize that perhaps kernel
development is not your true calling in life :-)
On Thu, 17 Oct 2002 22:30, Jeff Garzik wrote:
> Greg KH wrote:
> > Hm, in looking at the SELinux documentation, here's a list of the
> > syscalls they need:
> > http://www.nsa.gov/selinux/docs2.html
> >
> > That's a lot of syscalls :)
>
> Any idea if security identifiers change with each syscall?
>
> If not, a lot of the xxx_secure syscalls could go away...
None of them can go away.
Security identifiers are for the operation you perform. For example
open_secure() is so that you can specify the security context for a new file
that you are creating. connect_secure() is used to specify the security
context of the socket you want to connect to. In the default setup the only
way that connect_secure() and open_secure() can use the same SID is for unix
domain sockets (which are labeled with file types). A TCP connection will be
to a process, the SID of a process is not a valid type label for a file.
lstat_secure(), recv_secure() and others are used to retrieve the security
context of the file, network message, etc.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
On Thu, Oct 17, 2002 at 01:38:16PM -0700, David S. Miller wrote:
>
> How am I supposed to know what the things are being passed in
> via these opaque "unsigned long" parameters?
>
> Could they be pointers? If so, game over already, and this needs
> to be fixed NOW.
Agreed, I'll let a user of this function speak up on how they intend to
address the problem. I'm through arguing for this hook.
> And (ignoring the network hooks) there is not a measurable overhead for
> these hooks. We have documented this many times (OLS paper, USENIX
> paper, etc.) With the patch I'm about to submit, disabling the option
> makes them go away entirely.
>
> Look at the code that gets output, look at the 32K of kernel image
> I get even though I have no intention of _ever_ loading a security
> module.
>
> So if distribution makers enable CONFIG_SECURITY, EVERY USER eats
> this 32K. That _SUCKS_.
Note for the readers, this is 32K on Sparc, on i386 it's much smaller as
documented yesterday.
> And I severely contest your overhead argument, look at the assembler
> code being output, the kernel parts where the hooks are placed are
> different. Lots of places that used to be leaf functions are no
> longer leaf functions due to the security_ops invocation being there
> now. Register allocation is also going to be quite different
> different.
I've run the numbers myself on OSDL machines, and seen that there is no
measurable overhead for these functions. Sure, there is an extra
function call, and different assembler, I'll never contest that. It's
just that I could not measure it.
> In short, it's bloat, and if you refuse to realize that perhaps kernel
> development is not your true calling in life :-)
It is adding stuff to the kernel. Now if you want to call it bloat,
fine. I like calling the USB stack bloat too, and it is bloat for
people who don't use it. And now you can disable the option, so it will
not be bloat for you too, if you don't want it. Argue with your
favorite distro if they enable the option that they shouldn't do that,
if they do, don't try to convince me.
And I know what my true calling in life is, but unfortunately there isn't
much calling for a professional pan flute player :)
thanks,
greg k-h
From: Greg KH <[email protected]>
Date: Thu, 17 Oct 2002 13:58:31 -0700
I've run the numbers myself on OSDL machines, and seen that there is no
measurable overhead for these functions. Sure, there is an extra
function call, and different assembler, I'll never contest that. It's
just that I could not measure it.
Did you look at the _code_? Did you measure the size of even the
non security/*.o object code with/without the hooks? What is the
added overhead?
2.5.x is busting at the seams currently and CONFIG_SECURITY is part of
the reason why.
It is adding stuff to the kernel. Now if you want to call it bloat,
fine. I like calling the USB stack bloat too, and it is bloat for
people who don't use it.
There is a very important fundamental difference to the USB case.
It eats zero space in my kernel when I have no USB devices.
CONFIG_USB=m works as designed!
CONFIG_SECURITY=m still does not exist, so distribution makers have to
make a y vs. n choice.
Argue with your favorite distro if they enable the option that they
shouldn't do that, if they do, don't try to convince me.
I need to convince you to implement this in a way, so that like
USB, there is zero overhead when I enable it as a module. :-)
And I know what my true calling in life is, but unfortunately there isn't
much calling for a professional pan flute player :)
:)
Russell Coker wrote:
> On Thu, 17 Oct 2002 22:30, Jeff Garzik wrote:
>
>>Greg KH wrote:
>>
>>>Hm, in looking at the SELinux documentation, here's a list of the
>>>syscalls they need:
>>> http://www.nsa.gov/selinux/docs2.html
>>>
>>>That's a lot of syscalls :)
>>
>>Any idea if security identifiers change with each syscall?
>>
>>If not, a lot of the xxx_secure syscalls could go away...
>
>
> None of them can go away.
>
> Security identifiers are for the operation you perform. For example
> open_secure() is so that you can specify the security context for a new file
> that you are creating. connect_secure() is used to specify the security
> context of the socket you want to connect to. In the default setup the only
> way that connect_secure() and open_secure() can use the same SID is for unix
> domain sockets (which are labeled with file types). A TCP connection will be
> to a process, the SID of a process is not a valid type label for a file.
>
> lstat_secure(), recv_secure() and others are used to retrieve the security
> context of the file, network message, etc.
What specific information differs per-operation, such that security
identifiers cannot be stored internally inside a file handle?
Jeff
On Thu, 17 Oct 2002 23:10, Jeff Garzik wrote:
> >>Any idea if security identifiers change with each syscall?
> >>
> >>If not, a lot of the xxx_secure syscalls could go away...
> >
> > None of them can go away.
> >
> > Security identifiers are for the operation you perform. For example
> > open_secure() is so that you can specify the security context for a new
> > file that you are creating. connect_secure() is used to specify the
> > security context of the socket you want to connect to. In the default
> > setup the only way that connect_secure() and open_secure() can use the
> > same SID is for unix domain sockets (which are labeled with file types).
> > A TCP connection will be to a process, the SID of a process is not a
> > valid type label for a file.
> >
> > lstat_secure(), recv_secure() and others are used to retrieve the
> > security context of the file, network message, etc.
>
> What specific information differs per-operation, such that security
> identifiers cannot be stored internally inside a file handle?
My previous message obviously wasn't clear enough.
When you want to read or set the SID of a file handle then you need to pass in
a SID pointer or a SID.
This is what the *_secure() system calls do, they set a SID or read a SID.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
On Thu, 17 Oct 2002, Russell Coker wrote:
> > What specific information differs per-operation, such that security
> > identifiers cannot be stored internally inside a file handle?
>
> My previous message obviously wasn't clear enough.
>
> When you want to read or set the SID of a file handle then you need to pass in
> a SID pointer or a SID.
So fscking what? _Nothing_ of the above warrants a new syscall. There
are struct file * attributes and there are descriptor attributes.
Rather than excreting a new syscall you could look what already exists
in the API.
Frankly, SELinux has some interesting ideas, but interfaces are appalling.
Either they've never cared about it, or they have no taste (or have, er,
overriding manag^Wissues actively hostile to any taste). Take your pick.
And don't get me started on access to file by inumber and other beauties
in that excuse of an API. It wasn't designed. It happened. As in, "it
happens".
David S. Miller wrote:
>Who is going to use this stuff? %99.999 of users
>will never load a security module, and the distribution makers are
>going to enable this NOP overhead for _everyone_ just so a few telcos
>or government installations can get their LSM bits?
I don't understand how anyone can possibly know that.
It's true that today very few users use security modules,
but the Linux kernel doesn't support loadable security modules
today, so it would be unreasonable to use today's figures to
estimate likely future usage.
>This doesn't make any sense to me, including LSM appears to be quite
>against one of the basic maxims of Linux kernel ideology if you ask me
>:-) (said maxim is: If %99 of users won't use it, they better not
>even notice it is there or be affected by it in any way)
Ahh, good. Then you should be pretty happy with the current LSM
framework. I believe that users who don't load a LSM module won't
notice anything. For example, the LSM folks have several performance
measurements that show that the performance overhead of LSM is basically
negligible, so that's one way that users won't notice it is there.
On Thu, Oct 17, 2002 at 01:58:32PM -0700, David S. Miller wrote:
> From: Greg KH <[email protected]>
> Date: Thu, 17 Oct 2002 13:58:31 -0700
>
> I've run the numbers myself on OSDL machines, and seen that there is no
> measurable overhead for these functions. Sure, there is an extra
> function call, and different assembler, I'll never contest that. It's
> just that I could not measure it.
>
> Did you look at the _code_? Did you measure the size of even the
> non security/*.o object code with/without the hooks? What is the
> added overhead?
I did not look at size, sorry. I only looked at run-time performance.
> 2.5.x is busting at the seams currently and CONFIG_SECURITY is part of
> the reason why.
With the patch I just sent, that size issue should be resolved.
> I need to convince you to implement this in a way, so that like
> USB, there is zero overhead when I enable it as a module. :-)
I would love to implement it in such a manner. Without using
self-modifying code, do you have any ideas of how this could be done?
thanks,
greg k-h
On Thu, 17 Oct 2002 23:49, Alexander Viro wrote:
> On Thu, 17 Oct 2002, Russell Coker wrote:
> > > What specific information differs per-operation, such that security
> > > identifiers cannot be stored internally inside a file handle?
> >
> > My previous message obviously wasn't clear enough.
> >
> > When you want to read or set the SID of a file handle then you need to
> > pass in a SID pointer or a SID.
>
> So fscking what? _Nothing_ of the above warrants a new syscall. There
> are struct file * attributes and there are descriptor attributes.
> Rather than excreting a new syscall you could look what already exists
> in the API.
OK, how do you go about supplying extra data to a file open than to modify the
open system call?
If for example I want to create a file of context
"system_u:object_r:fingerd_log_t" under /var/log (instead of taking the
context from that of the /var/log directory "system_u:object_r:var_log_t")
then how would I go about doing it other than through a modified open system
call?
When are extended attributes going to be in Ext2/3? This issue could be
solved through them, but not in any other way AFAIK.
> Frankly, SELinux has some interesting ideas, but interfaces are appalling.
> Either they've never cared about it, or they have no taste (or have, er,
> overriding manag^Wissues actively hostile to any taste). Take your pick.
>
> And don't get me started on access to file by inumber and other beauties
> in that excuse of an API. It wasn't designed. It happened. As in, "it
> happens".
ichsid() was created to allow relabeling of the mount points of mounted file
systems.
When you install SE Linux you need to have the mount points labelled
appropriately. The default file_t is usually OK, however there is the issue
of re-installing SE Linux on a machine that previously had it, and as the SE
Linux type labels are not integrated into the file system (need extended
attributes) the type database could be out of sync with the file system. Of
course most mount points can be relabelled in single user mode after
umounting the file systems - except /dev on a devfs system...
Admittedly ichsid() is pretty ugly even when you consider the ugly problem
it's trying to solve.
What are the "other beauties" you refer to?
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
On Thu, Oct 17, 2002 at 03:07:22PM -0700, David S. Miller wrote:
>
> I would love to implement it in such a manner. Without using
> self-modifying code, do you have any ideas of how this could be done?
>
> Yes, I agree it's a difficult problem.
>
> My main point is, don't compare the security bloat to USB, because in
> the USB case if I don't use it I get no space/time consumption even if
> I have it enabled (as a module). This is not true for the security
> bits.
Agreed, I shouldn't have made that comparison in the first place, sorry.
Even if I do view the USB code as bloat at times... :)
greg k-h
From: Greg KH <[email protected]>
Date: Thu, 17 Oct 2002 15:09:57 -0700
> 2.5.x is busting at the seams currently and CONFIG_SECURITY is part of
> the reason why.
With the patch I just sent, that size issue should be resolved.
I really apprecite that you've done this work Greg.
Thank you.
> I need to convince you to implement this in a way, so that like
> USB, there is zero overhead when I enable it as a module. :-)
I would love to implement it in such a manner. Without using
self-modifying code, do you have any ideas of how this could be done?
Yes, I agree it's a difficult problem.
My main point is, don't compare the security bloat to USB, because in
the USB case if I don't use it I get no space/time consumption even if
I have it enabled (as a module). This is not true for the security
bits.
On Oct 18, 2002 00:14 +0200, Russell Coker wrote:
> When are extended attributes going to be in Ext2/3? This issue could be
> solved through them, but not in any other way AFAIK.
Ted is actively trying to merge them in 2.5.
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
From: [email protected] (David Wagner)
Date: 17 Oct 2002 21:54:49 GMT
For example, the LSM folks have several performance
measurements that show that the performance overhead of LSM is
basically negligible, so that's one way that users won't notice it
is there.
How about size measurements? As in, the kernel is at a minimum
several Kb larger than if CONFIG_SECURITY=n
And about prospective usage of LSM, it can be judged even though it
isn't in the tree yet. That's how we decide what to put into the
kernel to begin with.
Look at your average user, he doesn't really care about LSM. He wants
to be able to play his music, play quake3, surf the web, write emails
and compose documents. If he's a developer he also wants to compile
programs and source management tools. If he's an artist or
professional photographer, he wants something like the GIMP.
Sure, it might become popular on multi-user machines to use
some sort of LSM module for this purpose or that.
But as far as raw seats are concerned, the majority will not use
LSM. They simply have no need for it on their workstation.
David S. Miller wrote:
> The more I look at LSM the more and more I dislike it, it sticks it's
> fingers everywhere. Who is going to use this stuff? %99.999 of users
> will never load a security module, and the distribution makers are
> going to enable this NOP overhead for _everyone_ just so a few telcos
> or government installations can get their LSM bits?
>
I'm going to ignore the overhead stated above here. And please take the
following as a comment/personal opinion you may as well ignore. But I'm
somewhat irritated, so:
<sarcasm>
So users are dumb in general, why not apply the "Single user linux"
patch? If you don't remember: http://www.surriel.com/potm/apr2001.shtml
</sarcasm>
Honestly, if you don't offer a patchless option to tighter security you
can't estimate usage.
Given that LSM becomes a standard part of the kernel it would be easy
for distros to offer "trusted" installations based on LSM. And in this
case advanced security will spread.
> This doesn't make any sense to me, including LSM appears to be quite
> against one of the basic maxims of Linux kernel ideology if you ask me
> :-) (said maxim is: If %99 of users won't use it, they better not
> even notice it is there or be affected by it in any way)
For the next few years 99% of the linux users won't use GBit ethernet,
so why don't you remove these drivers from the kernel?
If things should be only added to the kernel if there's already
sufficient users my opinion is that development would come to a grinding
halt.
--
Andreas Steinmetz
Andreas Steinmetz wrote:
> David S. Miller wrote:
>
>> The more I look at LSM the more and more I dislike it, it sticks it's
>> fingers everywhere. Who is going to use this stuff? %99.999 of users
>> will never load a security module, and the distribution makers are
>> going to enable this NOP overhead for _everyone_ just so a few telcos
>> or government installations can get their LSM bits?
>>
>
> I'm going to ignore the overhead stated above here. And please take the
> following as a comment/personal opinion you may as well ignore. But I'm
> somewhat irritated, so:
>
> <sarcasm>
> So users are dumb in general, why not apply the "Single user linux"
> patch? If you don't remember: http://www.surriel.com/potm/apr2001.shtml
> </sarcasm>
>
> Honestly, if you don't offer a patchless option to tighter security you
> can't estimate usage.
>
> Given that LSM becomes a standard part of the kernel it would be easy
> for distros to offer "trusted" installations based on LSM. And in this
> case advanced security will spread.
No offense, please, but I really think David is being very reasonable.
The normal "Linux way" is to have zero overhead unless something is
actually used -- witness spinlocks on UP versus SMP.
Regardless of whether some people feel the "majority" will be using LSM
at some point in the future, David's point is very valid today, and for
some time to come.
Finally, I was under the impression that Greg KH agreed that it is
possible to eliminate this overhead? Maybe I recall incorrectly.
Respectfully,
Jeff
From: Andreas Steinmetz <[email protected]>
Date: Fri, 18 Oct 2002 00:51:29 +0200
For the next few years 99% of the linux users won't use GBit ethernet,
so why don't you remove these drivers from the kernel?
The vast majority of desktop computers today ship with gigabit
ethernet interfaces on the motherboard.
So you are wrong, people use it today.
As per the rest of your email, most of my disagreement has to do
with the fact that the implementation isn't optimal. Going back
to USB, it's optimal because it falls into one of two possible
categories:
1) If I don't use it, and it's built as a module, it takes up
no resources on my computer.
2) The facilities added to support feature X also helps make
things like Y and Z possible.
Things like #2 are the things Al Viro is talking about.
So instead of "security_ops()->this, security_ops()->that" being
sprinkled merrily all over the VFS, we have something useful to things
outside of LSM such as full file */fd attributes.
Frankly, as a side effect of no effort being put into #2, the LSM user
level interface is complete shit. As is the hook mechanism.
From: Jeff Garzik <[email protected]>
Date: Thu, 17 Oct 2002 19:00:58 -0400
Finally, I was under the impression that Greg KH agreed that it is
possible to eliminate this overhead? Maybe I recall incorrectly.
The agreement was that it would be nice, we also agreed
that it's a very difficult thing to implement.
I'm now leaning more towards something like what Al Viro
hinted at earlier, creating generic per-file/fd attributes.
This kind of stuff.
David S. Miller wrote:
> I'm now leaning more towards something like what Al Viro
> hinted at earlier, creating generic per-file/fd attributes.
> This kind of stuff.
>
I'm perfectly happy with anything that doesn't kill LSM.
--
Andreas Steinmetz
On Thu, Oct 17, 2002 at 03:56:30PM -0700, David S. Miller wrote:
>
> I'm now leaning more towards something like what Al Viro
> hinted at earlier, creating generic per-file/fd attributes.
> This kind of stuff.
I think either Al, or Chris Wright, have mentioned that stackable
filesystems would remove all of the LSM VFS hooks, and also enable a lot
of other cool things to happen. Unfortunately, that's not going to make
it into 2.6, but in the future is probably the way to go.
thanks,
greg k-h
On Thu, Oct 17, 2002 at 07:00:58PM -0400, Jeff Garzik wrote:
>
> Finally, I was under the impression that Greg KH agreed that it is
> possible to eliminate this overhead? Maybe I recall incorrectly.
I eliminated the overhead at compile time, yes, much like spinlocks.
What would be ideal is if we could do CONFIG_SECURITY=m and only if
someone wants to load a security module, would they incur the overhead.
thanks,
greg k-h
* David S. Miller ([email protected]) wrote:
>
> But as far as raw seats are concerned, the majority will not use
> LSM. They simply have no need for it on their workstation.
I agree, the average desktop user isn't even aware of the issues. But I
think the photographer would like it if the mp3 player can't remove files
in ~/photos/ when it plays a malicious .mp3 file. So even the desktop
user could benefit from better security infrastructure. But your point
on security uptake is well-taken.
thanks,
-chris
* Greg KH ([email protected]) wrote:
> On Thu, Oct 17, 2002 at 03:56:30PM -0700, David S. Miller wrote:
> >
> > I'm now leaning more towards something like what Al Viro
> > hinted at earlier, creating generic per-file/fd attributes.
> > This kind of stuff.
>
> I think either Al, or Chris Wright, have mentioned that stackable
> filesystems would remove all of the LSM VFS hooks, and also enable a lot
> of other cool things to happen. Unfortunately, that's not going to make
> it into 2.6, but in the future is probably the way to go.
I think it's more like filters than true stacking. If I understand the
problem correctly, true generic stacking introduces cache coherency fun.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
From: Chris Wright <[email protected]>
Date: Thu, 17 Oct 2002 16:04:36 -0700
the photographer would like it if the mp3 player can't remove files
in ~/photos/ when it plays a malicious .mp3 file.
LSM doesn't provide anything in this area which can't be done
today. You can protect that directory from malicious programs
today with file/dir protections and running programs with a different
capability set or even with a different euid/egid for file accesses.
Christoph Hellwig wrote:
>On Thu, Oct 17, 2002 at 01:10:31PM -0700, Greg KH wrote:
>
>
>>>>How would they be done differently now? Multiple different syscalls?
>>>>
>>>>
>>>Yes.
>>>
>>>
>>Hm, in looking at the SELinux documentation, here's a list of the
>>syscalls they need:
>> http://www.nsa.gov/selinux/docs2.html
>>
>>That's a lot of syscalls :)
>>
>>
>I know. but hiding them doesn't make them any better..
>
Actuall, yes it does, and that is the point. You don't have to like
SELinux's system calls, or any other module's syscalls. The whole point
of LSM was to decouple security design from the Linux kernel development.
There are a butt-load of different access control models, and many of
them are not compatible with one another. You wouldn't want to support
them all--that would be serious bloat. So instead, LSM lets each user
choose the model that suits them:
* server users can choose a highly secure model
* workstation users can choose something desktop oriented
* embedded people can choose nothing at all, or the specific
narrow-cast model that they need
On the other hand: what is the big cost here? One system call. Isn't
that actually *lower* overhead than the (say) half dozen
security-oriented syscalls we might convince you to accept if we drop
the sys_security syscall as you suggest? Why the fierce desire to remove
something so cheap?
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
On Fri, Oct 18, 2002 at 12:04:00AM -0700, Crispin Cowan wrote:
> Why the fierce desire to remove something so cheap?
Because it's so crappy :)
And will not work properly on all architectures, which is one of the
biggest reasons to get rid of it, IMHO.
thanks,
greg k-h
From: Crispin Cowan <[email protected]>
Date: Fri, 18 Oct 2002 00:04:00 -0700
Christoph Hellwig wrote:
>On Thu, Oct 17, 2002 at 01:10:31PM -0700, Greg KH wrote:
>I know. but hiding them doesn't make them any better..
Actuall, yes it does, and that is the point. You don't have to like
SELinux's system calls, or any other module's syscalls. The whole point
of LSM was to decouple security design from the Linux kernel development.
Anything which passes a completely opaque value through a system
call is a sign of trouble, design wise.
There is simply no way we can enfore proper portable typing by
all these security module authors such that we can do any kind
of proper 32-bit/64-bit syscall translation on the ports that
need to do this.
If we do things such as the fs stacking or fs filter ideas,
that eliminates a whole swath of the facilities the security_ops
"provide". No ugly syscalls passing opaque types through the kernel
to some magic module, but rather a real facility that is useful
to many things other than LSM.
On Fri, 18 Oct 2002, Crispin Cowan wrote:
> * server users can choose a highly secure model
> * workstation users can choose something desktop oriented
> * embedded people can choose nothing at all, or the specific
> narrow-cast model that they need
>
> On the other hand: what is the big cost here? One system call. Isn't
> that actually *lower* overhead than the (say) half dozen
> security-oriented syscalls we might convince you to accept if we drop
> the sys_security syscall as you suggest? Why the fierce desire to remove
> something so cheap?
Because ugliness has its price. As for "highly secure"... Could we please
see some proof? Clearly stated properties with code audit to verify them
would be nice.
I'm yet to see a single shred of evidence that so-called security improvements
actually do improve security (as opposed to feeling of security - quite
a different animal). And in this case burden of proof is clearly on your
side.
What I _do_ see is a lucrative market for peddlers of feel-good "solutions"
that do not make anything secure but have miles-long feature lists that
can be used to impress PHBs. Now, I have no particular problems with
people who help suckers part with their money, but I don't see any reason
to support them.
3 or 4 patches that might be interesting would be better off without LSM.
The rest... care to give a hard evidence that it is worth any support?
David S. Miller wrote:
>There is a very important fundamental difference to the USB case.
>It eats zero space in my kernel when I have no USB devices.
>CONFIG_USB=m works as designed!
>
>CONFIG_SECURITY=m still does not exist, so distribution makers have to
>make a y vs. n choice.
>
This was our design goal for LSM: to be as minimally intrusive to the
kernel as possible. We would LOVE to have a zero-footprint solution that
allowed users to enable LSM when they need it. More precisely, LSM is
that mechanism intended to impose as little overhead as possible with no
modules loaded, and provide adequate access to the modules when they are
loaded.
LSM is not zero-footprint, but it is as low as we could make it. We are
interested in ways to reduce the footprint, but that reduction needs to
be looked at in cost/benefit terms: changes that have very little impact
on footprint, but high impact on the functionality of the LSM interface.
If you remove this system call, you will save almost nothing in kernel
resources, but do a lot of damage to functionality.
On the other hand, the complaints about the typing of the arguments are
well taken, in the context of 32/64-bit porting issues. So what types
should the arguments be? Abstractly, they are integers, in the
mathematical sense. What is the preferred word-size-portalbe way to
express that?
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
From: Crispin Cowan <[email protected]>
Date: Fri, 18 Oct 2002 01:00:34 -0700
LSM is not zero-footprint, but it is as low as we could make it.
I disagree, entirely.
You could entirely hide a lot of this crap, especially the
VFS stuff, by stacking in your own LSM specific VFS ops
if we could stack filesystems or something like that.
From: Crispin Cowan <[email protected]>
Date: Fri, 18 Oct 2002 01:31:35 -0700
Could you elaborate on why this is a sign of trouble, design wise?
Bacause if you can't even specify the data types, something
is severely wrong. It's entirely a black box.
That doesn't give it system call status.
Compare:
read(fd, buf, size)
This reads, from file descriptor FD, into BUF of
size SIZE.
with:
security(id, call, args)
???
How would you describe this in a manpage, for example?
>There is simply no way we can enfore proper portable typing by
>all these security module authors such that we can do any kind
>of proper 32-bit/64-bit syscall translation on the ports that
>need to do this.
THAT I would love to hear about. If all we have to do to save
sys_security is change its signature, that'd be great.
Well for one thing a pointer to opaque stuff can't be translated
properly. You MUST KNOW THE DATA TYPES that are being passed
into the system call to translate it properly.
Your system call, BY DESIGN, makes the data types opaque and
indeterminable.
You can only fix this by contradicting yourself. :-)
Yes, that will be wonderful. And the LSM team will be pleased to re-work
the desing when stackable file systems appear and we can take advantage
of them.
So we should just stick your crap in now right? No, that is not how
things work.
David S. Miller wrote:
>Anything which passes a completely opaque value through a system
>call is a sign of trouble, design wise.
>
That's interesting. Passing a completely opaque value (actually an
integer) through the system call was exactly what we designed it to do,
because we saw a design need for pecisely that: so that applications
with awareness of a specific module can talk to the module.
Could you elaborate on why this is a sign of trouble, design wise?
>There is simply no way we can enfore proper portable typing by
>all these security module authors such that we can do any kind
>of proper 32-bit/64-bit syscall translation on the ports that
>need to do this.
>
THAT I would love to hear about. If all we have to do to save
sys_security is change its signature, that'd be great.
>If we do things such as the fs stacking or fs filter ideas,
>that eliminates a whole swath of the facilities the security_ops
>"provide". No ugly syscalls passing opaque types through the kernel
>to some magic module, but rather a real facility that is useful
>to many things other than LSM.
>
Yes, that will be wonderful. And the LSM team will be pleased to re-work
the desing when stackable file systems appear and we can take advantage
of them.
Crispin
Alexander Viro wrote:
>On Fri, 18 Oct 2002, Crispin Cowan wrote:
>
>
>> * server users can choose a highly secure model
>> * workstation users can choose something desktop oriented
>> * embedded people can choose nothing at all, or the specific
>> narrow-cast model that they need
>>
>>On the other hand: what is the big cost here? One system call. Isn't
>>that actually *lower* overhead than the (say) half dozen
>>security-oriented syscalls we might convince you to accept if we drop
>>the sys_security syscall as you suggest? Why the fierce desire to remove
>>something so cheap?
>>
>>
>Because ugliness has its price. As for "highly secure"... Could we please
>see some proof? Clearly stated properties with code audit to verify them
>would be nice.
>
LSM being an interface, it doesn't provide that. LSM's objective is to
provide modules with the ability to mediate access to major internal
kernel objects by user processes.
The security modules, in turn, use this ability to mediate to access to
objects to implement some specific stated security property, and you
would have to audit the module's code.
Some simple properties in the OWLSM module (porting some of the
properties from the Openwall patch, and adding some more):
* root may not follow non-root symlinks in certain circumstances
(prevent some temp file attacks)
* non-root may not create a hard-link to root-owned files in certain
circumstances (prevent some other temp file attacks)
* may not ptrace root processes (preventing further recurrance of
the bugs in ptrace over the last year or so)
These policies help a lot to secure a system. But these policies also
break some things, so it is good that they be a loadable module, and not
a proposed Linux patch.
>I'm yet to see a single shred of evidence that so-called security improvements
>actually do improve security (as opposed to feeling of security - quite
>a different animal). And in this case burden of proof is clearly on your
>side.
>
We took a system protected with SubDomain to Defcon and kicked ass
http://news.com.com/2100-1001-948404.html?tag=rn
That was a 2.2 version of SubDomain. SubDomain is in the process of
being ported to the 2.4 back-patch version of LSM.
>What I _do_ see is a lucrative market for peddlers of feel-good "solutions"
>that do not make anything secure but have miles-long feature lists that
>can be used to impress PHBs. Now, I have no particular problems with
>people who help suckers part with their money, but I don't see any reason
>to support them.
>
>3 or 4 patches that might be interesting would be better off without LSM.
>The rest... care to give a hard evidence that it is worth any support?
>
The SELinux and DTE modules provide a similar form of security, but with
different trade-offs between expressivenes and complexity. *Not* forcing
a specific choice in this space on users was a major reason Linus
rejected SELinux as a patch, and instead suggested enhancing the module
interface.
There is GOBS of evidence that mandatory access control enhances
security. But there is also gobs of evidence that mandatory access
control is a huge pain in the ass to manage, leading to a huge plethora
of different access control models. Being able to choose your model to
suit your needs & circumstances, or choose none at all, was another
reason for implementing an interface instead of a specific set of features.
Crispin
Crispin Cowan <[email protected]> writes:
> Could you elaborate on why this is a sign of trouble, design wise?
David refers to the 32bit emulation issues. Some ports have a 64bit
kernel, but support 64bit and 32bit userland (e.g. ia64 or x86-64).
Some ports even only have 32bit userland but 64bit kernel (like sparc64 or
mips64)
The 32bit and the 64bit worlds have different data types. Structure
layout are different. To handle this the kernel has an emulation
layer that converts the arguments of ioctls and system calls between
32bit and 64bit.
This emulation layer sits at the 'edge' of the kernel. For example
to convert an ioctl it first figures out the ioctl, converts it
then reissues the same ioctl internally with 64bit arguments. When
the ioctl returns outgoing arguments are converted too as needed.
For this to work all data structures need to be transparent.
The emulation layer needs to have a way to figure out what and
how to convert without looking at internal state in the kernel.
Otherwise it cannot do its job.
Without working emulation sparc64 won't work and David will be unhappy.
-Andi
Andi Kleen wrote:
>Crispin Cowan <[email protected]> writes:
>
>
>>Could you elaborate on why this is a sign of trouble, design wise?
>>
>>
>David refers to the 32bit emulation issues. Some ports have a 64bit
>kernel, but support 64bit and 32bit userland (e.g. ia64 or x86-64).
>Some ports even only have 32bit userland but 64bit kernel (like sparc64 or
>mips64)
>
Thank you very much for clarifying.
>The 32bit and the 64bit worlds have different data types. Structure
>layout are different. To handle this the kernel has an emulation
>layer that converts the arguments of ioctls and system calls between
>32bit and 64bit.
>
>This emulation layer sits at the 'edge' of the kernel. For example
>to convert an ioctl it first figures out the ioctl, converts it
>then reissues the same ioctl internally with 64bit arguments. When
>the ioctl returns outgoing arguments are converted too as needed.
>
>For this to work all data structures need to be transparent.
>The emulation layer needs to have a way to figure out what and
>how to convert without looking at internal state in the kernel.
>Otherwise it cannot do its job.
>
>Without working emulation sparc64 won't work and David will be unhappy.
>
I'm all for 64-bit support, and for easy transition from 32 to 64 bits.
Really: I was around to watch the pain of transition from 16 bits to 32
bits, and I'm thrilled to see people taking the problem more seriously
this time.
So: does it help to specify that the sys_security arguments be (say)
"unsigned int"? Then you can just zero-pad them, or truncate them.
And even if the 32bit emulation layer doesn't perfectly translate the
sys_security arguments: that just breaks LSM modules. It would not
surprise me that something like an application trying to talk to a
security module might not cleanly port from 32 to 64 bits. By carefully
stating the assumptions (clean data types) most of these problems should
be addressed.
I don't get why this is a hard problem.
Crispin
On Fri, Oct 18, 2002 at 02:36:31AM -0700, Crispin Cowan wrote:
> So: does it help to specify that the sys_security arguments be (say)
> "unsigned int"? Then you can just zero-pad them, or truncate them.
Yes that works fine.
But the problem is when people pass pointers to structures and
copy_*_user them later. And they near always do. Structures need to be
converted when they contain pointers or long long (on x86-64/ia64 long
long has different alignment than ia32 long long)
>
> And even if the 32bit emulation layer doesn't perfectly translate the
> sys_security arguments: that just breaks LSM modules. It would not
> surprise me that something like an application trying to talk to a
> security module might not cleanly port from 32 to 64 bits. By carefully
The application does not need to be ported. That's the whole point
of the emulation layer. Just the in kernel stuff needs to be.
> stating the assumptions (clean data types) most of these problems should
> be addressed.
You can specify clean data types. But it's very likely that eventually
someone fucks up and adds something that needs to be translated
(at least it's very likely with such an 'designed to be extensible'
interface like you have)
And then having a basic design that makes translation impossible would
be unfortunate.
-Andi
On Fri, 18 Oct 2002 11:25, Andi Kleen wrote:
> Crispin Cowan <[email protected]> writes:
> > Could you elaborate on why this is a sign of trouble, design wise?
>
> David refers to the 32bit emulation issues. Some ports have a 64bit
> kernel, but support 64bit and 32bit userland (e.g. ia64 or x86-64).
For such ports would we need to have security system calls operating in both
64bit and 32bit versions? For SE Linux half the programs that use the SE
system calls are specific to SE Linux (loading policy, showing or toggling
"enforcing mode", etc), the other half are modified versions of ls, ps, cron,
login, and a few other important system programs.
I can't imagine why you would want to use a 32bit policy loading program on a
64bit SE kernel.
As for cron etc, is it going to be difficult to get those programs compiled
for 64bit operation?
> Some ports even only have 32bit userland but 64bit kernel (like sparc64 or
> mips64)
So for those ports we could have a straight 32bit interface and again have no
problems.
> The 32bit and the 64bit worlds have different data types. Structure
> layout are different. To handle this the kernel has an emulation
> layer that converts the arguments of ioctls and system calls between
> 32bit and 64bit.
Which is terribly ugly.
I agree with the point about not wanting to be converting between 32bit and
64bit for the LSM calls. However I am not certain that we need to support
both 32bit and 64bit interfaces to LSM on the same platform.
--
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
[this is a re-post here of something I earlier sent to the LSM mailing list]
Alexander Viro wrote:
>As for "highly secure"... Could we please
>see some proof? Clearly stated properties with code audit to verify them
>would be nice.
There has been some work done on automated analysis of the LSM hooks
to verify that hooks are placed everywhere they are needed, and LSM
benefitted from this. See, e.g.,
http://www.usenix.org/publications/library/proceedings/sec02/zhang.html
>I'm yet to see a single shred of evidence that so-called security improvements
>actually do improve security (as opposed to feeling of security - quite
>a different animal).
Adding LSM support to the kernel does not itself improve security.
However, LSM support enables modules to add security. And yes, there
are some substantial security wins available here.
Are you familiar with privilege separation in SSH? One of the promises
of LSM is that it provides a way that we could systematically apply
privilege separation to many (or all) of our security-critical apps.
Existing mechanisms in the OS are too coarse-grained to be adequate for
privilege separation; LSM gives us a way to change all that. This would
be a big improvement in security.
I've never been shy of criticizing feel-good solutions. LSM is not a
feel-good solution; it's a real step forward.
This really is real stuff. This is not snake oil. Honest.
> For such ports would we need to have security system calls operating in both
> 64bit and 32bit versions? For SE Linux half the programs that use the SE
> system calls are specific to SE Linux (loading policy, showing or toggling
> "enforcing mode", etc), the other half are modified versions of ls, ps, cron,
> login, and a few other important system programs.
On most 64bit ports it is no big issue, just a nuisance. But sparc64 and
mips64 don't have a 64bit userland, only 32bit. For these it is a showstopper.
> > Some ports even only have 32bit userland but 64bit kernel (like sparc64 or
> > mips64)
>
> So for those ports we could have a straight 32bit interface and again have no
> problems.
So you want to maintain an own interface for sparc64? That's identical
to an emulation layer effectively, but somewhat less maintainable.
-Andi
On Fri, 18 Oct 2002 09:28, Alexander Viro wrote:
> As for "highly secure"... Could we please
> see some proof? Clearly stated properties with code audit to verify them
> would be nice.
>
> I'm yet to see a single shred of evidence that so-called security
> improvements actually do improve security (as opposed to feeling of
> security - quite a different animal). And in this case burden of proof is
> clearly on your side.
Some people at IBM are working on analysis of SE Linux policy to prove that it
does what it is supposed to do. The benefits of MAC as a general concept are
well documented.
For real-world examples of the benefits of SE Linux:
With the recent terrible PAM bug, in a default Debian setup you could login as
"man" and then replace the man program (owned by user "man") with a trojan
(and wait for root to read a man page). With a default SE Linux setup the
man binary is in bin_t and the default SE Linux role (which is applied to the
"man" account) is not permitted to write to it. Of course setting the file
to be immutable or configuring the man-db package for the man program to not
be SUID would get the same result, but that's not generally done. Also it
should be noted that there's an infinite number of potential attacks,
removing access that's not needed is the best way to address them.
The recent Apache SSL exploit gave attackers the full access rights of the
Apache process, and the recent scoreboard Apache bug allowed someone who can
write to Apache data the ability to send a signal to any process. Taking
advantage of both bugs a remote attacker could send a signal to any process
(including root). With SE Linux Apache only gets control over it's own
cgi-bin scripts and it's own processes. It can kill itself and some of it's
children, but that's all. It can't interfere with other daemons or user
processes.
After the recent ssh bug the default SE Linux policy was changed to not allow
sshd_t to transition directly to priviledged domains. So the next time sshd
is broken the worst you can do with a default SE Linux machine is to login as
user_r (which allows you to kill any user processes and write to any user
files but not kill daemons, change system configuration, or read
/etc/shadow). You could configure a SE Linux system to have ssh log you in
with a role that is only allowed to transition to the real role (which
requires password authentication) not actually do anything useful. So then
if sshd is cracked the attacker can't directly do anything useful. Of course
this still wouldn't solve the problem of sshd being trojaned...
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
On Fri, Oct 18, 2002 at 11:25:02AM +0200, Andi Kleen wrote:
>
> The 32bit and the 64bit worlds have different data types. Structure
> layout are different. To handle this the kernel has an emulation
> layer that converts the arguments of ioctls and system calls between
> 32bit and 64bit.
>
> This emulation layer sits at the 'edge' of the kernel. For example
> to convert an ioctl it first figures out the ioctl, converts it
> then reissues the same ioctl internally with 64bit arguments. When
> the ioctl returns outgoing arguments are converted too as needed.
>
> For this to work all data structures need to be transparent.
> The emulation layer needs to have a way to figure out what and
> how to convert without looking at internal state in the kernel.
> Otherwise it cannot do its job.
Why not let the security module supply the information about the
struct layout?
I'm thinking of something roughly like stdarg.h, e.g.
#include <linux/user_args.h>
user_args args;
user_args_start(&args, ptr);
where args is some variable where user_args can save internal state
and ptr is the pointer to the struct from userland (which is
translated appropriately to a kernel space pointer; maybe also a size
argument might be handy, so that you can copy the struct from
userspace memory to kernel memory at once instead of accessing user
address space for every struct member individually), then
struct.longlongmember = user_args_get(&args, long long);
which applies the right alignment, translates 32bit to 64bit etc.
Due to complexity probably one wants to restrict that to a set of
common types instead of making it full generic (and e.g. use something
like user_args_get_longlong() instead of the type argument), but I
don't think this would be a serious restriction (you can always extend
it later if you really need another type to get through).
This wouldn't work on an architecture where members following later in
a struct could affect the alignment of previous members, but are there
any (sane) architectures around where this is the case? Personally I
can't think of any reason why one possibly wanted to do that...
Andreas
--
Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
---------------------------------------------------------
+49 521 1365800 - [email protected] - http://www.devcon.net
On Fri, Oct 18, 2002 at 12:04:00AM -0700, Crispin Cowan wrote:
> >I know. but hiding them doesn't make them any better..
> >
> Actuall, yes it does, and that is the point. You don't have to like
> SELinux's system calls, or any other module's syscalls. The whole point
> of LSM was to decouple security design from the Linux kernel development.
But I dislike the notation of module syscalls. Syscalls are a global
thing and they shall not be registered without proper review from
all kernel developers. Driver development is untangled from kernel
development, too and it doesn;t need syscalls.
> There are a butt-load of different access control models, and many of
> them are not compatible with one another. You wouldn't want to support
> them all--that would be serious bloat. So instead, LSM lets each user
> choose the model that suits them:
Fucking no! Don't add syscall interfaces without review. Adding
a new syscall for a "security modules" is sign that you got
your design wrong.
> * server users can choose a highly secure model
> * workstation users can choose something desktop oriented
> * embedded people can choose nothing at all, or the specific
> narrow-cast model that they need
Blah, blah, blah. You don't get more security by pluggin in a buggy
module.
> On the other hand: what is the big cost here? One system call. Isn't
> that actually *lower* overhead than the (say) half dozen
> security-oriented syscalls we might convince you to accept if we drop
> the sys_security syscall as you suggest? Why the fierce desire to remove
> something so cheap?
It's the broken design. Look at windows: it has tons of cheap
features - and exactly because of that it's such a piece of crap.
On Fri, Oct 18, 2002 at 01:31:35AM -0700, Crispin Cowan wrote:
> That's interesting. Passing a completely opaque value (actually an
> integer) through the system call was exactly what we designed it to do,
> because we saw a design need for pecisely that: so that applications
> with awareness of a specific module can talk to the module.
>
> Could you elaborate on why this is a sign of trouble, design wise?
Because we already have such a syscall (ioctl) and we see the trouble it
causes all over the place. Design yur interfaces properly instead.
> >If we do things such as the fs stacking or fs filter ideas,
> >that eliminates a whole swath of the facilities the security_ops
> >"provide". No ugly syscalls passing opaque types through the kernel
> >to some magic module, but rather a real facility that is useful
> >to many things other than LSM.
> >
> Yes, that will be wonderful. And the LSM team will be pleased to re-work
> the desing when stackable file systems appear and we can take advantage
> of them.
So do it know. It's possible and it just shows you've sent the LSM crap
without actually thinking about a better design. Come back when you
have a proper design.
and btw, as LSM is part of the kernel anyone can and will change it.
Your LSM team attitude is a bit like that hated CVS mentality..
On Fri, Oct 18, 2002 at 02:02:19AM -0700, Crispin Cowan wrote:
> * root may not follow non-root symlinks in certain circumstances
> (prevent some temp file attacks)
> * non-root may not create a hard-link to root-owned files in certain
> circumstances (prevent some other temp file attacks)
> * may not ptrace root processes (preventing further recurrance of
> the bugs in ptrace over the last year or so)
>
> These policies help a lot to secure a system. But these policies also
> break some things, so it is good that they be a loadable module, and not
> a proposed Linux patch.
All three are actually very good examples on how your "Security"
modules work around problems instead of fixing thev actual cause.
Instead of adding hacks for tempfile races you rather want to
give each user a private namesapace and it's own /tmp (IMHO
we should also get rid of symlinks entirely, but they're in too wide
use nowdays unfortunately).
And ptrace _really_ _really_ needs to be replaced by a sane debug
interface, like the plan9 procfs-based debugging.
But instead of attaking these causes security folks like wirex just
implement fuzzy busword mechanisms that are selable to managers.
On Fri, Oct 18, 2002 at 01:00:34AM -0700, Crispin Cowan wrote:
> If you remove this system call, you will save almost nothing in kernel
> resources, but do a lot of damage to functionality.
But I remove an extensible, very broken interface before it's too late.
On Fri, Oct 18, 2002 at 01:10:58AM +0200, Andreas Steinmetz wrote:
> David S. Miller wrote:
> > I'm now leaning more towards something like what Al Viro
> > hinted at earlier, creating generic per-file/fd attributes.
> > This kind of stuff.
> >
> I'm perfectly happy with anything that doesn't kill LSM.
What about maintaining it out-of-tree? That's the most widely used
way to keep crap alive..
On Thu, Oct 17, 2002 at 04:08:55PM -0700, David S. Miller wrote:
> From: Chris Wright <[email protected]>
> Date: Thu, 17 Oct 2002 16:04:36 -0700
>
> the photographer would like it if the mp3 player can't remove files
> in ~/photos/ when it plays a malicious .mp3 file.
>
> LSM doesn't provide anything in this area which can't be done
> today. You can protect that directory from malicious programs
> today with file/dir protections and running programs with a different
> capability set or even with a different euid/egid for file accesses.
Ok - now I'm surprised.
How do I prevent my Evolution from reading
Projects/top-secret-stuff/main.c ?
I mean, my emacs should still be able to read it of course, and su'ing
to fifty different users for each of the fifty applications I usually
run is not really an option of course.
Please enlighten me :)
--
................................................................
: [email protected] : And I see the elder races, :
:.........................: putrid forms of man :
: Jakob ?stergaard : See him rise and claim the earth, :
: OZ9ABN : his downfall is at hand. :
:.........................:............{Konkhra}...............:
On Fri, Oct 18, 2002 at 01:52:43PM +0100, Christoph Hellwig wrote:
> and btw, as LSM is part of the kernel anyone can and will change it.
> Your LSM team attitude is a bit like that hated CVS mentality..
Please don't assume Crispin's attitude represents anyone but himself.
Not being a kernel developer, he makes statements that occasionally
offend pretty much everyone here (yesterday's gpl issue was a nice
example of that :)
I understand anyone can change the code, and am glad to see that, it
helps everyone out in the end.
thanks,
greg k-h
On Fri, 18 Oct 2002 14:05:43 BST, Christoph Hellwig said:
> All three are actually very good examples on how your "Security"
> modules work around problems instead of fixing thev actual cause.
OK.. I'll grant that a lot of things done here are fixing the fact that
there are some really fundamental botches in the Linux kernel, such as
the fact that there isn't a long history of Posix-capability flavor
separation (so processes need to start as root just so they can bind
a low-number port - blech).
Would fixing *ALL* of that history (and all the userspace crap that has
grown on top of it) be *LESS* invasive/disruptive than what LSM does?
Do you have a projected timeline of when this mythical "all the warts in the
kernel are fixed and all the userspace cruft is cleaned up" world will happen?
I'd like some sort of reasonable estimate, so I know whether this will be
before or after I retire. (While we're at it, can we reverse the definition
of the 'r' and 'x' permissions on directories, so 'umask 037' doesn't result
in directories with borked permissions? I'm actually somewhat serious here -
this is the sort of thing that will need to be cleaned up and fixed all over
the place...)
> Instead of adding hacks for tempfile races you rather want to
> give each user a private namesapace and it's own /tmp (IMHO
> we should also get rid of symlinks entirely, but they're in too wide
> use nowdays unfortunately).
Symlinks are in too wide use, and too much code knows about them - yes,
it might be nice if we threw symlinks out the window and replaced them with
a union-mount scheme. But would that be any less disruptive than what LSM does?
> And ptrace _really_ _really_ needs to be replaced by a sane debug
> interface, like the plan9 procfs-based debugging.
Yes. But would that be less disruptive than what LSM does?
> But instead of attaking these causes security folks like wirex just
> implement fuzzy busword mechanisms that are selable to managers.
The part you're missing here is that the "fuzzy buzzword mechanism" is
deployable *NOW*, and will provide *real benefits* *NOW*, rather than having
to wait for the 2.7 or 3.1 or whatever kernel.
And before you go off on the "but a lot of these can be circumvented" tangent,
I'll point out that almost *NOTHING* is totally secure. Yes, there are a
number of ways to defraud my bank. This doesn't mean that my bank is remiss
in making sure that *one class* of attacks (for instance, physical attacks
on ATM machines) isn't sufficiently protected against. Yes, my signature
can be forged - but my bank still has a signature card on file.
Which is more easily sellable to managers:
1) "We could deploy extended attributes and ACLs, except that they're not
supported yet on the filesystem that would otherwise be most suited. Once
they're integrated into that filesystem it will be great, but we're not sure
which release of the kernel it will happen in, or when that will be. And once
it DOES get supported, we don't have any guarantee that some clever person
won't find a way around the permissions that the kernel maintainer(*) isn't
allowed to explain to us, like we've seen at least once already that we know
of. Oh, and if the facilities provided don't match our business model,
we're stuck maintaining local patches or changing our business model".
2) "We could deploy an LSM module, that will work no matter WHAT filesystem
we're using. It's there for the current kernel, and although there's always
the chance that some clever person will find a way to end-run our module and
bypass it, it's equally likely that the same clever person will find some
OTHER silly bug elsewhere in the kernel that lets them bypass everything.
Oh, and we can tailor the restrictions to fit *OUR* business model and the
threats *we* feel are important."
(*) Apologies to Alan Cox here - I actually think he did The Right Thing, and
the actual bugs weren't his fault. The point here is that we've seen a *LOT*
more security problems caused by simple *BUGS* than we have by any hypothetical
"the LSM model doesn't secure 100% of the cases, so it's breakable and totally
useless" problems.
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
On Fri, Oct 18, 2002 at 11:14:14AM -0400, [email protected] wrote:
> OK.. I'll grant that a lot of things done here are fixing the fact that
> there are some really fundamental botches in the Linux kernel, such as
> the fact that there isn't a long history of Posix-capability flavor
> separation (so processes need to start as root just so they can bind
> a low-number port - blech).
>
> Would fixing *ALL* of that history (and all the userspace crap that has
> grown on top of it) be *LESS* invasive/disruptive than what LSM does?
It would most certainly not be less invasive. But that's okay.
We want stuff fixed properly, not least invasive.
> Do you have a projected timeline of when this mythical "all the warts in the
> kernel are fixed and all the userspace cruft is cleaned up" world will happen?
It depends on how many people actually work on it..
> I'd like some sort of reasonable estimate, so I know whether this will be
> before or after I retire. (While we're at it, can we reverse the definition
> of the 'r' and 'x' permissions on directories, so 'umask 037' doesn't result
> in directories with borked permissions? I'm actually somewhat serious here -
> this is the sort of thing that will need to be cleaned up and fixed all over
> the place...)
I dount you can change the meaning of the mod bits ever. Adding something
like a umask for directories (dmask) might be possible, though.
> The part you're missing here is that the "fuzzy buzzword mechanism" is
> deployable *NOW*, and will provide *real benefits* *NOW*, rather than having
> to wait for the 2.7 or 3.1 or whatever kernel.
By messing up the kernel. Note that I don't want to steal you your
code - deploy it if you want, but don't harm the mainline kernel with it.
On Fri, 18 Oct 2002 17:18, Christoph Hellwig wrote:
> > The part you're missing here is that the "fuzzy buzzword mechanism" is
> > deployable *NOW*, and will provide *real benefits* *NOW*, rather than
> > having to wait for the 2.7 or 3.1 or whatever kernel.
>
> By messing up the kernel. Note that I don't want to steal you your
> code - deploy it if you want, but don't harm the mainline kernel with it.
So how does it harm the mainline kernel to have a system call reserved for LSM
and then not allow anything in the mainline kernel that uses it? Then we can
deploy modules using the current LSM design without harming the mainline
kernel.
The only code that we really want to see in the mainline kernel is the hooks
for permission checks. Personally I would not mind if no security module
ever gets included in Linus' source tree.
Disclaimer: This message is my own opinion, even if I was part of "team LSM"
I would not be representing them in this issue.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
On Fri, Oct 18, 2002 at 06:30:28PM +0200, Russell Coker wrote:
> So how does it harm the mainline kernel to have a system call reserved for LSM
> and then not allow anything in the mainline kernel that uses it? Then we can
> deploy modules using the current LSM design without harming the mainline
> kernel.
IT adds infrastructure to implement syscalls without peer review.
End then it ends beeing crap like the selinux syscalls.
> The only code that we really want to see in the mainline kernel is the hooks
> for permission checks. Personally I would not mind if no security module
> ever gets included in Linus' source tree.
And exactly these hooks harm. They are all over the place, have performance
and code size impact and mess up readability. Why can't you just maintain
an external patch like i.e. mosix folks that nead similar deep changes?
On Fri, 18 Oct 2002 17:14, [email protected] wrote:
> Do you have a projected timeline of when this mythical "all the warts in
> the kernel are fixed and all the userspace cruft is cleaned up" world will
> happen? I'd like some sort of reasonable estimate, so I know whether this
> will be before or after I retire. (While we're at it, can we reverse the
> definition of the 'r' and 'x' permissions on directories, so 'umask 037'
> doesn't result in directories with borked permissions? I'm actually
> somewhat serious here - this is the sort of thing that will need to be
> cleaned up and fixed all over the place...)
A "dmask" sounds like a really good idea!
> > Instead of adding hacks for tempfile races you rather want to
> > give each user a private namesapace and it's own /tmp (IMHO
> > we should also get rid of symlinks entirely, but they're in too wide
> > use nowdays unfortunately).
>
> Symlinks are in too wide use, and too much code knows about them - yes,
> it might be nice if we threw symlinks out the window and replaced them with
> a union-mount scheme. But would that be any less disruptive than what LSM
> does?
We will never get rid of symlinks. Make a change like that and the result
will not be recognisable as Unix.
In any case it only solves a part of the problem. Any time that a program can
be tricked into writing to the wrong file by a symlink attack it could be
tricked into writing to the wrong file by a buffer overflow.
> 1) "We could deploy extended attributes and ACLs, except that they're not
> supported yet on the filesystem that would otherwise be most suited. Once
> they're integrated into that filesystem it will be great, but we're not
> sure which release of the kernel it will happen in, or when that will be.
> And once it DOES get supported, we don't have any guarantee that some
> clever person won't find a way around the permissions that the kernel
> maintainer(*) isn't allowed to explain to us, like we've seen at least once
> already that we know of. Oh, and if the facilities provided don't match
> our business model, we're stuck maintaining local patches or changing our
> business model".
You forgot to mention that migrating to an extended attribute based system
would have to wait until there is a release kernel supporting it (2.6 at the
earliest).
Also there's another problem, we need to create files, directories, and device
nodes with the permission set as an atomic operation. Until it's possible to
create a file system object with some EAs already set then they can not be
used for what we are doing.
--
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
I think, if you are going to reserve a system-call for "security",
all you need is one. And, I think you need to reserve one.
By default, it calls a dummy procedure that just returns "okay".
The security folks can write a module that interfaces with this
one security-hook. You only need one such hook because a system
call can get a pointer to some structure that tells it what to
do. You don't need "N" system calls, only one.
Such a simple hook is quite likely the way-to-go. No cruft in
the kernel, and upon some reported error, the development people
can say; "Unload the security module and see if you still have
the error..."
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.
On Fri, Oct 18, 2002 at 05:33:39PM +0100, Christoph Hellwig wrote:
>
> And exactly these hooks harm. They are all over the place, have performance
> and code size impact and mess up readability. Why can't you just maintain
> an external patch like i.e. mosix folks that nead similar deep changes?
They do not have performance impacts (with the minor exception of
networking, which has been talked about before), and now they do not
have any size impact. As for readability, that is also not an issue.
And no, we do not want to maintain an external patch, as that's not what
this project is about. At the first kernel summit, Linus said he wanted
this patch to allow people to pick their own security model (so we
didn't have to end up with SELinux as a default, vs. LIDS, vs.
SubDomain, vs. whatever.) At the second kernel summit, this patch was
again talked about, and was stated that it would be accepted, as we met
the goals initially talked about (mediation of kernel objects, not
syscalls or auditing.)
The whole idea of this patch is for it to be in the kernel, having it
external, doesn't help anyone out, they might as well just do their own
thing, like they were doing before.
Now there is no size impact, and no performance impact if you disable
the config option (which is the default right now!) I'm all for
dropping the syscall too, if the SELinux people, or someone else doesn't
speak up as to why they really need it. The hooks have a real design
and purpose, as we've constantly pointed out in our documentation, and
they have been validated by others in their USENIX papers.
I know you've never liked this patch, I'm sorry. Lots of other people
do :)
thanks,
greg k-h
On Fri, 18 Oct 2002 18:33, Christoph Hellwig wrote:
> On Fri, Oct 18, 2002 at 06:30:28PM +0200, Russell Coker wrote:
> > So how does it harm the mainline kernel to have a system call reserved
> > for LSM and then not allow anything in the mainline kernel that uses it?
> > Then we can deploy modules using the current LSM design without harming
> > the mainline kernel.
>
> IT adds infrastructure to implement syscalls without peer review.
It is no easier to add syscalls without peer revies in the LSM model than it
is to add them directly. LSM merely avoids the risk of syscall conflict.
Adding syscalls without review starting at a number 1000 greater than the
current highest syscall should remove the risk of number conflict to merely a
risk of patch conflict.
Removing the LSM syscall does not remove this problem.
> > The only code that we really want to see in the mainline kernel is the
> > hooks for permission checks. Personally I would not mind if no security
> > module ever gets included in Linus' source tree.
>
> And exactly these hooks harm. They are all over the place, have
> performance and code size impact and mess up readability. Why can't you
> just maintain an external patch like i.e. mosix folks that nead similar
> deep changes?
One problem with maintaining an external patch that makes lots of deep changes
is that any patch of note will conflict with it. For most people who use
such patches that's a huge problem. I'm not a great kernel coder, so most of
the kernel coding that I do is involved with resolving such patches not
actually doing anything interesting. I'd prefer to be able to spend that
time on other tasks, which would include working on some of the issues with
coreutils we discussed.
If we remove make-work tasks from other programmers (such as repeated work to
keep a patch up to date and in-sync with other patches) then they can spend
their time productively on other tasks.
Another issue with LSM is that it's not as easy to test as Mosix. With Mosix
you can test that everything works, although these tests may not be easy
(Mosix is complex) they can give a satisfactory result. For security you
can't test it in an authoritative fashion, if a certain parameter to a
syscall results in a permission check being skipped you can't determine this
by testing. Part of the solution to this is to have the LSM code in the
mainline kernel so we are all working on the same version. Another part is
the ongoing research that IBM people are performing on validating kernel
hooks.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
On Fri, 18 Oct 2002, Christoph Hellwig wrote:
> It adds infrastructure to implement syscalls without peer review.
> And then it ends being crap like the selinux syscalls.
Yes, I think you've made your point. Go ahead, remove sys_security.
We can look into revising the SELinux syscalls, hopefully with some
constructive suggestions from people, to make them more acceptable.
Feel free to send specific suggestions, or at least explain further why
you hate the current ones.
> And exactly these hooks harm. They are all over the place, have performance
> and code size impact and mess up readability. Why can't you just maintain
> an external patch like i.e. mosix folks that nead similar deep changes?
LSM only came into existence based on Linus' statements about what he
would be willing to consider for inclusion in the mainstream kernel. Of
course, if LSM has diverged from Linus' expectations, then that divergence
should be corrected. But that doesn't mean that LSM should be dropped out
entirely, just pruned and refined. If the whole of LSM has to be
maintained as a separate patch, then the various security projects have
largely wasted their time transitioning to it.
--
Stephen D. Smalley, NAI Labs
[email protected]
On Fri, 18 Oct 2002, Russell Coker wrote:
> The only code that we really want to see in the mainline kernel is the hooks
> for permission checks. Personally I would not mind if no security module
> ever gets included in Linus' source tree.
I'd disagree. I would like to see selinux included in the mainstream
kernel someday, but I know that selinux needs quite a bit of work
(Christoph says "rewrite") to make it acceptable. It also doesn't make
much sense to submit selinux until after the remainder of LSM has been
submitted for possible merging and after some level of pruning
and refinement of LSM has occurred. I would also expect other security
modules, e.g. DTE, to be submitted by their authors eventually. If there
aren't any in-tree users of LSM, then there is little motivation for the
kernel developers to retain LSM.
--
Stephen D. Smalley, NAI Labs
[email protected]
On Fri, 18 Oct 2002, Russell Coker wrote:
> I agree with the point about not wanting to be converting between 32bit
> and 64bit for the LSM calls. However I am not certain that we need to
> support both 32bit and 64bit interfaces to LSM on the same platform.
You'll only need to support it if you insist on keeping
sys_security in the kernel ;)
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
Am Fre, 2002-10-18 um 00.51 schrieb David S. Miller:
> The vast majority of desktop computers today ship with gigabit
> ethernet interfaces on the motherboard.
Don't know where you got your figures from but I've yet to see a single
complete desktop computer based on ix86 which ships with 1000TX. Sure
one can get the motherboards on the market and then there are also
Apples which have had it for quite some time now, but "majority" is this
not... maybe a good case for a different kind of minority report....
--
Servus,
Daniel
Christoph Hellwig wrote:
>And exactly these hooks harm. They are all over the place, have performance
>and code size impact and mess up readability. Why can't you just maintain
>an external patch like i.e. mosix folks that nead similar deep changes?
Actually, this is not an accurate description of LSM. As you may know,
the LSM hooks do not have a noticeable performance impact (with the
exception of 1Gb networking, where I believe there is a 1-2% slowdown).
This has been pointed out several times before, and the LSM folks have
posted a pointer to the measurements.
* Stephen Smalley ([email protected]) wrote:
>
> On Fri, 18 Oct 2002, Christoph Hellwig wrote:
>
> > It adds infrastructure to implement syscalls without peer review.
> > And then it ends being crap like the selinux syscalls.
>
> Yes, I think you've made your point. Go ahead, remove sys_security.
Looks like we should remove this. The interface is awkward, and there
are many examples of how it's not needed and is broken by design. I know
SubDomain can get by without it.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Greg KH wrote:
>On Fri, Oct 18, 2002 at 01:52:43PM +0100, Christoph Hellwig wrote:
>
>
>>and btw, as LSM is part of the kernel anyone can and will change it.
>>Your LSM team attitude is a bit like that hated CVS mentality..
>>
>>
>Please don't assume Crispin's attitude represents anyone but himself.
>Not being a kernel developer, he makes statements that occasionally
>offend pretty much everyone here (yesterday's gpl issue was a nice
>example of that :)
>
I apologize to anyone I may have offended in the course of these
discussions.
WRT the "LSM Team", I meant that there is a group of people who want LSM
to succeed, and will work on overcoming issues to make it succeed. It
was never intended to be exclusionary in any way.
Thanks,
Crispin
On Thu, 2002-10-17 at 21:10, Greg KH wrote:
> Ok, I think it's time for someone who actually cares about the security
> syscall to step up here to try to defend the existing interface. I'm
> pretty sure Ericsson, HP, SELinux, and WireX all use this, so they need
> to be the ones defending it.
The existing interface is basically the one Linus asked for, although
perhaps with a little less thought on the structure side than it would
have benefitted
----- Original Message -----
From: Stephen Smalley <[email protected]>
To: Christoph Hellwig <[email protected]>
Cc: <[email protected]>; <[email protected]>
Sent: 18 October 2002 18:15
Subject: Re: [PATCH] remove sys_security
>
> On Fri, 18 Oct 2002, Christoph Hellwig wrote:
>
> > It adds infrastructure to implement syscalls without peer review.
> > And then it ends being crap like the selinux syscalls.
>
> Yes, I think you've made your point. Go ahead, remove sys_security.
> We can look into revising the SELinux syscalls, hopefully with some
> constructive suggestions from people, to make them more acceptable.
> Feel free to send specific suggestions, or at least explain further why
> you hate the current ones.
>
I'm not sure the case for removal has been made. Some potential problems
with the LSM security syscall have been pointed out. Isn't it better to
consider
fixes instead of ditching the syscall? Won't the absence of the syscall just
result
in even worse code being used? Presumably SELinux will have to implement
the syscall functionality some other way.
> > And exactly these hooks harm. They are all over the place, have
performance
> > and code size impact and mess up readability. Why can't you just
maintain
> > an external patch like i.e. mosix folks that nead similar deep changes?
>
> LSM only came into existence based on Linus' statements about what he
> would be willing to consider for inclusion in the mainstream kernel. Of
> course, if LSM has diverged from Linus' expectations, then that divergence
> should be corrected. But that doesn't mean that LSM should be dropped out
> entirely, just pruned and refined. If the whole of LSM has to be
> maintained as a separate patch, then the various security projects have
> largely wasted their time transitioning to it.
>
Precisely. The whole reason for having LSM at all is that maintaining a
kernel
patch to add a security model is not sustainable. Adding a general kernel
framework to support security was the agreed way to go, and that is what
LSM does.
After the latest changes the LSM framework hurts no-one who
isn't using it, so I see no reason to ditch it. If there are
remaining problems let's fix them - not ditch the approach.
Mike
On Mon, Oct 21, 2002 at 02:54:33PM +0100, Mike Wray wrote:
> I'm not sure the case for removal has been made. Some potential problems
> with the LSM security syscall have been pointed out. Isn't it better to
> consider
> fixes instead of ditching the syscall?
The conceptual wrong design was pointed out, yes. It's not fixable
without rplacing it with a proper design of the security module entry
points.
> Won't the absence of the syscall just result
> in even worse code being used? Presumably SELinux will have to implement
> the syscall functionality some other way.
Unlike this hook there is a chance we can review their new creations when
they ask for inclusion.
From: Christoph Hellwig <[email protected]>
Sent: 21 October 2002 15:09
> On Mon, Oct 21, 2002 at 02:54:33PM +0100, Mike Wray wrote:
> > I'm not sure the case for removal has been made. Some potential problems
> > with the LSM security syscall have been pointed out. Isn't it better to
> > consider
> > fixes instead of ditching the syscall?
>
> The conceptual wrong design was pointed out, yes. It's not fixable
> without rplacing it with a proper design of the security module entry
> points.
>
I'm not sure what was conceptually wrong. There are other multiplexing
syscalls
in the kernel - so the concept of multiplexing cannot be wrong?
Or is setsockopt broken too?
If it's just the particular signature used
right now that's the problem, then that's easily fixed.
For example, what would be wrong in making the security syscall follow the
get/set sockopt approach?
> > Won't the absence of the syscall just result
> > in even worse code being used? Presumably SELinux will have to implement
> > the syscall functionality some other way.
>
> Unlike this hook there is a chance we can review their new creations when
> they ask for inclusion.
Netfilter provides nf_register_sockopt() to allow open-ended registration
of socket-opt handling by a module - without any review. So do many other
kernel interfaces.
Mike
On Mon, Oct 21, 2002 at 05:44:15PM +0100, Mike Wray wrote:
> I'm not sure what was conceptually wrong. There are other multiplexing
> syscalls
> in the kernel - so the concept of multiplexing cannot be wrong?
> Or is setsockopt broken too?
It is conceptually wrong, yes. Just because a mistake has been made
in the past there's no real reason to repeat it.
> Netfilter provides nf_register_sockopt() to allow open-ended registration
> of socket-opt handling by a module - without any review. So do many other
> kernel interfaces.
socket-opt handling does not come with different argument types.
Alan Cox wrote:
>On Thu, 2002-10-17 at 21:10, Greg KH wrote:
>
>
>>Ok, I think it's time for someone who actually cares about the security
>>syscall to step up here to try to defend the existing interface. I'm
>>pretty sure Ericsson, HP, SELinux, and WireX all use this, so they need
>>to be the ones defending it.
>>
>>
>The existing interface is basically the one Linus asked for, although
>perhaps with a little less thought on the structure side than it would
>have benefitted
>
The intent behind the syscall interface was that it needed to be generic
enough to support the 50+ syscalls that SELinux wants, and also be
generic enough to support potential modules that have not been invented
yet. That's why it is a MUX, and why the signature definition is enough
to deal with stacked modules and then pass a generic argv list to the
module itself.
Unfortunately, this design goal (highly generic interface) is
incompatible with the 32/64 bit transparancy layer that several
supported architectures need. As Christoph says, this is unfixable.
IMHO, it is unfixable because of conflicting design goals: you cannot
have a truly generic syscall interface and hope for it to port clean
from 32 bits to 64 bits.
Therefore, the sys_security syscall has been removed. LSM-aware
applications that want to talk to security modules can do so through a
file system interface. This will work for WireX, and Smalley says it
will work for SELinux. I hope it will work for others.
Again, my thanks for eveyone's help in cleaning up this issue, and my
apologies to anyone I may have offended. We should have thought about
the 32/64 bit issue when we defined that interface. Kudos to Greg K-H,
who told me that this syscall would be a problem.
Thanks,
Crispin
On Mon, Oct 21, 2002 at 02:12:50PM -0700, Crispin Cowan wrote:
>
> Therefore, the sys_security syscall has been removed.
Um, removed in what tree? Still looks like it's present in 2.5.44 :)
Ok, I'll add Christoph's patch to my other LSM hook rework patches and
queue them up for when Linus gets back from vacation.
thanks,
greg k-h
On Mon, 21 Oct 2002, Crispin Cowan wrote:
> Therefore, the sys_security syscall has been removed. LSM-aware
> applications that want to talk to security modules can do so through a
> file system interface. This will work for WireX, and Smalley says it
> will work for SELinux. I hope it will work for others.
Actually, with regard to using a pseudo filesystem interface, I said that
we could investigate it, but I have doubts about cleanly supporting the
extended forms of existing calls (e.g. execve_secure, mkdir_secure,
msgrcv_secure, recvmsg_secure, etc) using such an interface. I
raised the same issue when sys_security was originally discussed on
the lsm list long ago. SELinux extends the POSIX API to incorporate
security (specifically flexible mandatory access control) as a first class
notion.
However, I understand Christoph's objection to sys_security and am not
trying to revive that debate. We can hopefully have a dialogue about the
SELinux API with the kernel developers at a later time and come to some
consensus on a set of specific system calls that can be added to the
kernel to support equivalent functionality to the SELinux API.
--
Stephen D. Smalley, NAI Labs
[email protected]
Hi,
On Fri, Oct 18, 2002 at 12:14:16AM +0200, Russell Coker wrote:
> OK, how do you go about supplying extra data to a file open than to modify the
> open system call?
>
> If for example I want to create a file of context
> "system_u:object_r:fingerd_log_t" under /var/log (instead of taking the
> context from that of the /var/log directory "system_u:object_r:var_log_t")
> then how would I go about doing it other than through a modified open system
> call?
With a "setesid(2)" syscall to set the effective sid.
A new file already inherits a ton of context, from the current uid/gid
to the umask. Those are already selectable by setting up the current
process context. And for the uid/gid bits, we also have setfsuid to
set the id for creation without causing the whole process to suddenly
change ownership.
A similar way of setting the effective sid for new object creation
would eliminate over 20 of the new sys_security syscalls in the
SELinux patches.
--Stephen
On Wed, 23 Oct 2002 02:35, Stephen C. Tweedie wrote:
> > If for example I want to create a file of context
> > "system_u:object_r:fingerd_log_t" under /var/log (instead of taking the
> > context from that of the /var/log directory
> > "system_u:object_r:var_log_t") then how would I go about doing it other
> > than through a modified open system call?
>
> With a "setesid(2)" syscall to set the effective sid.
>
> A new file already inherits a ton of context, from the current uid/gid
> to the umask. Those are already selectable by setting up the current
> process context. And for the uid/gid bits, we also have setfsuid to
> set the id for creation without causing the whole process to suddenly
> change ownership.
Good idea, however there are two potential problems that I can see.
When creating a file the UID/GID name space for the file is the same as that
for the process. In SE Linux the name space for files to be created does not
intersect the name space of the processes. This makes it much less clean
than setfsuid().
Secondly there is the issue of a lack of atomicity. Is there a potential for
a signal handler to create a file between the setesid() and creat() in the
main code? I guess the API open_secure() could remain the same and block all
signals for it's operation...
--
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
Hi,
On Wed, Oct 23, 2002 at 01:43:55PM +0200, Russell Coker wrote:
> On Wed, 23 Oct 2002 02:35, Stephen C. Tweedie wrote:
> > > "system_u:object_r:var_log_t") then how would I go about doing it other
> > > than through a modified open system call?
> > With a "setesid(2)" syscall to set the effective sid.
> Good idea, however there are two potential problems that I can see.
>
> When creating a file the UID/GID name space for the file is the same as that
> for the process. In SE Linux the name space for files to be created does not
> intersect the name space of the processes. This makes it much less clean
> than setfsuid().
setfsuid() creates credentials which are _only_ applied to file
operations. The namespace happens to be the same one that applies to
processes, but there's nothing that requires that to be the case, and
if you have a corresponding setfssid() to set the effective set for fs
access, you're explicitly requesting the fs namespace, not the process
one.
> Secondly there is the issue of a lack of atomicity. Is there a potential for
> a signal handler to create a file between the setesid() and creat() in the
> main code? I guess the API open_secure() could remain the same and block all
> signals for it's operation...
Definitely. Application writers will need to be aware of that, just
as they have to be aware of the same for setfsuid today. But when
you've got signal handlers doing complex work, you've got all sorts of
races opening up, and trying to fix every single one of them by
inventing new syscalls for every single combination of operation that
the app might want to do atomically makes no sense!
--Stephen
On Wed, 23 Oct 2002, Stephen C. Tweedie wrote:
> setfsuid() creates credentials which are _only_ applied to file
> operations. The namespace happens to be the same one that applies to
> processes, but there's nothing that requires that to be the case, and
> if you have a corresponding setfssid() to set the effective set for fs
> access, you're explicitly requesting the fs namespace, not the process
> one.
Would we need a separate call for setting the SIDs to use for each
"namespace", i.e. fs (for open, mkdir, mknod, and symlink calls), IPC
(for semget, msgget, and shmget calls), process (for execve calls), and
socket (for socket, connect, listen, sendmsg, and sendto calls, requiring
two SIDs for send*)?
Notice that there are differences in the semantics of an fsuid vs. an fs
SID if the purpose of the fs SID is for newly created files. The fs SID
would only be used for specifying a SID other than the default transition
SID for new files, which is normally determined by the policy logic
based on a combination of the creating process' SID, the SID of the parent
directory, and the kind (security class) of file. The fs SID should not
be used as the process' effective SID in permission checks for operations
on existing files (you can't just use a file SID and a process SID
interchangeably, unlike uids). By default, the fs SID would need to be
"unset" (e.g. SECSID_NULL) to indicate that a default transition SID
should be computed; you would not have an equivalent to the default case
of fsuid == euid.
While your approach would work for calls that take input SID parameters,
what about the various calls that return SIDs either directly or via
output SID parameters, e.g. extended forms of *stat, msgrcv, recvmsg,
getpeername/accept plus new calls like (sem|shm|msg)sid and getsecsid?
--
Stephen D. Smalley, NAI Labs
[email protected]
Hi,
On Wed, Oct 23, 2002 at 10:27:27AM -0400, Stephen Smalley wrote:
> On Wed, 23 Oct 2002, Stephen C. Tweedie wrote:
> > setfsuid() creates credentials which are _only_ applied to file
> > operations. The namespace happens to be the same one that applies to
> > processes, but there's nothing that requires that to be the case
> Would we need a separate call for setting the SIDs to use for each
> "namespace", i.e. fs (for open, mkdir, mknod, and symlink calls), IPC
> (for semget, msgget, and shmget calls), process (for execve calls), and
> socket (for socket, connect, listen, sendmsg, and sendto calls, requiring
> two SIDs for send*)?
The BSD socket API already has a clean and extensible way of dealing
with multiple namespaces, so there's plenty of precedent about how to
do this without requiring multiple syscalls.
> While your approach would work for calls that take input SID parameters,
> what about the various calls that return SIDs either directly or via
> output SID parameters, e.g. extended forms of *stat, msgrcv, recvmsg,
> getpeername/accept plus new calls like (sem|shm|msg)sid and getsecsid?
Good question --- what is the reason you need these, and are other
security modules likely to need similar functionality? If so, there's
an argument for new syscalls which take a credentials/sid area as a
return argument.
--Stephen
On Wed, 23 Oct 2002, Stephen C. Tweedie wrote:
> Good question --- what is the reason you need these, and are other
> security modules likely to need similar functionality? If so, there's
> an argument for new syscalls which take a credentials/sid area as a
> return argument.
The extended *stat calls enable applications to obtain file SIDs along
with the regular file status for a variety of purposes, e.g. SELinux
provides patched versions of ls (displaying security contexts to users),
find (searching for files with particular security contexts or displaying
the contexts of files matching the find criteria to users), cp -p and tar
(preserving contexts on copies and in archives), logrotate (preserving
contexts when logs are rotated), and crond (checking the context on a
user-generated crontab spool file to protect against running cron jobs
with a given process SID from a less trusted source). While you don't
always need to get both the file status and the security attributes for a
given file, you often do for programs like ls, cp, tar, etc.
If we migrate SELinux to using extended attributes to store file security
contexts (pending their merging into 2.5), then we could replace the
extended *stat with getxattr, although getxattr doesn't provide an atomic
way of getting both the regular file status information and the security
attributes for a given file. Closest approximation to stat_secure() would
be an open(...O_RDONLY), fstat(), fgetxattr(), close() sequence to ensure
that the file status and security attributes are from the same inode, but
this assumes that you can always read the file in order to stat it and
isn't exactly ideal.
For System V IPC and socket IPC, the extended calls enable applications to
obtain security information about the sender and the data so that the
security-aware applications can make security decisions and label data
appropriately. An extended form of SCM_CREDENTIALS that supports
additional security data and is not limited to local domain sockets [the
SELinux calls work for INET sockets if labeled networking is used] might
be reasonable for socket IPC.
--
Stephen D. Smalley, NAI Labs
[email protected]
On Wed, Oct 23, 2002 at 12:09:47PM -0400, Stephen Smalley wrote:
> If we migrate SELinux to using extended attributes to store file security
> contexts (pending their merging into 2.5), then we could replace the
> extended *stat with getxattr,
extended attributes are both in 2.4.20-pre and 2.5 (for a long time).
On Wed, Oct 23, 2002 at 12:34:05PM -0400, Stephen Smalley wrote:
>
> On Wed, 23 Oct 2002, Christoph Hellwig wrote:
>
> > extended attributes are both in 2.4.20-pre and 2.5 (for a long time).
>
> I meant the merging of the EA implementations for ext[23], not just the
> EA API calls.
Why are you limited to a single fs? xfs and jfs have xattr support
out of the box (in 2.4 only jfs is actually in the mainline tree, though)
On Wed, 23 Oct 2002, Christoph Hellwig wrote:
> extended attributes are both in 2.4.20-pre and 2.5 (for a long time).
I meant the merging of the EA implementations for ext[23], not just the
EA API calls.
--
Stephen D. Smalley, NAI Labs
[email protected]
Stephen Smalley <[email protected]> writes:
> If we migrate SELinux to using extended attributes to store file security
> contexts (pending their merging into 2.5),
You can already use extended attributes in 2.5. Just not with ext2/3/reiserfs
yet, only with JFS and XFS.
-Andi
On Wed, 23 Oct 2002, Christoph Hellwig wrote:
> Why are you limited to a single fs? xfs and jfs have xattr support
> out of the box (in 2.4 only jfs is actually in the mainline tree, though)
Most of our users (and we) happen to use ext[23], so there isn't any point
in migrating SELinux to using EAs until EA implementations are merged into
those filesystems. Also, the EA API lacks support for creating files with
specified security attributes (as opposed to creating and then calling
setxattr to change the attributes, possibly after someone has already
obtained access to the file), so it isn't ideal for our purposes anyway.
--
Stephen D. Smalley, NAI Labs
[email protected]
Hello,
On Wed, Oct 23, 2002 at 12:51:08PM -0400, Stephen Smalley wrote:
> > Why are you limited to a single fs? xfs and jfs have xattr support
> > out of the box (in 2.4 only jfs is actually in the mainline tree, though)
>
> Most of our users (and we) happen to use ext[23], so there isn't any point
> in migrating SELinux to using EAs until EA implementations are merged into
> those filesystems. Also, the EA API lacks support for creating files with
> specified security attributes (as opposed to creating and then calling
> setxattr to change the attributes, possibly after someone has already
> obtained access to the file), so it isn't ideal for our purposes anyway.
This is not a shortcoming of the xattr interfaces, they do what
they were designed to do. I think the only interfaces suited to
setting up things in the way you've described are create, mkdir,
mknod, and co. It isn't clear to me how sys_security helps in
this situation? -- it would also seem to be non-atomic wrt the
inode creation syscalls, in the same way the xattr calls are.
The ACL code has to address a similar problem to the one you've
described - if a directory has a default ACL set on it, then new
children must be created with that ACL. This is implemented by
giving filesystems knowledge of the semantics of this attribute,
and having them create the ACL along with the inode if need be.
cheers.
--
Nathan
On Thu, 24 Oct 2002 08:26, Nathan Scott wrote:
> > Also, the EA API lacks support for
> > creating files with specified security attributes (as opposed to creating
> > and then calling setxattr to change the attributes, possibly after
> > someone has already obtained access to the file), so it isn't ideal for
> > our purposes anyway.
>
> This is not a shortcoming of the xattr interfaces, they do what
> they were designed to do. I think the only interfaces suited to
> setting up things in the way you've described are create, mkdir,
> mknod, and co. It isn't clear to me how sys_security helps in
> this situation? -- it would also seem to be non-atomic wrt the
> inode creation syscalls, in the same way the xattr calls are.
Currently sys_security is used to implement open_secure(), mkdir_secure(), etc
which do this atomically.
> The ACL code has to address a similar problem to the one you've
> described - if a directory has a default ACL set on it, then new
> children must be created with that ACL. This is implemented by
> giving filesystems knowledge of the semantics of this attribute,
> and having them create the ACL along with the inode if need be.
SE Linux needs that functionality, but also it needs the ability to support
file type automatic transition rules, for example when a program in fingerd_t
domain creates a file in a directory of var_log_t then the file will have
type var_log_fingerd_t. But this doesn't require any extra system calls
either.
What requires more system calls is the logrotate program which has to create
new log files with the same security context as the log file it renamed.
I suggest that you check the archives for the full thread as it explains all
this and more in detail.
--
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