Messages in this thread | | | Date | Mon, 20 Apr 1998 13:13:43 +0200 | From | Alexander Kjeldaas <> | Subject | Re: [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
| |