Re: Preparing Debian for using capabilities: file ownership.
On Wed, Sep 27, 2000 at 08:59:20PM -0400, Jonathan D. Proulx wrote:
> However after further reading I stand by my previous assertion that
> slapping capapilities ontop of a Un*x like system is asking for
> trouble.
Depends what you do.
> Are we really going to get anything valuable out of this? Will portmap
> be able to assign reserved ports without any other privileges? Will
> MTA's be restricted to just running the mail queue and *appending* to
> mail spool files?
The reserved ports one is easily solved by capabilities (and, some
would argue that the whole concept of reserved ports is silly --
reserved ports should be reserved by a simple program, along the
lines of tcpserver[*]). The mail spool problem is best solved
with something that has root privileges (since mail privacy is
roughly the same problem as login privacy -- it's the same underlying
file system offering the protections).
> Will this mean that every file and/or directory will need to be picked
> over by the kernel (or some user space deamon) if the machine is not
> shutdown properly (or worse even if it is) or will some checkpointing
> system be used to save this state (and suck up disk resources)?
Yep, that's a bad approach. I was only suggesting it as a bad example.
> More to the point is this even an issue for a Distribution to take up,
> wouldn't these changes happen up stream (I know that some people here
> are also there, but...)
To some degree, they will. But upstream will hopefully be waiting for the
same thing we are: a stable and complete implementation of capabilities.
And, presumably, upstream will be intelligent about how they implement
capabilities (and, presumably, our maintainers will make the right
choices about how those capabilities are deployed).
> The granularity afforded by capabilities is, IMHO, required to have
> a reasonably secure operating system in an open environment. But
> putting capabilities ontop of the blocky UN*X ACL system (especially
> if they can only *elevate* privilige) is likely to cause more problems
> than it solves both in new and more interesting security holes and
> overwhelming complexity for administrators (which will in turn case
> more security flaws of omission)
Once they're in the file system, they won't only elevate privilege.
At that point, programs can be denied privilege (even if the user process
has the capability, the program will drop it).
In practice, this is mostly useful to keep complex programs unprivileged.
[It's one of those closing the gate after the horses have left kinds
of solutions. Better than nothing, but not by very much.]
Basically, I see some use for privileges, but I don't want to see us
going into any kind of "change everything to take advantage of this new
whiz-bang vaporware" thing.
--
Raul
[*] Yeah, I know, tcpserver doesn't have a DFSG license, while inetd does.
But, inetd is a complex, unportable beast with lots of subtle things that
make it a bit unpredictable and unwieldy, while tcpserver is simple,
easy to comprehend, and is portable. So, I prefer to allude to tcpserver
when talking about security/reliability issues.
Reply to: