Re: [PATCH] remove sys_security

Re: [PATCH] remove sys_security

[Andi Kleen]

Crispin Cowan <crispin@wirex.com> 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

Re: [PATCH] remove sys_security

[Crispin Cowan]

[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]

Andi Kleen wrote:

>Crispin Cowan <crispin@wirex.com> 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


[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [PATCH] remove sys_security

[Andi Kleen]

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

Re: [PATCH] remove sys_security

[Russell Coker]

On Fri, 18 Oct 2002 11:25, Andi Kleen wrote:
> Crispin Cowan <crispin@wirex.com> 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

Re: [PATCH] remove sys_security

[Andi Kleen]

> 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

Re: [PATCH] remove sys_security

[Andreas Ferber]

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 - af@devcon.net - www.devcon.net

Re: [PATCH] remove sys_security

[Rik van Riel]

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:"october@surriel.com">october@surriel.com</a>

Re: [PATCH] remove sys_security

[Russell Coker]

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

Re: [PATCH] remove sys_security

[Nathan Scott]

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

Re: [PATCH] remove sys_security

[Stephen Smalley]

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
ssmalley@nai.com

Re: [PATCH] remove sys_security

[Christoph Hellwig]

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)

Re: [PATCH] remove sys_security

[Stephen Smalley]

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
ssmalley@nai.com

Re: [PATCH] remove sys_security

[Andi Kleen]

Stephen Smalley <sds@tislabs.com> 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

Re: [PATCH] remove sys_security

[Christoph Hellwig]

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).

Re: [PATCH] remove sys_security

[Stephen Smalley]

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
ssmalley@nai.com

Re: [PATCH] remove sys_security

[Stephen C. Tweedie]

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

Re: [PATCH] remove sys_security

[Stephen Smalley]

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
ssmalley@nai.com

Re: [PATCH] remove sys_security

[Stephen C. Tweedie]

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

Re: [PATCH] remove sys_security

[Russell Coker]

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

Re: [PATCH] remove sys_security

[Stephen C. Tweedie]

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

Re: [PATCH] remove sys_security

[Stephen Smalley]

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
ssmalley@nai.com

Re: [PATCH] remove sys_security

[Greg KH]

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

Re: [PATCH] remove sys_security

[Crispin Cowan]

[-- Attachment #1: Type: text/plain, Size: 1778 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [PATCH] remove sys_security

[Christoph Hellwig]

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.

Re: [PATCH] remove sys_security

[Mike Wray]

From: Christoph Hellwig <hch@infradead.org>
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

Re: [PATCH] remove sys_security

[Christoph Hellwig]

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.

Re: [PATCH] remove sys_security

[Alan Cox]

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

Re: [PATCH] remove sys_security

[Mike Wray]

----- Original Message -----
From: Stephen Smalley <sds@tislabs.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: <linux-kernel@vger.kernel.org>; <linux-security-module@wirex.com>
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

Re: [PATCH] remove sys_security

[Crispin Cowan]

[-- Attachment #1: Type: text/plain, Size: 764 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [PATCH] remove sys_security

[Chris Wright]

* Stephen Smalley (sds@tislabs.com) 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

Re: [PATCH] remove sys_security

[David Wagner]

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.

Re: [PATCH] remove sys_security

[Daniel Egger]

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

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

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] remove sys_security

[Stephen Smalley]

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
ssmalley@nai.com

Re: [PATCH] remove sys_security

[Stephen Smalley]

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
ssmalley@nai.com

Re: [PATCH] remove sys_security

[Russell Coker]

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

Re: [PATCH] remove sys_security

[Greg KH]

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

Re: [PATCH] remove sys_security

[Richard B. Johnson]

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.

Re: [PATCH] remove sys_security

[Russell Coker]

On Fri, 18 Oct 2002 17:14, Valdis.Kletnieks@vt.edu 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

Re: [PATCH] remove sys_security

[Christoph Hellwig]

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?

Re: [PATCH] remove sys_security

[Russell Coker]

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

Re: [PATCH] remove sys_security

[Christoph Hellwig]

On Fri, Oct 18, 2002 at 11:14:14AM -0400, Valdis.Kletnieks@vt.edu 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.

Re: [PATCH] remove sys_security

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 4240 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH] remove sys_security

[Greg KH]

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

Re: [PATCH] remove sys_security

[Jakob Oestergaard]

On Thu, Oct 17, 2002 at 04:08:55PM -0700, David S. Miller wrote:
>    From: Chris Wright <chris@wirex.com>
>    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  :)

-- 
................................................................
:   jakob@unthought.net   : 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}...............:

Re: [PATCH] remove sys_security

[Christoph Hellwig]

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..

Re: [PATCH] remove sys_security

[Christoph Hellwig]

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.

Re: [PATCH] remove sys_security

[Christoph Hellwig]

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.

