Re: Reducing Ambient user authority in a Type Safe /Memory Safe OS.

On Thu, December 31, 2009 01:09, Marcus Brinkmann wrote:
> Rob Meijer wrote:
>> On Fri, December 18, 2009 13:58, Marcus Brinkmann wrote:
>>> Rob Meijer wrote:
>>>> The process of creating an anonymous file to my knowledge still uses
>>>> linking into a namespace that is vulnerable to race condition attacks.
>>> It's only vulnerable if used incorrectly ever since O_EXCL was added,
>>> see
>>> mkstemp(3).
>>
>> The O_EXCL flag only makes sure that a named file does not already exist
>> within the given namespace before creating it. The problem remains that
>> in
>> between the open with O_CREAT | O_EXCL, or mkstemp for that matter, and
>> the moment of unlink, we have a short moment that the file exists in the
>> global namespace, and a hostile process could potentially gain access to
>> it.
>
> As (among other reasons) all file descriptors are linked into
> /proc/PID/fd/NR
> with the same access restrictions as a file created by mkstemp(), I can
> not
> see a significant difference.  Maybe you can explain it to me.

Your right, access to /proc/$PID (where /proc/$PID is not equal to
/proc/self) in effect renders all ideas you might have about implementing
fine grained access control on *NIX effectively useless.
With MinorFs this has been a major problem up to now, as MAC systems
AppArmor that MinorFs depends on, untill this day does not allow to
express the difference between /proc/$somepid and /proc/$mypid. This is
however something that as I understand is on the feature list for the
upcoming
major release of AppArmor. I feel this distinction is essential for
allowing to do any kind of least authority retrofit system on *NIX.

If we assume however that it is quite possible for many programs to run
perfectly without any implicit access to /proc/$mypid, and thus can
restrict quit a lot of programs so that they don't have access to this,
than it remains useful if we could be able to create unnamed files without
using a shared namespace.