Re: silent semantic changes with reiser4

From: Jamie Lokier (jamie_at_shareable.org)
Date: 08/26/04

  • Next message: Arthur Corliss: "Re: [Lse-tech] Re: [PATCH] new CSA patchset for 2.6.8"
    Date:	Thu, 26 Aug 2004 20:29:18 +0100
    To: Rik van Riel <riel@redhat.com>
    
    

    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/


  • Next message: Arthur Corliss: "Re: [Lse-tech] Re: [PATCH] new CSA patchset for 2.6.8"

    Relevant Pages

    • Re: Oh.... Im just wondering whos seen this stumper...
      ... A guy running code under an account ... read/write effective permissions. ... Now his code fails writing to OTHER ... authentication is written in the script. ...
      (microsoft.public.windows.server.active_directory)
    • File Share permission / read-only attribute
      ... I'm writing to you. ... I'm from a netware background and now I'm migrating from novell to windows ... for user directories, application data and forms. ... the file share permissions and the security to full control. ...
      (microsoft.public.windows.file_system)
    • script permissions
      ... i'm converting an asp/vbscript to perl and trying to write to the same ... not stated what those rights are, but seem to include writing ... web originated permissions for file access are controlled thru iis? ... asp runs under the IUSR_hostname account? ...
      (microsoft.public.inetserver.iis.security)
    • Using impersonation to allow writing to server directory?
      ... I'm struggling with an odd permissions problem I have with one of my ... The root folder I am writing too ... Should I have IUSER set up with write permissions? ...
      (microsoft.public.dotnet.framework.aspnet)
    • RE: Migrate File Server and add default permissions
      ... tool that enables administrators to obtain security information about ... Migrate File Server and add default permissions ... I am migrating a file server from our old NT4 Domain to our new 2000 AD ... I've used xcopy and robocopy and played with secure copy to ...
      (microsoft.public.windows.server.migration)