Re: [PATCH] remove sys_security

[Christoph Hellwig]

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..

Re: [PATCH] remove sys_security

[Christoph Hellwig]

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.

Re: [PATCH] remove sys_security

[Russell Coker]

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

Re: [PATCH] remove sys_security

[David Wagner]

[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.

Re: [PATCH] remove sys_security

[Crispin Cowan]

[-- Attachment #1: Type: text/plain, Size: 3477 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [PATCH] remove sys_security

[Crispin Cowan]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [PATCH] remove sys_security

[David S. Miller]

   From: Crispin Cowan <crispin@wirex.com>
   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.

Re: [PATCH] remove sys_security

[Crispin Cowan]

[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [PATCH] remove sys_security

[David S. Miller]

   From: Crispin Cowan <crispin@wirex.com>
   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.

Re: [PATCH] remove sys_security

[Alexander Viro]

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?

Re: [PATCH] remove sys_security

[Greg KH]

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

Re: [PATCH] remove sys_security

[David S. Miller]

   From: Crispin Cowan <crispin@wirex.com>
   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.

Re: [PATCH] remove sys_security

[Crispin Cowan]

[-- Attachment #1: Type: text/plain, Size: 1657 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [PATCH] remove sys_security

[Greg KH]

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

Re: [PATCH] remove sys_security

[Andreas Steinmetz]

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

Re: [PATCH] remove sys_security

[Chris Wright]

* Greg KH (greg@kroah.com) 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

Re: [PATCH] remove sys_security

[Greg KH]

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

Re: [PATCH] remove sys_security

[David S. Miller]

   From: Chris Wright <chris@wirex.com>
   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.

Re: [PATCH] remove sys_security

[Chris Wright]

* David S. Miller (davem@redhat.com) 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

Re: [PATCH] remove sys_security

[Jeff Garzik]

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

Re: [PATCH] remove sys_security

[David S. Miller]

   From: Jeff Garzik <jgarzik@pobox.com>
   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.

Re: [PATCH] remove sys_security

[David S. Miller]

   From: Andreas Steinmetz <ast@domdv.de>
   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.

Re: [PATCH] remove sys_security

[Andreas Steinmetz]

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

Re: [PATCH] remove sys_security

[David S. Miller]

   From: daw@mozart.cs.berkeley.edu (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.

Re: [PATCH] remove sys_security

[Andreas Dilger]

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/

Re: [PATCH] remove sys_security

[Greg KH]

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

Re: [PATCH] remove sys_security

[Russell Coker]

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

Re: [PATCH] remove sys_security

[Greg KH]

On Thu, Oct 17, 2002 at 01:58:32PM -0700, David S. Miller wrote:
>    From: Greg KH <greg@kroah.com>
>    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

Re: [PATCH] remove sys_security

[David S. Miller]

   From: Greg KH <greg@kroah.com>
   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.

Re: [PATCH] remove sys_security

[David Wagner]

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.

Re: [PATCH] remove sys_security

[Alexander Viro]

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".

Re: [PATCH] remove sys_security

[Russell Coker]

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

Re: [PATCH] remove sys_security

[Jeff Garzik]

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

Re: [PATCH] remove sys_security

[Russell Coker]

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

Re: [PATCH] remove sys_security

[David S. Miller]

   From: Greg KH <greg@kroah.com>
   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 :)
   
:)

Re: [PATCH] remove sys_security

[Greg KH]

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

Re: [PATCH] remove sys_security

[Russell Coker]

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

Re: [PATCH] remove sys_security

[David S. Miller]

   From: Greg KH <greg@kroah.com>
   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 :-)

Re: [PATCH] remove sys_security

[Greg KH]

On Thu, Oct 17, 2002 at 01:18:30PM -0700, David S. Miller wrote:
>    From: Greg KH <greg@kroah.com>
>    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

Re: [PATCH] remove sys_security

[Jeff Garzik]

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...

Re: [PATCH] remove sys_security

[Greg KH]

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

Re: [PATCH] remove sys_security

[Christoph Hellwig]

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.

Re: [PATCH] remove sys_security

[Russell Coker]

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

Re: [PATCH] remove sys_security

[David S. Miller]

   From: Greg KH <greg@kroah.com>
   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)

Re: [PATCH] remove sys_security

[Christoph Hellwig]

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..

Re: [PATCH] remove sys_security

[Greg KH]

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

Re: [PATCH] remove sys_security

[Christoph Hellwig]

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.

Re: [PATCH] remove sys_security

[Greg KH]

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.

Re: [PATCH] remove sys_security

[Alexander Viro]

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?

Re: [PATCH] remove sys_security

[Christoph Hellwig]

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..

Re: [PATCH] remove sys_security

[Greg KH]

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

[PATCH] remove sys_security

[Christoph Hellwig]

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);