Re: [PATCH] new syscall: flink

Re: [PATCH] new syscall: flink

[Clayton Weaver]

One other thing: why O_CANLINK (suggested flag
to open) instead of O_NOLINK?

It seems to me that for the vast majority of
open()calls, you don't care whether the open
fd can be flink()ed to, because you don't pass
the file descriptor to an untrusted process.

A bit set to eliminate that capability is
the new feature one might need for security reasons with an implemented flink() call
available to programmers.

Seems like leaving "can be linked to" as the default setting and having an explicit flag
to prevent that would be more efficient.

Regards,

Clayton Weaver
<mailto: cgweav@email.com>


-- 
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Re: [PATCH] new syscall: flink

[David Wagner]

Clayton Weaver wrote:
>One other thing: why O_CANLINK (suggested flag
>to open) instead of O_NOLINK?

Because O_CANLINK fails secure; O_NOLINK fails open.
When security is on the line, you really want a fail-safe solution.

And the failure mode of forgetting to specify an O_NOLINK flag
where it should have been specified is going to be a common one.

Re: [PATCH] new syscall: flink

[Clayton Weaver]

> [David Wagner, "should fail closed", ie with
the capability to flink()to any given open file
descriptor disabled by default]

Ok, that's reasonable. I was imagining that
guessing when you need to enable it for an
open fd that is going to be inherited by
someone else's code that may not even have
been written yet is rather a vague proposition,
while guessing when you need to disable it regardless of what the code that you pass it to
does is likely to be all too clear and made
much of in online discussions.

But some application author not noticing that a potential flink() vulnerability is there at all will perhaps be the more common failure
scenario(so I yield the point).

flink() does seem a useful tool that I've wanted in the past (for reasons similar to the linker
example) if one could get around the implicit
security risk of a naive implementation.

Regards,

Clayton Weaver
<mailto: cgweav@email.com>


-- 
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Re: [PATCH] new syscall: flink

[Clayton Weaver]

----- Original Message -----
From: Werner Almesberger <wa@almesberger.net>
Date: Mon, 7 Apr 2003 15:43:03 -0300
To: Clayton Weaver <cgweav@email.com>
Subject: Re: [PATCH] new syscall: flink

> Clayton Weaver wrote:
> > If the client process subsequently flink()s to the inode, it is merely
> > a zerocopy file copy.

> As far as access to the data is concerned, yes. But there's also the
> location of the file. E.g. this might enable you to fill somebody
> else's quota, or, if distinct physical devices can be be covered by
> the same file system, to access a physical device that would
> otherwise not be available to you.

> Example: I write some kind of RAID mounted at /world, that contains
> my disk under /world/disk, and some Flash storage under /world/flash.
> I protect /world/flash against writes by other people. If a
> read-only FD could be turned into something writeable, some malicious
> creature could "wear out" my Flash by writing to it a lot of times.

> - Werner

I'm wondering about the semantics of the unlink
of the last directory entry and subsequent
flink(). When is the inode updated?
 
I presume that the open fd has owner and mode
information from open(), but would flink()update the inode with new owner information if the
last directory reference had already been
unlinked, and how would this interact with
owner information associated with the open fd
for subsequent file operations? Would fchmod() then succeed, even if the new process is not
owned by the original owner of the flink()ed
to inode? Are any changes to the inode data
delayed until after close()?

What about multiple flink()s before an inode
update has appeared in the filesystem?

It seems to me that "change of owner of the inode" via flink() is an issue, and application programmers that unlink the last directory reference and then pass the open fd to another process had better have no sentimental attachment to the existing access constraints on the file. flink(), close(), open() isn't exactly a difficult hoop to jump through, even if you've passed an
open fd for a read-only file (that you unlinked
any directory references to).

Regards,

Clayton Weaver
<mailto: cgweav@email.com>


-- 
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Re: [PATCH] new syscall: flink

[Chuck Ebbert]

Ulrich Drepper wrote:


>  + temp files which have to be completed first before renamed.  Here
>    flink() and frename() would introduce the name in the filesystem.
>    This is obviously useful in many many places, e.g., the linker
>    scenario.  There is no way to attack the linker while it is doing
>    its work since the output file isn't visible until it is installed
>    under the final name.


 How about an O_LINKONCLOSE flag that says not to link the file until
it's closed?

--
 Chuck
 I am not a number!

Re: [PATCH] new syscall: flink

[Werner Almesberger]

I wrote:
> Example: I write some kind of RAID mounted at /world, that contains
> my disk under /world/disk, and some Flash storage under /world/flash.
> I protect /world/flash against writes by other people. If a
> read-only FD could be turned into something writeable, some malicious
> creature could "wear out" my Flash by writing to it a lot of times.

Just to clarify: the file in question would be inaccessible for the
abuser, and the read-only fd would have to be handed out by some
access mediator.

Obviously, if the abuser obtains a read-only fd directly by opening
a file, the hypothetical flink couldn't be used for privilege
escalation.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/

Re: [PATCH] new syscall: flink

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Linus Torvalds wrote:
> If you really really think you need this (and not just do it because
> some random idiot-customer doesn't understand security), then I would
> suggest you add a O_CANLINK flag to open, and require that that flag is
> set in the file descriptor.

Nobody would be stupid enough to let me work on customer issues related
to the kernel.  The requests come in through glibc users.

Anyway, there are two or three ways I can see:

- - add safelink() instead of flink()

   int safelink (const char *oldname, int fd, const char *newname)

  As Jakub explained, this syscall would check that the file referenced
  by oldname really corresponds to fd before making the link.

  If you need an example, take the linker.  The linking can take a long
  time.  The temporary output file has to be created early and there is
  sometimes enough time before the linking finished for even a human
  to figure out the temporary file's name and replace the file.  If then
  the final file is installed as root (since the linking succeeds)
  you'll have problems.

  There is of course the possibility that one compares the ino/dev of
  the temporary file and the file after the link (or rename, btw) but
  this means the wrong output file existed for some time and all that
  is left to do is to remove the file which might be critical if the
  system depends on the file always being present.


- - add the O_CANLINK.  Sure it's possible.  But see the next variant


- - add an open() flag to create files which are not present in the
  filesystem (Hurd has something like this).  open() would get as the
  filename the name of a directory.  Such a feature can be
  used for all kinds of temporary files:

  + files which never need names, i.e., don't have to be accessed
    through the filesystem; the advantage is that there would never
    be stray files in the filesystem if the program forgets to clean
    them up

  + temp files which have to be completed first before renamed.  Here
    flink() and frename() would introduce the name in the filesystem.
    This is obviously useful in many many places, e.g., the linker
    scenario.  There is no way to attack the linker while it is doing
    its work since the output file isn't visible until it is installed
    under the final name.

  Maybe the O_CANLINK flag idea is also necessary for this, don't know.
  The O_ANONYMOUS flag might include setting O_CANLINK.


I'm certainly not qualified to say whether this is viable or not.  The
safelink() idea certainly is implementable, just 3-4 more lines on top
of the flink() patch.  But this wouldn't be necessary if we'd have the
more complete support with the new open() flag(s).  Al mentioned to me
some problems with network filesystem in the context of flink().  So
somebody who understands these issues might want to comment.  It seems
there is some interest in this.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+khaN2ijCOnn/RHQRAm09AJ9Fin1Js+Qla9vVSRzawSASl0dCNACfdoU1
VxrcNGyC06OxRiQZ0+reo0k=
=PosI
-----END PGP SIGNATURE-----

Re: [PATCH] new syscall: flink

[Chuck Ebbert]

Ulrich Drepper wrote:


> The people who don't want to use /proc for security reasons better
> come up with fixes to make it acceptable.


 I already have one -- FreeBSD 5.  It's gained an unbelievable
amount of security features with the merge of the TrustedBSD code.

--
 Chuck

Re: [PATCH] new syscall: flink

[Fredrik Tolf]

On Tuesday 08 April 2003 00:25, Ulrich Drepper wrote:
> The use of /proc is growing and you'll find that more than just
> fexecve() will fail if you don't have /proc.

Well, that was no news, but still; you know like... shouldn't it be 
implemented? Or if I put it like this: If I were going to implemented, is 
there any kind of chance to get that public, not least considering that it is 
a new syscall and all?

Fredrik Tolf

Re: [PATCH] new syscall: flink

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fredrik Tolf wrote:

> If I've missed the introduction of a fexecve syscall, I'm sorry for wasting 
> your time.

There is no syscall.  The people who don't want to use /proc for
security reasons better come up with fixes to make it acceptable.  The
kernel lacks a number of syscalls which allow getting various pieces of
information and the only way to implement the functionality is via
/proc.  The use of /proc is growing and you'll find that more than just
fexecve() will fail if you don't have /proc.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+kfrw2ijCOnn/RHQRArnmAJ4y6lXO3Msq3NvnnVLp/NHzJK6oUwCgvIFu
Aw+0YsJzlYFtawxSjR5xPEQ=
=SYEg
-----END PGP SIGNATURE-----

Re: [PATCH] new syscall: flink

[Fredrik Tolf]

On Monday 07 April 2003 23:43, Ulrich Drepper wrote:
> Fredrik Tolf wrote:
> > Anyway, while we're on the subject, is it just me who would like to see a
> > fexec() call?
>
> If you'd run an up-to-date system (e.g., RHL9) you'd have fexecve()
> already.

Am I right if I guess that this is the execve("/proc/self/fd/?") solution? I'm 
asking since I'm running 2.4.20 right now and I do not have such a syscall.
I'm not sure if I truly like the idea of having to rely on the existence of 
the proc fs, especially not since there is the chroot call. fexecve would 
also be a nice thing just because of that, since it allows you to keep a file 
descriptor over a chroot away from any /proc accessibility and then exec it.
For that reason, a fexec call could increase security in certain areas.

If I've missed the introduction of a fexecve syscall, I'm sorry for wasting 
your time.

Fredrik Tolf

Re: [PATCH] new syscall: flink

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fredrik Tolf wrote:

> Anyway, while we're on the subject, is it just me who would like to see a
> fexec() call?

If you'd run an up-to-date system (e.g., RHL9) you'd have fexecve() already.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+kfD92ijCOnn/RHQRAhO2AKCOD1ugVpxvM6shymsylznP/tsYmQCfbODX
n+wHxIQMq9G8Tfi2/0seh7I=
=EJxb
-----END PGP SIGNATURE-----

Re: [PATCH] new syscall: flink

[Fredrik Tolf]

On Monday 07 April 2003 05:39, H. Peter Anvin wrote:
> Followup to:
> <Pine.BSO.4.44.0304062250250.9407-100000@kwalitee.nolab.conman.org> By
> author:    Mark Grosberg <mark@nolab.conman.org>
> In newsgroup: linux.dev.kernel
>
> > > > Suppose I give you an O_RDONLY handle to a file which you then
> > > > flink and gain write access too ?
> > >
> > > This, I believe, is the real issue.  However, we already have that
> > > problem:
> >
> > As far as I understand it, isn't the protection information stored in the
> > inode? The flink call is just linking an inode into a directory that the
> > caller has write access to. The permissions and ownership of the file
> > shouldn't change.
>
> The problem is when you get passed a file descriptor from another
> process (via exec or file-descriptor passing) and you don't have
> permissions to access the *directory*.

Does that really matter? If the user owning the process has write permission
to the file, it can't possibly hurt security that he gains write access as
well to it using flink, right?
If it would prove to be a security hole anyway, it should be easily remedied
by only allowing the call for the file's owner and root. It would admittedly
make the call less usable, but its main uses still remain, as I see it.

Anyway, while we're on the subject, is it just me who would like to see a
fexec() call?

Fredrik Tolf

Re: [PATCH] new syscall: flink

[H. Peter Anvin]

Followup to:  <b6scsk$18b$1@penguin.transmeta.com>
By author:    torvalds@transmeta.com (Linus Torvalds)
In newsgroup: linux.dev.kernel
> 
> As others have pointed out, there is no way in HELL we can do this
> securely without major other incursions.
> 

If so, we already have the security hole... and we need to fix it.

> In particular, both flink() and funlink() require that you do all the
> same permission checks that a real link() or unlink() would do. And as
> some of them are done on the _source_ of the file, that implies that
> they have to be done at open() time.

[f]link() doesn't do any checks that open() doesn't, except for the
O_RDONLY/O_WRONLY/O_RDWR flags.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Re: [PATCH] new syscall: flink

[H. Peter Anvin]

Followup to:  <20030407165009.13596.qmail@email.com>
By author:    "Clayton Weaver" <cgweav@email.com>
In newsgroup: linux.dev.kernel
> 
> Since the client owns the new directory entry, it can chmod the
> inode to have any permissions it wants, create or modify an ACL
> where ACLs are in use, modify a capabilities mask more fine-grained
> than traditional unix permissions if something like that is in use,
> etc.
> 

Uhm, no.  Ownership is an inode property.

     -hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Re: [PATCH] new syscall: flink

[H. Peter Anvin]

Bill Rugolsky Jr. wrote:
> 
> We discussed this previously; I described the problems with
> existing semantics, and on 2000/020/29 you wrote:
> 
> http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=fa.iqoa6kv.flii0q%40ifi.uio.no&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26q%3Dhpa%2Brugolsky%26btnG%3DGoogle%2BSearch
> 
>   "I'm hoping to fix this in 2.5.  The problem is that the way open() is
>   done in the VFS *requires* the creation of a new filestructure."
> 
> I'm still open to suggestions. ;-)
> 

I suggested at one point the following change:

Instead of having the filesystem open() method being passed in a pointer 
to already allocated, partially initialized file structure, that code 
should be moved to a library function, and instead let the open() method 
return a struct file *.  That way open() could either return a reference 
to an already-allocated file or a new one.

	-hpa

Re: [PATCH] new syscall: flink

[Bill Rugolsky Jr.]

On Mon, Apr 07, 2003 at 07:57:08AM -0700, H. Peter Anvin wrote:
> Personally I would prefer if open() on
> /proc/*/fd would actually operate as if a dup() on the relevant file
> descriptor, which would be a significant change of semantics; however,
> one could argue those are the saner semantics.

We discussed this previously; I described the problems with
existing semantics, and on 2000/020/29 you wrote:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=fa.iqoa6kv.flii0q%40ifi.uio.no&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26q%3Dhpa%2Brugolsky%26btnG%3DGoogle%2BSearch

  "I'm hoping to fix this in 2.5.  The problem is that the way open() is
  done in the VFS *requires* the creation of a new filestructure."

I'm still open to suggestions. ;-)

Regards,

   Bill Rugolsky

Re: [PATCH] new syscall: flink

[Wichert Akkerman]

Previously H. Peter Anvin wrote:
> b) This is a security hole, in which case /proc needs to be fixed.  In
> particular, the open("/proc/self/fd/3", O_RDWR) in my example above
> should return EPERM.

proc might not be a problem if you deal with a chroot or namespace which
doesn't have proc mounted and no processes running with mount
capabilities. flink could still be a problem in those situations.

Wichert.

-- 
Wichert Akkerman <wichert@wiggy.net>           http://www.wiggy.net/
A random hacker

Re: [PATCH] new syscall: flink

[Werner Almesberger]

Clayton Weaver wrote:
> If the client process subsequently flink()s to the inode, it is merely
> a zerocopy file copy.

As far as access to the data is concerned, yes. But there's also the
location of the file. E.g. this might enable you to fill somebody
else's quota, or, if distinct physical devices can be be covered by
the same file system, to access a physical device that would
otherwise not be available to you.

Example: I write some kind of RAID mounted at /world, that contains
my disk under /world/disk, and some Flash storage under /world/flash.
I protect /world/flash against writes by other people. If a
read-only FD could be turned into something writeable, some malicious
creature could "wear out" my Flash by writing to it a lot of times.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/

Re: [PATCH] new syscall: flink

[David Wagner]

Clayton Weaver wrote:
>Once a process unlinks the last directory entry referencing a particular
>inode that it has an
>open fd for and then passes the open fd to some other process
>(regardless of exactly how it does that), it seems to me that it has
>conceded any interest in the previous security constraints associated
>with that inode or with the recently
>unlinked last directory entry for it.

Huh?  That's not the Unix model.  If I pass you a read-only file
descriptor, you're not supposed to be able to get write access to
the fd.  If you can, that's a security hole.  This is true whether
the fd refers to an inode still linked into the filesystem or not.

>The cases with potential security implications are all in the context of
>flink()ing to an open fd for an inode that still corresponds to at least
>one directory entry.

No, that's not correct.

Re: [PATCH] new syscall: flink

[Linus Torvalds]

In article <3E90746A.2010300@redhat.com>,
Ulrich Drepper  <drepper@redhat.com> wrote:
>
>I got a couple of requests for a function which isn't support on Linux
>so far.  Also not supportable, i.e., cannot be emulated at userlevel.
>It has some history in other systems (QNX I think), though, and helps
>with some security issues.  It really not adding much new functionality
>and I hope I got it right with my "monkey see, monkey do" technique of
>looking up other places doing similar things.

As others have pointed out, there is no way in HELL we can do this
securely without major other incursions.

In particular, both flink() and funlink() require that you do all the
same permission checks that a real link() or unlink() would do. And as
some of them are done on the _source_ of the file, that implies that
they have to be done at open() time.

One check in particular is "is the opener willing to let this be linked
anywhere else in the namespace". Since the opener isn't necessarily the
same agent as the one doing the flink().

If you really really think you need this (and not just do it because
some random idiot-customer doesn't understand security), then I would
suggest you add a O_CANLINK flag to open, and require that that flag is
set in the file descriptor.

That way you get "flink()" behaviour, but you require that the opener be
aware of the fact that the file may be linked into another position.
That will fix the glaring security hole.

		Linus

Re: [PATCH] new syscall: flink

[Arjan van de Ven]

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

On Mon, 2003-04-07 at 18:50, Clayton Weaver wrote:

> The cases with potential security implications are all in the context of flink()ing to an open fd for an inode that still corresponds to at least one directory entry.

almost.
there is of course always the case of a setuid app doing a userspace ACL
like thing and only sending fd's to non-privileged apps based on some
security scheme..... flink() would sort of break this thing entirely

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] new syscall: flink

[Clayton Weaver]

Once a process unlinks the last directory entry referencing a particular inode that it has an
open fd for and then passes the open fd to some other process (regardless of exactly how it does that), it seems to me that it has conceded any interest in the previous security constraints associated with that inode or with the recently
unlinked last directory entry for it. If the client process subsequently flink()s to the inode, it is merely a zerocopy file copy.

Since the client owns the new directory entry, it can chmod the inode to have any permissions it wants, create or modify an ACL where ACLs are in use, modify a capabilities mask more fine-grained than traditional unix permissions if something like that is in use, etc.

The cases with potential security implications are all in the context of flink()ing to an open fd for an inode that still corresponds to at least one directory entry.
 
Regards,

Clayton Weaver
<mailto: cgweav@email.com>


-- 
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Re: [PATCH] new syscall: flink

[Shaya Potter]

On Mon, 2003-04-07 at 02:43, David Wagner wrote:
> H. Peter Anvin wrote:
> >Here is a better piece of sample code that actually shows a
> >permissions violation happening:
> >
> >[...]
> >mkdir("testdir", 0700)                  = 0
> >open("testdir/testfile", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
> >write(3, "Ansiktsburk\n", 12)           = 12
> >close(3)                                = 0
> >open("testdir/testfile", O_RDONLY)      = 3
> >chmod("testdir", 0)                     = 0
> >open("/proc/self/fd/3", O_RDWR)         = 4
> >write(4, "Tjo fidelittan hatt!\n", 21)  = 21
> 
> You're right!  Good point. I retract the comments in my previous email.
> (I did try an experiment like this, but apparently not the right one.)
> 
> My conclusion: /proc/*/fd is a security hole.  It should be fixed.
> Do you agree?

I'm somewhat confused, why don't /proc/*/fd entries behave like normal
symbolic links?  i.e. shouldn't the inodes just be a symbolic link to
the d_path() of the fd?  Since symbolic links have to travel the entire
path (hence calling fs->permission() or vfs_permission() on each dir) it
should catch that problem.

Is my understanding of the design wrong? Or is that right, and it's just
the implementation that's broken?

just wondering, thanks,

shaya

Re: [PATCH] new syscall: flink

[H. Peter Anvin]

Followup to:  <20030407113534.1de8dc91.agri@desnol.ru>
By author:    Vitaly <agri@desnol.ru>
In newsgroup: linux.dev.kernel
>
> On Mon, 7 Apr 2003 00:09:01 -0700 (PDT)
> David Wagner <daw@cs.berkeley.edu> wrote:
> 
> > > > >mkdir("testdir", 0700)                  = 0
> > > > >open("testdir/testfile", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
> > > > >write(3, "Ansiktsburk\n", 12)           = 12
> > > > >close(3)                                = 0
> > > > >open("testdir/testfile", O_RDONLY)      = 3
> > > > >chmod("testdir", 0)                     = 0
> > > > >open("/proc/self/fd/3", O_RDWR)         = 4
> > > > >write(4, "Tjo fidelittan hatt!\n", 21)  = 21
> > 
> > > open("/proc/self/fd/3", O_RDWR) -- i thought, it just makes a copy for fd/3, and fd/3 should have the same permissions as it was opened.
> > 
> > 
> > It should have the same permissions, but it doesn't.  Try the sample code!
> > This looks like a security hole to me.
> 
> Yep, you are write it's a big hole but it's not a security hole. 
> 

That is what people are arguing it is.  It is certainly a *potential*
security hole.  There are two possibilities:

a) Either flink() is harmless and we should be able to add it.

b) This is a security hole, in which case /proc needs to be fixed.  In
particular, the open("/proc/self/fd/3", O_RDWR) in my example above
should return EPERM.

> It is mistake of abstraction. ls show file in /proc/self/fd as
> symbolic links and kernel tries to work with it as symbolic
> links. Because there will be a problem when program can access file
> from cwd but cannot access from absolute path, also after chroot and
> after changing cwd. Therefore it just test permissions of the file
> and don't checks any directories in the path. It works as a program
> doing smth like that: cd testdir open testfile open /proc/self/fd/3
> (in mind: open testfile again)
> 
> it was a choice of proceed, and it's a bad choice.
> I think that "open("/proc/self/fd/3", O_RDWR)" should forget anything about "testdir/testfile" and should only check permissions for proc/self/fd/3.
> using your test program i got
> open("testfile", O_RDONLY) = 3
> open("/proc/self/fd/3", O_RDWR) = 5

You've clearly changed it around; the file descriptor should be 4.
 
> and ls /proc/self/fd:
> l-wx------   3 -> /.../testfile
> lrwx------   5 -> /.../testfile
> 
> my proceed: if fd 3 have permission l-wx------ it cannot be opened for reading anyway only for writing and execution.

You'd think, but it doesn't work that way.  By the way, I
get:

lr-x------    1 hpa      eng            64 Apr  7 07:54 3 ->
/home/hpa/flink/testdir/testfile
lrwx------    1 hpa      eng            64 Apr  7 07:54 4 ->
/home/hpa/flink/testdir/testfile

... not l-wx------ which would be an O_WRONLY file descriptor.

Personally I would prefer if open() on
/proc/*/fd would actually operate as if a dup() on the relevant file
descriptor, which would be a significant change of semantics; however,
one could argue those are the saner semantics.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Re: [PATCH] new syscall: flink

[Roman Zippel]

Hi,

On Mon, 7 Apr 2003, Andreas Schwab wrote:

> |> I wouldn't rely on this functionality, not all filesystems might like it 
> |> to have to recreate a deleted fs entry. Most filesystems should be able to 
> |> do this, but all fs drivers have to be checked, that they do the right 
> |> thing.
> 
> All filesystems already have to cope with unlinking of an open file
> anyway, so relinking should not be a problem.

I know, but creating a new dir entry and linking to an existing dir entry 
is not always the same, e.g. filesystems, where a dir entry is not simply 
a pointer to an inode table, have to update other entries as well to 
create a new link. So far filesystems could assume that source dentry was 
a valid dir entry, this patch changes this.

bye, Roman

Re: [PATCH] new syscall: flink

[Andreas Schwab]

Roman Zippel <zippel@linux-m68k.org> writes:

|> Hi,
|> 
|> > That breaks one of the main uses, creating with open a temporary file
|> > in /tmp, unlinking it, then later hooking it up somewhere else in the
|> > filesystem.
|> 
|> I wouldn't rely on this functionality, not all filesystems might like it 
|> to have to recreate a deleted fs entry. Most filesystems should be able to 
|> do this, but all fs drivers have to be checked, that they do the right 
|> thing.

All filesystems already have to cope with unlinking of an open file
anyway, so relinking should not be a problem.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH] new syscall: flink

