lkml.org 
[lkml]   [1998]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 2.1.97] more capabilities support
On Mon, Apr 20, 1998 at 03:32:15AM -0400, Albert D. Cahalan wrote:
[...]
> So "nobody" gets to use the "remove any file" capability.
> IMHO it would be nice to be able to stop that.
>
> Considering users as:
>
> a. authorized to use the capability as desired
> b. limited by tools & not expected to find holes in the tools
> c. possibly serious crackers who are likely to look for holes
>
> User "nobody" is in group c, and should not be able to
> execute tools with such power.
>

You can design a system without any forced bits capabilities at
all. That would stop a user in group c the possibility to gain extra
capabilities (I'm disregarding hacking already running,
high-confidence daemons.)

The example Andrew gives is _one_ out of _two_ ways of doing this.

1) You don't give users a lot of inheritable capabilities.
For old suid-programs, you set the forced bits on the executable.
By default, forced bits will not be passed on to children.
You might use 'wheel' etc to hide programs more efficiently than in
the old system since root don't have DAC override powers (however
this doesn't necessarily hold for the 'backward compatible' mode
which probably will be used quite extensively).

2) You give users inheritable capabilities that match the maximum
capabilities you want the user to be able to obtain. (nobody would
get none of course).
For old suid-programs, you set the allowed bits on the executable.


> > Strict capability model (cleanme.tool has file capabilities):
> > cleaner: (pI = 0; pP = ? ; pE = ?)
> > cleanme.tool: (fI = 1; fP = 1 ; fE = 1)

This file is given forced capabilities (fP != 0). The allowed bis are
also set (pI != 0), but this doesn't matter.

> > cleaner-running-cleanme.tool (pI'= 0; pP'= 1 ; pE'= 1)

..so this is #1.

> > Backward compatibility model (cleanme.tool is setuid root):
> > cleaner: (pI = 1; pP = 0 ; pE = 0)
> > cleanme.tool: (fI = 1; fP = 0 ; fE = 1)
> > cleaner-running-cleanme.tool (pI'= 1; pP'= 1 ; pE'= 1)
> >

Here, the cleanme.tool isn't given any forced capabilities, but that
means that the cleaner process needs to have inheritable capabilities
(pI != 0). So this is #2. However, this model isn't specific to
backward compatibleness.

I generally like #2 and would reserve #1 for special cases.

If you use #1, the program should be written to be secure as it pretty
much works like a suid binary.

If you use #2, the program should be written to be secure since your
users would be interested in getting their inherited set transferred
to their permitted set by hacking processes with non-zero permitted
bits.

If you use #2, users will still hack daemons with capabilities beyond
their inherited set, so it doesn't mean you're safe.

> > [I'm going to put all this in the documentation. I strongly suspect
> > other people will find it handy.. ;]
>
> Yes, until we have enough features to need a full HOWTO on them.
> (did you see the research project that did MAC & other stuff?)
>

I'm in the process of designing some web-pages on this. It will take
some time, but eventually I'll get there :-)

The MAC project you're referring to, it wouldn't be the project I and
Finn Arne <finnag@guardian.no> did one year ago? We evaluated how MAC
could be implemented in Linux. I came to the same conclusion that
others have before me: it is hard :-). This, and the fact that you
mostly don't need MAC, but rather some other form of mandatory access
control (I use the term MAC as referring to DoD style mandatory access
control, but the concept includes lots of other techniques) lead me to
consider the alternatives. A nice alternative is type enforcement. I'm
looking for students wanting to take their diploma on this at the
University. We'll see if someone volunteers as summer approaches.

astor

--
Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway
http://www.guardian.no/

-
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.063 / U:0.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site