remove sys_security

From: Crispin Cowan <[email protected]>
Date: Fri, 18 Oct 2002 00:04:00 -0700

Quoted 2 lines · Christoph Hellwig

On Thu, Oct 17, 2002 at 01:10:31PM -0700, Greg KH wrote:
I know. but hiding them doesn't make them any better..

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.

Crispin Cowan

2002-10-18 08:26 UTC #10 lore raw

Quoted 3 lines · David S. Miller

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?

Quoted 5 lines

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.

Quoted 6 lines

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

David S. Miller

2002-10-18 08:31 UTC #11 lore raw

From: Crispin Cowan <[email protected]>
Date: Fri, 18 Oct 2002 01:31:35 -0700

Could you elaborate on why this is a sign of trouble, design wise?

Bacause if you can't even specify the data types, something is severely wrong. It's entirely a black box.

That doesn't give it system call status.

Compare:

read(fd, buf, size)

This reads, from file descriptor FD, into BUF of size SIZE.

with:

	security(id, call, args)

	???

How would you describe this in a manpage, for example?

Quoted 4 lines

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.

Christoph Hellwig

author

2002-10-18 12:46 UTC #12 lore raw

Quoted 6 lines · Crispin Cowan

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.

Quoted 9 lines

Quoted 6 lines
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..

Greg KH

2002-10-18 14:58 UTC #13 lore raw

Quoted 2 lines · Christoph Hellwig

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

Crispin Cowan

2002-10-19 02:00 UTC #14 lore raw

Quoted 12 lines · Greg KH

Quoted 4 lines · Christoph Hellwig
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

Alexander Viro

2002-10-18 07:22 UTC #15 lore raw

In reply to Christoph Hellwig

Quoted 10 lines · Crispin Cowan

* 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?

Crispin Cowan

2002-10-18 08:56 UTC #16 lore raw

Quoted 8 lines · Alexander Viro

Quoted 5 lines · Crispin Cowan
* 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

Quoted 7 lines

Quoted 3 lines
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.

Quoted 5 lines

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.

Quoted 9 lines

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

Christoph Hellwig

author

2002-10-18 12:59 UTC #17 lore raw

Quoted 10 lines · Crispin Cowan

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

[email protected]

2002-10-18 15:08 UTC #18 lore raw

Quoted 2 lines · Christoph Hellwig

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

Quoted 4 lines

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?

Quoted 2 lines

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?

Quoted 2 lines

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.

Signature · 3 lines

				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

Christoph Hellwig

author

2002-10-18 15:12 UTC #19 lore raw

Quoted 8 lines · On Fri, Oct 18, 2002 at 11:14:14AM -0400, [email protected] wrote:

OK.. I'll grant that a lot of things done here are fixing the fact that there are some really fundamental botches in the Linux kernel, such as the fact that there isn't a long history of Posix-capability flavor separation (so processes need to start as root just so they can bind a low-number port - blech).
Would fixing *ALL* of that history (and all the userspace crap that has grown on top of it) be *LESS* invasive/disruptive than what LSM does?

It would most certainly not be less invasive. But that's okay. We want stuff fixed properly, not least invasive.

Quoted 2 lines

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

Quoted 6 lines

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.

Quoted 3 lines

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.

Russell Coker

2002-10-18 16:24 UTC #20 lore raw

Quoted 6 lines · Christoph Hellwig

Quoted 3 lines
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.

Signature · 4 lines

http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Christoph Hellwig

author

2002-10-18 16:27 UTC #21 lore raw

Quoted 4 lines · Russell Coker

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.

Quoted 3 lines

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?

Greg KH

2002-10-18 16:48 UTC #22 lore raw

Quoted 4 lines · Christoph Hellwig

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

Russell Coker

2002-10-18 16:49 UTC #23 lore raw

Quoted 7 lines · Christoph Hellwig

Quoted 4 lines · Russell Coker
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.

Quoted 8 lines

Quoted 3 lines
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.

Signature · 4 lines

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

Stephen Smalley

2002-10-18 17:31 UTC #24 lore raw