[Roman Zippel]

Hi,

> That breaks one of the main uses, creating with open a temporary file
> in /tmp, unlinking it, then later hooking it up somewhere else in the
> filesystem.

I wouldn't rely on this functionality, not all filesystems might like it 
to have to recreate a deleted fs entry. Most filesystems should be able to 
do this, but all fs drivers have to be checked, that they do the right 
thing.

bye, Roman

Re: [PATCH] new syscall: flink

[Alan Cox]

On Llu, 2003-04-07 at 10:11, Olivier Galibert wrote:
> On Mon, Apr 07, 2003 at 04:35:56AM -0400, Jakub Jelinek wrote:
> > There is at most one path associated with an opened file - d_path on
> > file->f_dentry. If a fd has no path, don't permit flink().
> > Alternatively, flink() could have 3 arguments, 2 like link and an opened
> > fd, which would atomically do if fd describes the same object as buf,
> > link buf to newname.
> 
> That breaks one of the main uses, creating with open a temporary file
> in /tmp, unlinking it, then later hooking it up somewhere else in the
> filesystem.

/tmp is normally on another file system so its not going to work anyway

Re: [PATCH] new syscall: flink

[Olivier Galibert]

On Mon, Apr 07, 2003 at 10:09:15AM +0100, Malcolm Beattie wrote:
> Here's another example along similar lines: you can open a file
> O_APPEND and pass the descriptor along to another process (e.g. a
> security mediator process that hands out a file descriptor to a
> less-trusted recipient that it can use for appending entries only).
> fcntl() explicity prevents the clearing of the O_APPEND flag on a
> file which was opened with O_APPEND. With flink, one could flink()
> and re-open without O_APPEND: security hole.

