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

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.

Adding unnamed file creation to the Linux kernel is a simple homework exercise
for a student.  Here is what the student would have to implement:

/* Returns file descriptor to new unnamed file.  All checks (access, quota,
   etc) are relative to the directory provided.  */
int mkfile (const char *directory, int open_flags, int open_mode);
int mkfileat (int dirfd, int open_flags, int open_mode);

Then it would also make sense to add more interfaces flink and flinkat that
allow linking unnamed files back into the namespace.

Apparently nobody cared enough so far to implement it and propose it for
inclusion into the kernel (or distributions, or as kernel module for those who
might need it).

>>> That is in the anonymous file creation I've seen, you do an open/create
>>> call followed by an unlink. Is there a way to create an anonymous file
>>> without using a temporary namespace to link it into?
>> The GNU/Hurd implemented an extension to the POSIX API that allowed
>> creation
>> of anonymous, unnamed files (the files were never linked into the
>> filesystem).
> 
> I don't understand 'never linked into the filesystem', the file needs to
> be linked into the filesystem, just not into the global namespace of the
> filesystem.

I meant "linked into the filesystem namespace" (it's the only meaning of the
word "link" in Unix, really).

The GNU/Hurd has a call dir_mkfile that works exactly like mkfileat() above.

Thanks,
Marcus