Re: [capsicum] Capability Mode



On 15 Dec 2010, at 12:47, Ben Laurie wrote:

> On 15 December 2010 01:33, Mark Seaborn <mseaborn at chromium.org> wrote:
>> On 14 December 2010 17:25, Jonathan Anderson
>> <jonathan.anderson at cl.cam.ac.uk> wrote:
>>> 
>>> Here's a patch against -CURRENT (r216376) that is the first step in a
>>> multi-phase programme:
>>> 
>>> 1. Capability mode with a restrictive syscall mask (no openat(2)
>>> functions, etc.)
>>> 2. Capabilities
>>> 3. Deep semantic constraints which allow openat(2), etc. - once we've
>>> convinced ourselves that our changes to namei() and friends don't introduce
>>> race conditions w.r.t. rename
>> 
>> What do you mean by "deep semantic constraints"?  The comment on race
>> conditions makes me think you are considering allowing ".." in
>> capability-mode pathnames.  Is that right, or am I jumping to conclusions?
>>  I prefer the idea of disallowing ".." because it is a simple syntactic
> 
> An insufficient one, surely? Consider "ln -s .. up".

When a symlink is evaluated, its contents are used as a fresh path for a lookup. If we implement ".." constraints within segment lookup, then when "up" is converted to "..", parsed, and the segment ".." is spotted, we can reject it there. Which is to say: it's only a problem if you apply ".." matching to paths rather than the segments during actual lookup.

By "deep semantics", I believe what Jon is referring to is any security constraint that is imposed with an awareness of the meaning of the system call or its arguments, rather than simply entirely blocked as a result of being an omitted system call in the ABI. For example, the decision to allow anonymous POSIX shared memory objects to be created, but not named ones -- both operations involve the same system call, so protection is done deeper where the name is interpreted.

Robert



This archive was generated by a fusion of Pipermail (Mailman edition) and MHonArc.