In reply to Christoph Hellwig

Quoted 2 lines · Christoph Hellwig

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.

Quoted 3 lines

And exactly these hooks harm. They are all over the place, have performance and code size impact and mess up readability. Why can't you just maintain an external patch like i.e. mosix folks that nead similar deep changes?

LSM only came into existence based on Linus' statements about what he would be willing to consider for inclusion in the mainstream kernel. Of course, if LSM has diverged from Linus' expectations, then that divergence should be corrected. But that doesn't mean that LSM should be dropped out entirely, just pruned and refined. If the whole of LSM has to be maintained as a separate patch, then the various security projects have largely wasted their time transitioning to it.

--
Stephen D. Smalley, NAI Labs
[email protected]

Chris Wright

2002-10-18 22:40 UTC #25 lore raw

Quoted 7 lines · * Stephen Smalley ([email protected]) wrote:

Quoted 2 lines · Christoph Hellwig
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

Signature · 1 line

Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Mike Wray

2002-10-21 13:51 UTC #26 lore raw

In reply to Stephen Smalley

----- Original Message -----
From: Stephen Smalley <[email protected]>
To: Christoph Hellwig <[email protected]>
Cc: <[email protected]>; <[email protected]>
Sent: 18 October 2002 18:15
Subject: Re: [PATCH] remove sys_security

Quoted 12 lines · Christoph Hellwig

Quoted 3 lines
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.

Quoted 1 line

Quoted 1 line
And exactly these hooks harm. They are all over the place, have

performance

Quoted 1 line

Quoted 1 line
and code size impact and mess up readability. Why can't you just

maintain

Quoted 10 lines

Quoted 1 line
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

Christoph Hellwig

author

2002-10-21 14:03 UTC #27 lore raw

Quoted 4 lines · Mike Wray

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.

Quoted 3 lines

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.

Mike Wray

2002-10-21 16:40 UTC #28 lore raw

From: Christoph Hellwig <[email protected]>
Sent: 21 October 2002 15:09

Quoted 10 lines · Mike Wray

Quoted 4 lines
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?

Quoted 6 lines

Quoted 3 lines
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

Christoph Hellwig

author

2002-10-21 17:30 UTC #29 lore raw

Quoted 4 lines · Mike Wray

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.

Quoted 3 lines

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.

David Wagner

2002-10-18 20:33 UTC #30 lore raw

In reply to Christoph Hellwig

Quoted 3 lines · Christoph Hellwig

And exactly these hooks harm. They are all over the place, have performance and code size impact and mess up readability. Why can't you just maintain an external patch like i.e. mosix folks that nead similar deep changes?

Actually, this is not an accurate description of LSM. As you may know, the LSM hooks do not have a noticeable performance impact (with the exception of 1Gb networking, where I believe there is a 1-2% slowdown). This has been pointed out several times before, and the LSM folks have posted a pointer to the measurements.

Stephen Smalley

2002-10-18 17:41 UTC #31 lore raw

In reply to Russell Coker

Quoted 3 lines · Russell Coker

The only code that we really want to see in the mainline kernel is the hooks for permission checks. Personally I would not mind if no security module ever gets included in Linus' source tree.

I'd disagree. I would like to see selinux included in the mainstream kernel someday, but I know that selinux needs quite a bit of work (Christoph says "rewrite") to make it acceptable. It also doesn't make much sense to submit selinux until after the remainder of LSM has been submitted for possible merging and after some level of pruning and refinement of LSM has occurred. I would also expect other security modules, e.g. DTE, to be submitted by their authors eventually. If there aren't any in-tree users of LSM, then there is little motivation for the kernel developers to retain LSM.

--
Stephen D. Smalley, NAI Labs
[email protected]

Russell Coker

2002-10-18 16:33 UTC #32 lore raw

In reply to [email protected]

Quoted 8 lines · On Fri, 18 Oct 2002 17:14, [email protected] wrote:

Do you have a projected timeline of when this mythical "all the warts in the kernel are fixed and all the userspace cruft is cleaned up" world will happen? I'd like some sort of reasonable estimate, so I know whether this will be before or after I retire. (While we're at it, can we reverse the definition of the 'r' and 'x' permissions on directories, so 'umask 037' doesn't result in directories with borked permissions? I'm actually somewhat serious here - this is the sort of thing that will need to be cleaned up and fixed all over the place...)

A "dmask" sounds like a really good idea!

Quoted 9 lines

Quoted 4 lines
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.

Quoted 10 lines

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.

Signature · 4 lines

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

Richard B. Johnson

2002-10-18 16:46 UTC #33 lore raw

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.

David Wagner

2002-10-18 09:58 UTC #34 lore raw

In reply to Alexander Viro

[this is a re-post here of something I earlier sent to the LSM mailing list]

Quoted 3 lines · Alexander Viro

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

Quoted 3 lines

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.

Russell Coker

2002-10-18 10:09 UTC #35 lore raw

In reply to Alexander Viro

Quoted 8 lines · Alexander Viro

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

Signature · 4 lines

http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Christoph Hellwig

author

2002-10-18 12:44 UTC #36 lore raw

Quoted 5 lines · Crispin Cowan

Quoted 2 lines
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.

Quoted 4 lines

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.

Quoted 4 lines

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

Quoted 5 lines

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.

Jeff Garzik

2002-10-17 20:25 UTC #37 lore raw

In reply to Russell Coker

Quoted 5 lines · Greg KH

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

Russell Coker

2002-10-17 20:54 UTC #38 lore raw

Quoted 10 lines · Jeff Garzik

Quoted 5 lines · Greg KH
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.

Signature · 4 lines

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

Jeff Garzik

2002-10-17 21:04 UTC #39 lore raw

Quoted 12 lines · Russell Coker

Quoted 10 lines · Jeff Garzik
Quoted 5 lines · Greg KH
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?

Quoted 8 lines

Quoted 1 line
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

Russell Coker

2002-10-17 21:32 UTC #40 lore raw

Quoted 15 lines · Jeff Garzik

Quoted 15 lines
Quoted 3 lines
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.

Quoted 5 lines

Quoted 2 lines
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.

Signature · 4 lines

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

Alexander Viro

2002-10-17 21:43 UTC #41 lore raw

Quoted 7 lines · Russell Coker

Quoted 2 lines
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".

Russell Coker

2002-10-17 22:08 UTC #42 lore raw

Quoted 6 lines · Alexander Viro

Quoted 5 lines · Russell Coker
Quoted 2 lines
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.

Quoted 7 lines

Quoted 2 lines
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.

Quoted 7 lines

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?

Signature · 4 lines

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

Andreas Dilger

2002-10-17 22:20 UTC #43 lore raw

Quoted 2 lines · Russell Coker

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/

Stephen C. Tweedie

2002-10-23 00:29 UTC #44 lore raw

Hi,

Quoted 8 lines · Russell Coker

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

Russell Coker

2002-10-23 11:38 UTC #45 lore raw

Quoted 6 lines · Stephen C. Tweedie

Quoted 5 lines
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?

Quoted 7 lines

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

Signature · 4 lines

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

Stephen C. Tweedie

2002-10-23 11:53 UTC #46 lore raw

Hi,

Quoted 11 lines · Russell Coker

Quoted 3 lines · Stephen C. Tweedie
Quoted 2 lines
"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.

Quoted 4 lines

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

Stephen Smalley

2002-10-23 14:21 UTC #47 lore raw

Quoted 6 lines · Stephen C. Tweedie

setfsuid() creates credentials which are _only_ applied to file operations. The namespace happens to be the same one that applies to processes, but there's nothing that requires that to be the case, and if you have a corresponding setfssid() to set the effective set for fs access, you're explicitly requesting the fs namespace, not the process one.

Would we need a separate call for setting the SIDs to use for each "namespace", i.e. fs (for open, mkdir, mknod, and symlink calls), IPC (for semget, msgget, and shmget calls), process (for execve calls), and socket (for socket, connect, listen, sendmsg, and sendto calls, requiring two SIDs for send*)?

