lkml.org 
[lkml]   [1998]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [patch 2.1.97] more capabilities support
Date
From
> From: Chris Evans <chris@ferret.lmh.ox.ac.uk>

> [other stuff snipped]

> This is largely irrelevant, sadly. A buffer overrun on the command line
> still, like in the SUID case, gets the attacker complete control of the
> program. The difference is the exploit code now has to call the
> raise_capability system call before doing its nasty stuff. Of course,
> _unlike_ the SUID case, an attacker will have a much more limited set of
> privs to play with, so capabilities are an excellent damage limitation
> scheme :)

Probably not true either. It's more likely that some blanket set of security will be the default
and local administrators and vendors installing software will just disable security until whatever
they want to work works. I've seen an awful lot of 777 files for no other reason than this.

Caveat: I haven't looked at the capabilities model and do not intend to.

All security features should be:
- simple to understand and implement
- trivial to learn and use
- clear in announcing violations so that admins can diagnose them from vague user descriptions.

I can't see any fine grained control satisfying these attributes, whereas setuid satisfies - or can
satisfy - at least some of them.

Instead of this stuff, why not spend some engergy robust-ifying setuid programs in the kernel.

There are well known rules
for writing setuid programs which, if followed, make them more safe than if not. Most of that
stuff involves system calls. Some of these could be rolled into the kernel or at least checked.
A bit mask could be filled in to make sure a buch of the stuff been done and which would disable
any file modification if not properly set. This would certainly make me rest easier when a vendor
ships a suid-root utility [a vendor who installs mosts of their software 777 [no I won't name
them - they market a financial accounting package]].

I'm kind of sensitive to this because I waste quite a little time making things work again after
some random piece of software gets upgraded on a couple of my client's systems. [e.g. someone
installs some new PC FTP software and the default permissions revert back to 640 from 660 and the
users end up swapping passwords (again) in order to simply finish the day's work. The on site
admin wastes a day trying to find where to fix it in the configuration stuff in the new package.
...]

Regards,
Mike Howard <mike@clove.com>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.016 / U:0.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site