Re: silent semantic changes with reiser4

[Christophe Saout <christophe@saout.de>]

[-- Attachment #1: Type: text/plain, Size: 2037 bytes --]

Am Donnerstag, den 26.08.2004, 20:29 +0100 schrieb Jamie Lokier:

> (1) O_CREAT creates something with "file-like
>     attributes", meaning stat() says it's a regular file.
> 
> (2) File-like means it can be unlinked, linked and renamed, even if
>     someone has something inside it open.  Nothing that can be created
>     inside it will prevent it from being unlinked (unlike a
>     directory-like object, where rmdir() will refuse if it's not empty).

I would say hat the file and all of its directory gets invalidated and
deleted as soon as the last opener of the file's main stream or some of
its directory content disappears. How would that be?

> > Does this create a new class of "symlink attack" style security
> > holes ?
> 
> Yes, but they don't need O_CREAT.
> 
> An adversary creates a symlink to metadata inside your file.  You
> write to it: it has interesting effects that weren't anticipated, such
> as either modifying another (virtual) file, or altering permissions or
> other parameters which writing doesn't normally do.

Hmm.

> This is very difficult to prevent.

Right. But to change some properties you usually need to be the owner of
that file anyway, or root.

> In Hans Reiser's example of expanded /etc/passwd, atimes
> and mtimes of individual passwd entries is security information that
> perhaps shouldn't be exposed.

Only assuming mtime/ctime/atime/rwx/uid/gid of file contents can
actually be independant of those from the main stream. I would say that
the rights (read and write) for non-pseudo sub-files should the same as
the file, uid and gid 644 (only owner can change these), something like
that. mtime, atime and ctime always show the same as the file itself.
Hmm.

> The solution is the same as for /proc (I hope): make sure the read
> permissions on all metadata inside a directory branch are restricted
> to the permissions of the file branch, and write permissions even more
> restricted at least by default.

That's what I was thinking.


[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]