Notice that there are differences in the semantics of an fsuid vs. an fs SID if the purpose of the fs SID is for newly created files. The fs SID would only be used for specifying a SID other than the default transition SID for new files, which is normally determined by the policy logic based on a combination of the creating process' SID, the SID of the parent directory, and the kind (security class) of file. The fs SID should not be used as the process' effective SID in permission checks for operations on existing files (you can't just use a file SID and a process SID interchangeably, unlike uids). By default, the fs SID would need to be "unset" (e.g. SECSID_NULL) to indicate that a default transition SID should be computed; you would not have an equivalent to the default case of fsuid == euid.

While your approach would work for calls that take input SID parameters, what about the various calls that return SIDs either directly or via output SID parameters, e.g. extended forms of *stat, msgrcv, recvmsg, getpeername/accept plus new calls like (sem|shm|msg)sid and getsecsid?

--
Stephen D. Smalley, NAI Labs
[email protected]

Stephen C. Tweedie

2002-10-23 14:48 UTC #48 lore raw

Hi,

Quoted 10 lines · Stephen Smalley

Quoted 3 lines · Stephen C. Tweedie
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.

Quoted 4 lines

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

Stephen Smalley

2002-10-23 16:04 UTC #49 lore raw

Quoted 4 lines · Stephen C. Tweedie

Good question --- what is the reason you need these, and are other security modules likely to need similar functionality? If so, there's an argument for new syscalls which take a credentials/sid area as a return argument.

The extended *stat calls enable applications to obtain file SIDs along with the regular file status for a variety of purposes, e.g. SELinux provides patched versions of ls (displaying security contexts to users), find (searching for files with particular security contexts or displaying the contexts of files matching the find criteria to users), cp -p and tar (preserving contexts on copies and in archives), logrotate (preserving contexts when logs are rotated), and crond (checking the context on a user-generated crontab spool file to protect against running cron jobs with a given process SID from a less trusted source). While you don't always need to get both the file status and the security attributes for a given file, you often do for programs like ls, cp, tar, etc.

If we migrate SELinux to using extended attributes to store file security contexts (pending their merging into 2.5), then we could replace the extended *stat with getxattr, although getxattr doesn't provide an atomic way of getting both the regular file status information and the security attributes for a given file. Closest approximation to stat_secure() would be an open(...O_RDONLY), fstat(), fgetxattr(), close() sequence to ensure that the file status and security attributes are from the same inode, but this assumes that you can always read the file in order to stat it and isn't exactly ideal.

For System V IPC and socket IPC, the extended calls enable applications to obtain security information about the sender and the data so that the security-aware applications can make security decisions and label data appropriately. An extended form of SCM_CREDENTIALS that supports additional security data and is not limited to local domain sockets [the SELinux calls work for INET sockets if labeled networking is used] might be reasonable for socket IPC.

--
Stephen D. Smalley, NAI Labs
[email protected]

Christoph Hellwig

author

2002-10-23 16:18 UTC #50 lore raw

Quoted 3 lines · Stephen Smalley

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

Stephen Smalley

2002-10-23 16:28 UTC #51 lore raw

Quoted 1 line · Christoph Hellwig

extended attributes are both in 2.4.20-pre and 2.5 (for a long time).

I meant the merging of the EA implementations for ext[23], not just the EA API calls.

--
Stephen D. Smalley, NAI Labs
[email protected]

Christoph Hellwig

author

2002-10-23 16:30 UTC #52 lore raw

Quoted 7 lines · Stephen Smalley

Quoted 1 line · Christoph Hellwig
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)

Stephen Smalley

2002-10-23 16:45 UTC #53 lore raw

Quoted 2 lines · Christoph Hellwig

Why are you limited to a single fs? xfs and jfs have xattr support out of the box (in 2.4 only jfs is actually in the mainline tree, though)

Most of our users (and we) happen to use ext[23], so there isn't any point in migrating SELinux to using EAs until EA implementations are merged into those filesystems. Also, the EA API lacks support for creating files with specified security attributes (as opposed to creating and then calling setxattr to change the attributes, possibly after someone has already obtained access to the file), so it isn't ideal for our purposes anyway.

--
Stephen D. Smalley, NAI Labs
[email protected]

Nathan Scott

2002-10-24 06:21 UTC #54 lore raw

Hello,

Quoted 9 lines · Stephen Smalley

Quoted 2 lines
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.

Signature · 1 line

Nathan

Russell Coker

2002-10-24 08:39 UTC #55 lore raw

Quoted 6 lines · Nathan Scott

Quoted 5 lines
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.

Quoted 6 lines

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.

Quoted 5 lines

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.

Signature · 4 lines

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

Russell Coker

2002-10-17 20:39 UTC #56 lore raw

Quoted 5 lines · Greg KH

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.

Signature · 4 lines

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

Alan Cox

2002-10-21 13:37 UTC #57 lore raw

Quoted 4 lines · Greg KH

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

Crispin Cowan

2002-10-21 21:07 UTC #58 lore raw

Quoted 9 lines · Alan Cox

Quoted 6 lines · Greg KH
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.

Quoted 4 lines

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

Greg KH

2002-10-21 21:12 UTC #59 lore raw

Quoted 2 lines · Crispin Cowan

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

Stephen Smalley

2002-10-22 12:16 UTC #60 lore raw

Quoted 4 lines · Crispin Cowan

Therefore, the sys_security syscall has been removed. LSM-aware applications that want to talk to security modules can do so through a file system interface. This will work for WireX, and Smalley says it will work for SELinux. I hope it will work for others.

Actually, with regard to using a pseudo filesystem interface, I said that we could investigate it, but I have doubts about cleanly supporting the extended forms of existing calls (e.g. execve_secure, mkdir_secure, msgrcv_secure, recvmsg_secure, etc) using such an interface. I raised the same issue when sys_security was originally discussed on the lsm list long ago. SELinux extends the POSIX API to incorporate security (specifically flexible mandatory access control) as a first class notion.

However, I understand Christoph's objection to sys_security and am not trying to revive that debate. We can hopefully have a dialogue about the SELinux API with the kernel developers at a later time and come to some consensus on a set of specific system calls that can be added to the kernel to support equivalent functionality to the SELinux API.

--
Stephen D. Smalley, NAI Labs
[email protected]

Russell Coker

2002-10-17 20:14 UTC #61 lore raw

In reply to Russell Coker

Quoted 6 lines · Greg KH

Quoted 5 lines · Christoph Hellwig
Quoted 4 lines
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.

Quoted 7 lines

Quoted 4 lines
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?

Quoted 3 lines

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.

Signature · 4 lines

http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Christoph Hellwig

author

2002-10-17 20:21 UTC #62 lore raw

Quoted 4 lines · Russell Coker

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?

Quoted 2 lines

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.

Quoted 1 line

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.

Greg KH

2002-10-17 20:22 UTC #63 lore raw

Quoted 3 lines · Russell Coker

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

Alexander Viro

2002-10-17 18:59 UTC #64 lore raw

Quoted 2 lines · Greg KH

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

Quoted 2 lines

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

Quoted 2 lines

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?

David S. Miller

2002-10-17 20:20 UTC #65 lore raw

From: Greg KH <[email protected]>
Date: Thu, 17 Oct 2002 11:53:52 -0700

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)

Greg KH

2002-10-17 20:31 UTC #66 lore raw

Quoted 19 lines · David S. Miller

From: Greg KH <[email protected]>
Date: Thu, 17 Oct 2002 11:53:52 -0700
No, don't remove this!
Yes, it's a big switch, but what do you propose otherwise? SELinux would need a _lot_ of different security calls, which would be fine, but we don't want to force every security module to try to go through the process of getting their own syscalls.
And other subsystems in the kernel do the same thing with their syscall, like networking, so there is a past history of this usage.
Well, here is another issue about opaque interfaces, how are we supposed to audit whether 32-bit/64-bit execution environments will be able to work correctly?
If there is no description available of what the types are going through these system calls, it cannot be handled properly.