That would be a big security hole waiting to happen though.  Nothing
forces the less trusted recipient not to send in zeroes or finish the
lines (for a text file) or respect a particular format (for a binary
file).

In practice, I tend to think that any secutiry scheme flink breaks is
brittle at best.  It requires passing a fd to a file which is owned by
the same uid than the untrusted process, and rely somehow on the
directory structure to prevent direct access to said file.  But the
trusted process must have had access to the file somehow, so, well,
it's really, really brittle.

/proc breaking it already isn't very surprising.

  OG.

Re: [PATCH] new syscall: flink

[Olivier Galibert]

On Mon, Apr 07, 2003 at 04:35:56AM -0400, Jakub Jelinek wrote:
> There is at most one path associated with an opened file - d_path on
> file->f_dentry. If a fd has no path, don't permit flink().
> Alternatively, flink() could have 3 arguments, 2 like link and an opened
> fd, which would atomically do if fd describes the same object as buf,
> link buf to newname.

That breaks one of the main uses, creating with open a temporary file
in /tmp, unlinking it, then later hooking it up somewhere else in the
filesystem.

  OG.

Re: [PATCH] new syscall: flink

[Malcolm Beattie]

David Wagner writes:
> H. Peter Anvin wrote:
> >Alan Cox wrote:
> >> Suppose I give you an O_RDONLY handle to a file which you then
> >> flink and gain write access too ?
> >
> >This, I believe, is the real issue.  However, we already have that
> >problem:
> 
> No, I don't think we already have that problem.  I think flink()
> would introduce a new security hole not already present.

