lkml.org 
[lkml]   [1999]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: caps in elf, next itteration (the hack get's bigger)
Date
From
"David L. Parsley (lkml account)" <kparse@salem.k12.va.us> said:

[...]

> named(8) just happens to be my favorite example, but others apply as well;
> at this point, I think the question is: do we implement capabilities as
> they were designed to be implemented (stickybit/immutable solution), or do
> we break the semantics of capabilities to work around problems in the
> solution based on setuid-root?

Capabilities were _not_ designed to be implemented in any particular way,
even less by overloading existing permission bits.

OK, let's check again: Where are we going? Possibilities include:

a) A vaguely unixy system with all-powerful root + capability-protected
daemons and whatnot

b) A fully capability based system, that by its very nature doesn't look
like Unix at all, at least to the sysadmins in charge

Note that the above might very well run on the same kernel, AFAIKS. The
difference is in policies, in capabilities and permissions of the various
binaries.

Then consider the relevant standards (POSIX, perhaps some of the Rainbow
series?) or their draft versions.

Then look around for Unixy systems that use capabilities, and (more
important, perhaps) at other systems that have them.

(a) has still serious security implications (if I hijack a root process,
I'm home free), but it might make this much harder to do to an attacker. So
this might be useful in a limited way.

(b) means throwing away much of the Unix tradition, massive rewrite of
tools, etc. Could be an interesting idea for somebody who wants to build a
bulletproof distribution, of for similar uses. But for this to be taken
seriously it would also need massive amounts of work elsewhere (get B
certification or thereabouts, I'd guess)

Whatever is done, I strongly suggest that (b) is not simply made impossible
to ease (a). Also, even for (a) the whole workings of the userland (and the
systems programs) has to be carefully scrutinized, several tools either
patched or supplemented with capability-aware, specialized tools. And then
the whole capability setup for _all_ programs has to be done, either
patching the relevant Makefiles or by some extra tool that keeps a database
of capabilities and sets them when a new version is installed (RPM could be
extended to at least keep this info, or the Debian package manager...).

Note that all this work _has_ to be done, whatever the way capabilities are
implemented in the end. That's why I lobby for putting them into the
filesystem: It's the _only_ guaranteed secure place to keep them, and
nobody paranoid enough to go to (b) will let anything non-local even get
near their system. For (a), if NFS/CODA/iso9660/VFAT/NTFS/whatever don't
know about capabilities, anything you get that way has _no_ capabilities,
and can't be a security risk.

For transition, the path will consist in a new filesystem (or a variant of
an existing one), and a lot of userspace changes. Nobody in its sane mind
will run old and new kernels alternatively on a security-sensitive machine
anyway, so the dual boot scenarios are moot anyway. Except perhaps for
testing or setting up the whole system, and there security will have to be
relaxed. Linux already knows of several differeent security levels in the
kernel, use that: A "Install" level with a "root", a "Normal" level
without. Or even different kernels, where the first gets obliterated after
the system is running.
--
Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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