Quoted 7 lines

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.

Quoted 3 lines

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.

Quoted 5 lines

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

David S. Miller

2002-10-17 20:39 UTC #67 lore raw

From: Greg KH <[email protected]>
Date: Thu, 17 Oct 2002 13:36:52 -0700

Quoted 3 lines

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.

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

Greg KH

2002-10-17 20:52 UTC #68 lore raw

Quoted 6 lines · David S. Miller

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.

Quoted 11 lines

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.

Quoted 6 lines

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.

Quoted 2 lines

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

David S. Miller

2002-10-17 21:00 UTC #69 lore raw

From: Greg KH <[email protected]>
Date: Thu, 17 Oct 2002 13:58:31 -0700

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

Greg KH

2002-10-17 22:04 UTC #70 lore raw

Quoted 11 lines · David S. Miller

From: Greg KH <[email protected]>
Date: Thu, 17 Oct 2002 13:58:31 -0700
I've run the numbers myself on OSDL machines, and seen that there is no measurable overhead for these functions. Sure, there is an extra function call, and different assembler, I'll never contest that. It's just that I could not measure it.
Did you look at the _code_? Did you measure the size of even the non security/*.o object code with/without the hooks? What is the added overhead?

I did not look at size, sorry. I only looked at run-time performance.

Quoted 2 lines

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.

Quoted 2 lines

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

David S. Miller

2002-10-17 22:08 UTC #71 lore raw

From: Greg KH <[email protected]>
Date: Thu, 17 Oct 2002 15:09:57 -0700

Quoted 2 lines

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.

Quoted 2 lines

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.

Greg KH

2002-10-17 22:14 UTC #72 lore raw

Quoted 10 lines · David S. Miller

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

Crispin Cowan

2002-10-18 07:55 UTC #73 lore raw

Quoted 7 lines · David S. Miller

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

Signature · 4 lines

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

David S. Miller

2002-10-18 07:59 UTC #74 lore raw

From: Crispin Cowan <[email protected]>
Date: Fri, 18 Oct 2002 01:00:34 -0700

LSM is not zero-footprint, but it is as low as we could make it.

I disagree, entirely.

You could entirely hide a lot of this crap, especially the VFS stuff, by stacking in your own LSM specific VFS ops if we could stack filesystems or something like that.

Christoph Hellwig

author

2002-10-18 13:02 UTC #75 lore raw

Quoted 2 lines · Crispin Cowan

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.

David Wagner

2002-10-17 22:06 UTC #76 lore raw

Quoted 4 lines · David S. Miller

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.

Quoted 4 lines

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.

David S. Miller

2002-10-17 22:38 UTC #77 lore raw

From: [email protected] (David Wagner)
Date: 17 Oct 2002 21:54:49 GMT

For example, the LSM folks have several performance measurements that show that the performance overhead of LSM is basically negligible, so that's one way that users won't notice it is there.

How about size measurements? As in, the kernel is at a minimum several Kb larger than if CONFIG_SECURITY=n

And about prospective usage of LSM, it can be judged even though it isn't in the tree yet. That's how we decide what to put into the kernel to begin with.

Look at your average user, he doesn't really care about LSM. He wants to be able to play his music, play quake3, surf the web, write emails and compose documents. If he's a developer he also wants to compile programs and source management tools. If he's an artist or professional photographer, he wants something like the GIMP.

Sure, it might become popular on multi-user machines to use some sort of LSM module for this purpose or that.

But as far as raw seats are concerned, the majority will not use LSM. They simply have no need for it on their workstation.

Chris Wright

2002-10-17 23:07 UTC #78 lore raw

Quoted 3 lines · * David S. Miller ([email protected]) wrote:

But as far as raw seats are concerned, the majority will not use LSM. They simply have no need for it on their workstation.

I agree, the average desktop user isn't even aware of the issues. But I think the photographer would like it if the mp3 player can't remove files in ~/photos/ when it plays a malicious .mp3 file. So even the desktop user could benefit from better security infrastructure. But your point on security uptake is well-taken.

thanks,
-chris

David S. Miller

2002-10-17 23:11 UTC #79 lore raw

From: Chris Wright <[email protected]>
Date: Thu, 17 Oct 2002 16:04:36 -0700

the photographer would like it if the mp3 player can't remove files in ~/photos/ when it plays a malicious .mp3 file.

LSM doesn't provide anything in this area which can't be done today. You can protect that directory from malicious programs today with file/dir protections and running programs with a different capability set or even with a different euid/egid for file accesses.

Jakob Oestergaard

2002-10-18 14:18 UTC #80 lore raw

Quoted 10 lines · David S. Miller

From: Chris Wright <[email protected]>
Date: Thu, 17 Oct 2002 16:04:36 -0700
the photographer would like it if the mp3 player can't remove files in ~/photos/ when it plays a malicious .mp3 file.
LSM doesn't provide anything in this area which can't be done today. You can protect that directory from malicious programs today with file/dir protections and running programs with a different capability set or even with a different euid/egid for file accesses.

Ok - now I'm surprised.

How do I prevent my Evolution from reading
Projects/top-secret-stuff/main.c ?

I mean, my emacs should still be able to read it of course, and su'ing to fifty different users for each of the fifty applications I usually run is not really an option of course.

Please enlighten me :)

Signature · 6 lines

................................................................
:   [email protected]   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

Andreas Steinmetz

2002-10-17 22:46 UTC #81 lore raw

In reply to Andreas Steinmetz

Quoted 6 lines · David S. Miller

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.

Quoted 4 lines

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.

Signature · 1 line

Andreas Steinmetz

David S. Miller

2002-10-17 22:53 UTC #82 lore raw

From: Andreas Steinmetz <[email protected]>
Date: Fri, 18 Oct 2002 00:51:29 +0200

For the next few years 99% of the linux users won't use GBit ethernet, so why don't you remove these drivers from the kernel?

The vast majority of desktop computers today ship with gigabit ethernet interfaces on the motherboard.

So you are wrong, people use it today.

As per the rest of your email, most of my disagreement has to do with the fact that the implementation isn't optimal. Going back to USB, it's optimal because it falls into one of two possible categories:

1) If I don't use it, and it's built as a module, it takes up no resources on my computer.

2) The facilities added to support feature X also helps make things like Y and Z possible.

Things like #2 are the things Al Viro is talking about.

So instead of "security_ops()->this, security_ops()->that" being sprinkled merrily all over the VFS, we have something useful to things outside of LSM such as full file */fd attributes.

