lkml.org 
[lkml]   [2004]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: silent semantic changes with reiser4
Rik van Riel wrote:
> What do we do with O_CREAT ?
>
> Do we always allow both a directory and a file to be created with
> the same name ?

I haven't analysed it thoroughly. I suspect it's fine as long as:

(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).

File-like also means that programs like "cp from to_my_new_file"
won't do anything so silly as to write _inside_, the way that
"cp from to_my_new_file/from" would.

Basic utilities will need to be checked to make sure they don't
try appending "/" as their method of deciding if the target object
is a directory and should be entered.

> 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.

This is very difficult to prevent.

We are creating a way for scripts and classic unix tools to have easy
access to fancy attributes which may affect the security: things like
being able to change a file's permissions just by writing to the
appropriate path, or reading characteristics of files that shouldn't
be visible. 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.

In a way, these holes are similar to /proc, in that just writing has
side effects which might not be acceptable.

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.

For the paranoid, one way is to make new files "not readable or
executable as directories". It's possible for the file and directory
branches to have different permission bits, though I could see that
getting a bit annoying. Other possibilities abound.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:05    [from the cache]
©2003-2011 Jasper Spaans