bugtraq - Re: /proc filesystem allows bypassing directory permissions on

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200911022333.nA2NXS92001643@fs4113.wdf.sap.corp>
Date: Tue, 3 Nov 2009 00:33:28 +0100 (MET)
From: Martin Rex <Martin.Rex@....com>
To: gombasg@...aki.hu (Gabor Gombas)
Cc: pavel@....cz, mrex@....com, jim@...n.com, marco@....nl,
	dan@...htwave.net.ru, bugtraq@...urityfocus.com
Subject: Re: /proc filesystem allows bypassing directory permissions on

Gabor Gombas wrote:
> 
> On Mon, Nov 02, 2009 at 08:53:26PM +0100, Pavel Machek wrote:
> 
> > > The link count of a files tells you the number of hard links that
> > > are persisted within the same filesystem.  It is _NOT_ a promise
> > > that there are no other means to access the inode of the file.
> > 
> > It used to be promise before /proc was mounted.

NOPE. There _NEVER_ was such a promise.

There may be flawed assumptions to that effect, but that doesn't
change history.

I couldn't find anything in the the POSIX 1003.1-2004 Online Edition
that _requires_ this to fail:

      int fd = open("/tmp/testfile", O_RDONLY);
      curmode = fcntl(fd,F_GETFD);
      curmode &= ~O_RDONLY;
      curmode |= O_RDWR;
      fcntl(fd,F_SETFD,curmode);

current AIX, HP-UX, Linux and Solaris seem to ignore that fcntl(F_SETFD)
for the access modes (read/write) entirely.

And the POSIX 1003.1-2004 Online Edition for fcntl(2) says
this in the RATIONALE:

  The arg values to F_GETFD, F_SETFD, F_GETFL, and F_SETFL all
  represent flag values to allow for future growth. Applications
  using these functions should do a read-modify-write operation
  on them, rather than assuming that only the values defined by
  this volume of IEEE Std 1003.1-2001 are valid. It is a common
  error to forget this, particularly in the case of F_SETFD.

Especially important: the last sentence!

Changing the access modes of a file descriptor is probably difficult
to implement.  It may be feasible for file in the filesystem which
has an inode with access permissions which could be checked.
Doing it for a socket might be a bad idea -- and usually impossible,
one cannot undo the shutdown(SHUT_WR) of a socket...

> 
> "mount --bind" behaves like a hard link and it does not increment the link
> count.

that seems to work similar to a hardlink on a directory (and also requires
root privileges).  It doesn't work for the same directory level, because
of this (the directory permissions of the mounted directories and
directories below it remain effective -- the permissions of directories
above disappear, however!

So yes, in a 2-level directory situation, the path permissions may also
disappear, voiding all flawed assumptions of an application about
path permission in an obvious way.

  /tmp/dir        0x700
  /tmp/dir/subdir 0x755
  /tmp/dir/subdir/secret_file_with_improper_permissions  0x666

if root has issued
mount --bind /tmp/dir/subdir /mnt
then secret_file_with_improper_permissions will be accessible
through an additonal path in the filesystem and this will not
be reflected in the inode link counts.

-Martin