Frankly, as a side effect of no effort being put into #2, the LSM user level interface is complete shit. As is the hook mechanism.

Daniel Egger

2002-10-18 18:02 UTC #83 lore raw

Am Fre, 2002-10-18 um 00.51 schrieb David S. Miller:

Quoted 2 lines

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

Signature · 2 lines

Servus,
       Daniel

Jeff Garzik

2002-10-17 22:55 UTC #84 lore raw

Quoted 11 lines · Andreas Steinmetz

Quoted 6 lines · David S. Miller
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:

Quoted 7 lines

<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

David S. Miller

2002-10-17 22:58 UTC #85 lore raw

From: Jeff Garzik <[email protected]>
Date: Thu, 17 Oct 2002 19:00:58 -0400

Finally, I was under the impression that Greg KH agreed that it is possible to eliminate this overhead? Maybe I recall incorrectly.

The agreement was that it would be nice, we also agreed that it's a very difficult thing to implement.

I'm now leaning more towards something like what Al Viro hinted at earlier, creating generic per-file/fd attributes. This kind of stuff.

Greg KH

2002-10-17 23:03 UTC #86 lore raw

Quoted 4 lines · David S. Miller

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

Chris Wright

2002-10-17 23:13 UTC #87 lore raw

Quoted 10 lines · * Greg KH ([email protected]) wrote:

Quoted 4 lines · David S. Miller
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

Signature · 1 line

Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Andreas Steinmetz

2002-10-17 23:07 UTC #88 lore raw