Here's another example along similar lines: you can open a file
O_APPEND and pass the descriptor along to another process (e.g. a
security mediator process that hands out a file descriptor to a
less-trusted recipient that it can use for appending entries only).
fcntl() explicity prevents the clearing of the O_APPEND flag on a
file which was opened with O_APPEND. With flink, one could flink()
and re-open without O_APPEND: security hole.

--Malcolm

-- 
Malcolm Beattie <mbeattie@clueful.co.uk>

Re: [PATCH] new syscall: flink

[Clayton Weaver]

Do file access capabilities (and ACLs where those
are enabled)attach to the directory entry or the inode for a file? 

I remember Linus wishing that capabilities
on files could have different multiple concurrent values in different directory entry contexts.
Seems like the kernel would need to be able
to trump these "capability views", which
would need to be associated with directory
entries, based on data stored with the inode
(so that you can drop capabilities when creating
a link but you can't elevate them).

(Someone already mentioned in this thread that traditional unix permissions are stored in the inode.)

The restricted directories with loose permissions
on the files within them looks more like an
application programmer issue than a kernel issue to me. The parent or server could always chmod the file(or copy it to a read-only file and open that) before execing or passing the open fd.

So who owns the inode? Or does "owned by
uid #N" only make sense in the context of a
directory entry? If so, does ownership of the linked-to fd propagate to the new directory
entry from the old directory entry? What if it
had been unlinked before the flink()?

Seems like the ultimate security constraints on files have to be stored in the inode or your security is potentially hosed merely by the ability to create a new directory entry for the same inode from a different uid (whether it
needs to do it in a different directory is a
separate issue). 
 
Regards,

Clayton Weaver
<mailto: cgweav@email.com>

-- 
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Re: [PATCH] new syscall: flink

[Jakub Jelinek]

On Mon, Apr 07, 2003 at 10:18:00AM +0200, Olivier Galibert wrote:
> On Mon, Apr 07, 2003 at 07:29:35AM +0000, Miquel van Smoorenburg wrote:
> > Can't you just check those permissions, i.e. behave like link() ?
> > If you cant't access the path to the file, don't permit flink() ?
> 
> Which path ?  A file can have many paths to it, or to the other
> extreme none at all.

There is at most one path associated with an opened file - d_path on
file->f_dentry. If a fd has no path, don't permit flink().
Alternatively, flink() could have 3 arguments, 2 like link and an opened
fd, which would atomically do if fd describes the same object as buf,
link buf to newname.

	Jakub

Re: [PATCH] new syscall: flink

[Olivier Galibert]

On Mon, Apr 07, 2003 at 07:29:35AM +0000, Miquel van Smoorenburg wrote:
> Can't you just check those permissions, i.e. behave like link() ?
> If you cant't access the path to the file, don't permit flink() ?

Which path ?  A file can have many paths to it, or to the other
extreme none at all.

  OG.

Re: [PATCH] new syscall: flink

[Vitaly]

On Mon, 7 Apr 2003 00:09:01 -0700 (PDT)
David Wagner <daw@cs.berkeley.edu> wrote:

> > > >mkdir("testdir", 0700)                  = 0
> > > >open("testdir/testfile", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
> > > >write(3, "Ansiktsburk\n", 12)           = 12
> > > >close(3)                                = 0
> > > >open("testdir/testfile", O_RDONLY)      = 3
> > > >chmod("testdir", 0)                     = 0
> > > >open("/proc/self/fd/3", O_RDWR)         = 4
> > > >write(4, "Tjo fidelittan hatt!\n", 21)  = 21
> 
> > open("/proc/self/fd/3", O_RDWR) -- i thought, it just makes a copy for fd/3, and fd/3 should have the same permissions as it was opened.
> 
> 
> It should have the same permissions, but it doesn't.  Try the sample code!
> This looks like a security hole to me.

Yep, you are write it's a big hole but it's not a security hole.
It is mistake of abstraction. ls show file in /proc/self/fd as symbolic links and kernel tries to work with it as symbolic links. Because there will be a problem when program can access file from cwd but cannot access from absolute path, also after chroot and after changing cwd. Therefore it just test permissions of the file and don't checks any directories in the path. It works as a program doing smth like that:
cd testdir
open testfile
open /proc/self/fd/3 (in mind: open testfile again)

it was a choice of proceed, and it's a bad choice.
I think that "open("/proc/self/fd/3", O_RDWR)" should forget anything about "testdir/testfile" and should only check permissions for proc/self/fd/3.
using your test program i got
open("testfile", O_RDONLY) = 3
open("/proc/self/fd/3", O_RDWR) = 5

and ls /proc/self/fd:
l-wx------   3 -> /.../testfile
lrwx------   5 -> /.../testfile

my proceed: if fd 3 have permission l-wx------ it cannot be opened for reading anyway only for writing and execution.

Agri

> -- David
> 

Re: [PATCH] new syscall: flink

[Miquel van Smoorenburg]

In article <b6qruf$elf$1@cesium.transmeta.com>,
H. Peter Anvin <hpa@zytor.com> wrote:
>Followup to: 
><Pine.BSO.4.44.0304062250250.9407-100000@kwalitee.nolab.conman.org>
>By author:    Mark Grosberg <mark@nolab.conman.org>
>> As far as I understand it, isn't the protection information stored in the
>> inode? The flink call is just linking an inode into a directory that the
>> caller has write access to. The permissions and ownership of the file
>> shouldn't change.
>
>The problem is when you get passed a file descriptor from another
>process (via exec or file-descriptor passing) and you don't have
>permissions to access the *directory*.

Can't you just check those permissions, i.e. behave like link() ?
If you cant't access the path to the file, don't permit flink() ?

Mike.
-- 
Linux isnt at war. War involves large numbers of people making losing decisions
that harm each other in a vain attempt to lose last. Linux is about winning.
	-- Alan Cox, linux-kernel, <E1276kG-00019y-00@the-village.bc.nu>

Re: [PATCH] new syscall: flink

[David Wagner]

H. Peter Anvin wrote:
>Here is a better piece of sample code that actually shows a
>permissions violation happening:
>
>[...]
>mkdir("testdir", 0700)                  = 0
>open("testdir/testfile", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
>write(3, "Ansiktsburk\n", 12)           = 12
>close(3)                                = 0
>open("testdir/testfile", O_RDONLY)      = 3
>chmod("testdir", 0)                     = 0
>open("/proc/self/fd/3", O_RDWR)         = 4
>write(4, "Tjo fidelittan hatt!\n", 21)  = 21

You're right!  Good point. I retract the comments in my previous email.
(I did try an experiment like this, but apparently not the right one.)

My conclusion: /proc/*/fd is a security hole.  It should be fixed.
Do you agree?

Re: [PATCH] new syscall: flink

[Vitaly]

On 7 Apr 2003 06:43:40 GMT
daw@mozart.cs.berkeley.edu (David Wagner) wrote:

> H. Peter Anvin wrote:
> >Here is a better piece of sample code that actually shows a
> >permissions violation happening:
> >
> >[...]
> >mkdir("testdir", 0700)                  = 0
> >open("testdir/testfile", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
> >write(3, "Ansiktsburk\n", 12)           = 12
> >close(3)                                = 0
> >open("testdir/testfile", O_RDONLY)      = 3
> >chmod("testdir", 0)                     = 0
> >open("/proc/self/fd/3", O_RDWR)         = 4
> >write(4, "Tjo fidelittan hatt!\n", 21)  = 21
> 
> You're right!  Good point. I retract the comments in my previous email.
> (I did try an experiment like this, but apparently not the right one.)
> 
> My conclusion: /proc/*/fd is a security hole.  It should be fixed.
> Do you agree?
open("/proc/self/fd/3", O_RDWR) -- i thought, it just makes a copy for fd/3, and fd/3 should have the same permissions as it was opened.

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

Re: [PATCH] new syscall: flink

[H. Peter Anvin]

Followup to:  <b6qo2a$ecl$1@cesium.transmeta.com>
By author:    "H. Peter Anvin" <hpa@zytor.com>
In newsgroup: linux.dev.kernel
> 
> This, I believe, is the real issue.  However, we already have that
> problem:
> 

[Sample code]

Here is a better piece of sample code that actually shows a
permissions violation happening:

[...]
mkdir("testdir", 0700)                  = 0
open("testdir/testfile", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
write(3, "Ansiktsburk\n", 12)           = 12
close(3)                                = 0
open("testdir/testfile", O_RDONLY)      = 3
chmod("testdir", 0)                     = 0
open("/proc/self/fd/3", O_RDWR)         = 4
write(4, "Tjo fidelittan hatt!\n", 21)  = 21
exit_group(0)                           = ?

----snip----

#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <limits.h>

int main(int argc, char *argv[])
{
  int sfd, rfd, wfd;
  char filebuf[PATH_MAX];

  mkdir("testdir", 0700);

  /* Create the file legitimately */
  sfd = open("testdir/testfile", O_WRONLY|O_CREAT|O_TRUNC, 0666);
  write(sfd, "Ansiktsburk\n", 12);
  close(sfd);

  /* Open read-only file descriptor */
  rfd = open("testdir/testfile", O_RDONLY);

  /* Make directory inaccessible */
  chmod("testdir", 0);

  /* Open read-write file descriptor */
  sprintf(filebuf, "/proc/self/fd/%d", rfd);
  wfd = open(filebuf, O_RDWR);

  /* Clobber file */
  write(wfd, "Tjo fidelittan hatt!\n", 21);

  return 0;
}
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Re: [PATCH] new syscall: flink

[H. Peter Anvin]

Followup to:  <Pine.BSO.4.44.0304062250250.9407-100000@kwalitee.nolab.conman.org>
By author:    Mark Grosberg <mark@nolab.conman.org>
In newsgroup: linux.dev.kernel
> 
> > > Suppose I give you an O_RDONLY handle to a file which you then
> > > flink and gain write access too ?
> >
> > This, I believe, is the real issue.  However, we already have that
> > problem:
> 
> As far as I understand it, isn't the protection information stored in the
> inode? The flink call is just linking an inode into a directory that the
> caller has write access to. The permissions and ownership of the file
> shouldn't change.
> 

The problem is when you get passed a file descriptor from another
process (via exec or file-descriptor passing) and you don't have
permissions to access the *directory*.

My example, though, shows that we have this problem already.

> > int main(int argc, char *argv[])
> > {
> >   int rfd, wfd;
> >   char filebuf[PATH_MAX];
> >
> >   rfd = open("testfile", O_RDONLY|O_CREAT, 0666);
> >   /* Now rfd is a read-only file descriptor */
> 
> There is nothing stopping the caller from re-opening the to-be flinked()
> file descriptor read-write using its name if the caller has permissions.
> So I don't see why that case is different.

Again, permissions on the directory.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Re: [PATCH] new syscall: flink

[Mark Grosberg]

On Sun, Apr 6 2003, H. Peter Anvin wrote:

> > Suppose I give you an O_RDONLY handle to a file which you then
> > flink and gain write access too ?
>
> This, I believe, is the real issue.  However, we already have that
> problem:

As far as I understand it, isn't the protection information stored in the
inode? The flink call is just linking an inode into a directory that the
caller has write access to. The permissions and ownership of the file
shouldn't change.

> int main(int argc, char *argv[])
> {
>   int rfd, wfd;
>   char filebuf[PATH_MAX];
>
>   rfd = open("testfile", O_RDONLY|O_CREAT, 0666);
>   /* Now rfd is a read-only file descriptor */

There is nothing stopping the caller from re-opening the to-be flinked()
file descriptor read-write using its name if the caller has permissions.
So I don't see why that case is different.

Other than that, HPA's responses make sense.

Personally, I would like to see this system call in Linux. It does make
certain thing easier. Not necessarily even in a security context, but
sometimes its generally useful to be able to make a hard link to an
already open file rather than track the name.

L8r,
Mark G.

Re: [PATCH] new syscall: flink

[H. Peter Anvin]

Followup to:  <1049663559.1602.46.camel@dhcp22.swansea.linux.org.uk>
By author:    Alan Cox <alan@lxorguk.ukuu.org.uk>
In newsgroup: linux.dev.kernel
> 
> It is actually rather more complicated. Suppose I give you a pipe
> pair handle. You can flink what was a private object and has no
> meaning as a name.
> 
> Suppose I give you a socket what does the call man ?
> 
> Suppose I give you a handle to an anonymous mapping ?
> 

-EXDEV

> Suppose I give you a handle to data, how do you know what disk
> it belongs to ?

f_ino->i_sb should give you that information.

> Suppose I give you an O_RDONLY handle to a file which you then
> flink and gain write access too ?

This, I believe, is the real issue.  However, we already have that
problem:

#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <limits.h>

int main(int argc, char *argv[])
{
  int rfd, wfd;
  char filebuf[PATH_MAX];

  rfd = open("testfile", O_RDONLY|O_CREAT, 0666);
  /* Now rfd is a read-only file descriptor */

  sprintf(filebuf, "/proc/self/fd/%d", rfd);
  wfd = open(filebuf, O_RDWR);
  /* Now wfd is a read-write file descriptor */

  write(wfd, "Tjo fidelittan hatt!\n", 21);

  return 0;
}


	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Re: [PATCH] new syscall: flink

[David Wagner]

H. Peter Anvin wrote:
>Alan Cox wrote:
>> Suppose I give you an O_RDONLY handle to a file which you then
>> flink and gain write access too ?
>
>This, I believe, is the real issue.  However, we already have that
>problem:

No, I don't think we already have that problem.  I think flink()
would introduce a new security hole not already present.


>  rfd = open("testfile", O_RDONLY|O_CREAT, 0666);
>  /* Now rfd is a read-only file descriptor */
>
>  sprintf(filebuf, "/proc/self/fd/%d", rfd);
>  wfd = open(filebuf, O_RDWR);

I don't think this is the same.  With /proc/self/fd, I can't escalate
privileges on a read-only fd.  You did the wrong test, because the user
already has write access to "testfile".  Change the above to make rfd a
read-only file descriptor to a file that I don't have write permission to,
and you'll find that the test all of a sudden fails.  (For instance, add
a chmod("testfile", 0444); between the two open()s, and see what happens.)

I think /proc/self/fd is doing the right thing.  /proc/self/fd doesn't
seem to be a security hole, unless I'm missing something.  I think flink()
would be a security risk, though.  Or did I overlook something?

Re: [PATCH] new syscall: flink

[Alan Cox]

On Sul, 2003-04-06 at 20:56, Oliver Neukum wrote:
> If you have an fd, the permissions based on the path are already
> bypassed, whether you can call flink or not, aren't they?

It is actually rather more complicated. Suppose I give you a pipe
pair handle. You can flink what was a private object and has no
meaning as a name.

Suppose I give you a socket what does the call man ?

Suppose I give you a handle to an anonymous mapping ?

Suppose I give you a handle to data, how do you know what disk
it belongs to ?

Suppose I give you an O_RDONLY handle to a file which you then
flink and gain write access too ?

Re: [PATCH] new syscall: flink

[Oliver Neukum]

Am Sonntag, 6. April 2003 22:08 schrieb Malcolm Beattie:
> Oliver Neukum writes:
> > If you have an fd, the permissions based on the path are already
> > bypassed, whether you can call flink or not, aren't they?
>
> Not if it's opened O_RDONLY, for example.

OK, so you could open a file RW even if the fd you get passed
is only RO, right?

	Regards
		Oliver

Re: [PATCH] new syscall: flink

[Malcolm Beattie]

Oliver Neukum writes:
> If you have an fd, the permissions based on the path are already
> bypassed, whether you can call flink or not, aren't they?

Not if it's opened O_RDONLY, for example.

--Malcolm

-- 
Malcolm Beattie <mbeattie@clueful.co.uk>

Re: [PATCH] new syscall: flink

[Oliver Neukum]

> Andrew Brown <atatat@atatdot.net> wrote:
>  ># as for flink(2), no.  flink(2) would be a terribly bad idea.  consider
>  ># that when opening a file, *all* the permissions on *all* the inodes in
>  ># the path to the file are considered.  if you were able to get some
>  ># process to hand you an open file descriptor to some file somewhere
>  ># that relies on being protected by permissions in the path and you were
>  ># able to flink(2) it to some arbitrary name, you could bypass the
>  ># permissions set that had been established.

If you have an fd, the permissions based on the path are already
bypassed, whether you can call flink or not, aren't they?

	Regards
		Oliver

Re: [PATCH] new syscall: flink

[Dan Kegel]

Dan Kegel wrote:
> How does this differ from fattach() in SuSv3
> (http://www.opengroup.org/onlinepubs/007904975/functions/fattach.html)?

Answering my own dumb question: fattach() is like mount, not ln.
- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

re: [PATCH] new syscall: flink

[Dan Kegel]

Ulrich wrote:
> I got a couple of requests for a function which isn't support on Linux
> so far.  Also not supportable, i.e., cannot be emulated at userlevel.
> It has some history in other systems (QNX I think), though, and helps
> with some security issues.

How does this differ from fattach() in SuSv3
(http://www.opengroup.org/onlinepubs/007904975/functions/fattach.html)?
(i.e. does the fact that fattach() is defined only for streams
fds make a difference?)

Out of curiosity, I did some searching for prior mentions of flink.
It gets proposed every two years or so, it seems.
There may be some security issues.  Here are two posts that
might be of interest (I wouldn't know, I'm not a security guru):

http://marc.theaimsgroup.com/?l=linux-kernel&m=88944672732020&w=2
Malcolm Beattie <mbeattie () sable ! ox ! ac ! uk> wrote:
> SysV calls this fattach() where fd is a STREAMS file descriptor
> (usually a STREAMS pipe). For general file descriptors, it has
> security implications. For example, you mustn't let it be legal
> for a process to get a read-only file descriptor and then link
> it into the file system because then it could change the file's
> permissions to read-write.

http://mail-index.netbsd.org/tech-userlevel/2001/09/29/0000.html
Andrew Brown <atatat@atatdot.net> wrote:
 ># as for flink(2), no.  flink(2) would be a terribly bad idea.  consider
 ># that when opening a file, *all* the permissions on *all* the inodes in
 ># the path to the file are considered.  if you were able to get some
 ># process to hand you an open file descriptor to some file somewhere
 ># that relies on being protected by permissions in the path and you were
 ># able to flink(2) it to some arbitrary name, you could bypass the
 ># permissions set that had been established.

- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

[PATCH] new syscall: flink

[Ulrich Drepper]

[-- Attachment #1.1: Type: text/plain, Size: 2354 bytes --]

I got a couple of requests for a function which isn't support on Linux
so far.  Also not supportable, i.e., cannot be emulated at userlevel.
It has some history in other systems (QNX I think), though, and helps
with some security issues.  It really not adding much new functionality
and I hope I got it right with my "monkey see, monkey do" technique of
looking up other places doing similar things.

The syscall I mean is

  int flink (int fd, const char *newname)

Similar to link(), but the first parameter is a file decsriptor.  Using
the file descriptor helps to avoid races in some situation.  Look at
this code bit (this is constructed and just a little test case):

#include <errno.h>
#define EE(a,x) {int e = a;if (e!=x)printf("%s = %d (%m)\n", #a, errno);}
#define E(a) EE(a,0)
int
main()
{
  printf("uid = %d, euid = %d, gid = %d, egid = %d\n", getuid(),
geteuid(), getgid(), getegid());
  E(setfsuid(getuid()));
  E(setfsgid(getgid()));
  char buf[] = "aaXXXXXX";
  int fd = mkstemp (buf);
  EE(setfsuid(0),getuid());
  EE(setfsgid(0),getgid());
  E(fchown(fd,48,48));
  E(setfsuid(getuid()));
  E(setfsgid(getgid()));
  E(syscall(268,fd,"aa"));
  E(unlink(buf));
  return 0;
}

This is for a SUID/SGID root application.  A temporary file is created
carefully using the permissions of the user running the program.  If the
syscall 268 (flink) line would be

  link(buf,"aa)

instead, somebody with limited priviledges could in theory have unlinked
the temporary file and created a new one.  With flink() this isn't
possible.  And the best is: the unlink() line can be moved right below
the mkstemp() call.  This means no temporary files are around if
something goes wrong before the unlink().  (For me this is at least as
important as the security issue, it simplifies temp file handling and
reduces the number of bugs == leftover fiels).

The patch itself is very minimal.  The impact on the link() syscall is
not measurable and the extra code for sys_flink is only a few bytes.

Is this acceptable?  Shall I add more syscall definitions for platforms
!= x86 (I'd think the port maintainers want to do this themselves)?

-- 
--------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------

[-- Attachment #1.2: d-kernel-flink --]
[-- Type: text/plain, Size: 3048 bytes --]

--- linux-2.5/arch/i386/kernel/entry.S-flink	2003-03-21 23:09:32.000000000 -0800
+++ linux-2.5/arch/i386/kernel/entry.S	2003-04-06 10:32:27.000000000 -0700
@@ -852,6 +852,7 @@ ENTRY(sys_call_table)
  	.long sys_clock_gettime		/* 265 */
  	.long sys_clock_getres
  	.long sys_clock_nanosleep
+	.long sys_flink
  
  
 nr_syscalls=(.-sys_call_table)/4
--- linux-2.5/fs/namei.c-flink	2003-04-03 10:04:03.000000000 -0800
+++ linux-2.5/fs/namei.c	2003-04-06 11:20:41.000000000 -0700
@@ -16,6 +16,7 @@
 
 #include <linux/init.h>
 #include <linux/slab.h>
+#include <linux/file.h>
 #include <linux/fs.h>
 #include <linux/namei.h>
 #include <linux/quotaops.h>
@@ -1796,10 +1797,10 @@ int vfs_link(struct dentry *old_dentry, 
  * with linux 2.0, and to avoid hard-linking to directories
  * and other special files.  --ADM
  */
-asmlinkage long sys_link(const char * oldname, const char * newname)
+static long link_common(struct vfsmount *old_mnt, struct dentry *old_dentry, const char *newname)
 {
 	struct dentry *new_dentry;
-	struct nameidata nd, old_nd;
+	struct nameidata nd;
 	int error;
 	char * to;
 
@@ -1807,32 +1808,53 @@ asmlinkage long sys_link(const char * ol
 	if (IS_ERR(to))
 		return PTR_ERR(to);
 
-	error = __user_walk(oldname, 0, &old_nd);
-	if (error)
-		goto exit;
 	error = path_lookup(to, LOOKUP_PARENT, &nd);
 	if (error)
-		goto out;
+		goto exit;
 	error = -EXDEV;
-	if (old_nd.mnt != nd.mnt)
+	if (old_mnt != nd.mnt)
 		goto out_release;
 	new_dentry = lookup_create(&nd, 0);
 	error = PTR_ERR(new_dentry);
 	if (!IS_ERR(new_dentry)) {
-		error = vfs_link(old_nd.dentry, nd.dentry->d_inode, new_dentry);
+		error = vfs_link(old_dentry, nd.dentry->d_inode, new_dentry);
 		dput(new_dentry);
 	}
 	up(&nd.dentry->d_inode->i_sem);
 out_release:
 	path_release(&nd);
-out:
-	path_release(&old_nd);
 exit:
 	putname(to);
 
 	return error;
 }
 
+asmlinkage long sys_link(const char *oldname, const char *newname)
+{
+	struct nameidata old_nd;
+	int error;
+
+	error = __user_walk(oldname, 0, &old_nd);
+	if (!error) {
+		error = link_common(old_nd.mnt, old_nd.dentry, newname);
+		path_release(&old_nd);
+	}
+	return error;
+}
+
+asmlinkage long sys_flink(unsigned int fd, const char *newname)
+{
+	struct file *file;
+	int error = -EBADF;
+
+	file = fget(fd);
+	if (file) {
+		error = link_common(file->f_vfsmnt, file->f_dentry, newname);
+		fput(file);
+	}
+	return error;
+}
+
 /*
  * The worst of all namespace operations - renaming directory. "Perverted"
  * doesn't even start to describe it. Somebody in UCB had a heck of a trip...
--- linux-2.5/include/asm-i386/unistd.h-flink	2003-02-19 21:41:59.000000000 -0800
+++ linux-2.5/include/asm-i386/unistd.h	2003-04-06 10:30:08.000000000 -0700
@@ -273,8 +273,9 @@
 #define __NR_clock_gettime	(__NR_timer_create+6)
 #define __NR_clock_getres	(__NR_timer_create+7)
 #define __NR_clock_nanosleep	(__NR_timer_create+8)
+#define __NR_flink		268
 
-#define NR_syscalls 268
+#define NR_syscalls 269
 
 /* user-visible error numbers are in the range -1 - -124: see <asm-i386/errno.h> */
 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]