Re: varlinks! (and 2.1.98 works for me)

Rogier Wolff (R.E.Wolff@BitWizard.nl)
Wed, 29 Apr 1998 10:35:59 +0200 (MET DST)

H. Peter Anvin wrote:
>
> > >
> > > First, let me point out that this same subject has been discussed here
> > > before. Second, let me say that I have used Apollo, which had this
> > > feature, and I think it's a great idea. It was previously objected
> > > that this feature was insecure, but I've never understood this
> > > objection. Perhaps someone would be kind enough to provide an example.
> >
> > Peter Anvin and I have been Emailing back and forth about this.
> > I think I now understand what he means by insecure:
> >
> > Suppose I do an "lpr -s '/home/wolff/${uid}'". Then lpr will pull a
> > symlink which might not mean what it intended into its "secure
> > environment".
> >
> > In this specific case, it might just print a different file than was
> > intended. I don't see any other problems. If the printing process
> > opens the file under my uid (which it should for security reasons) I
> > will be able to change where the symlink points. But I could've done
> > that already through modifying the filesystem. (just print something
> > that already is a symlink) The result is that I can print files that
> > I already had access to anyway.
> >
>
> No, no, no... you could potentially trick an app into indirecting
> though a symlink it otherwise wouldn't have indirected through,
> getting unauthorized access to a file.

So, I still don't get it. Explain please....

You mean something like

I configure my web server to allow symlinks into
'/home/wolff/${uid}'
but not into
'/home/wolff/99' (99 is "nobody" on my system)
But in this case the web server needs to follow the symlink "by
hand" (= the old way) anyway, to prevent hitting a symlink at the
end of the indirection.

Every time I find an example, it turns up dead. How about this one:

I ftp into a system where I'm not allowed to access files above
my home.
Now I pull a symlink "link -> ${blabla}".
Now as the ftpd sees that the link doesn't contain any ".." it
will allow me to access the link. However I maliciously make
the variable blabla=../../etc/passwd .
However, this ftpd is already flawed. It opened the file through
the link instead evaluating the link itself. It is vulnerable
to the file "${blabla}" (litterally) being a symlink to /etc/passwd
as well as the link could change after the readlink call.

Every time I find an example, it turns up dead.

> Why not just make it a new file type -- which it is -- and make a
> varlink() system call?

Because:
- That makes it much more complex.
- Added system call
- new "readlink" call
- change "ls" to interpret the new filesystem object.
- allow tar and dump to make backups of these objects.

- it won't work for other filesystems. (e.g. NFS).
(You can make a SUN server export a filesystem full of varlinks to
a bunch of Linux clients!).

- It breaks existing semantics that says that filesystem objects are
either file, directory, pipe, socket, char device, block device,
or symlink(*).

Any change is slightly "painful". And it is going to change the
existing API in some way. Even if the actual spec says "unspecified",
you get into trouble by changing it. Remember select?

Roger.

(*) I might have missed one or two.... 

-- 
If it's there and you can see it, it's REAL      |___R.E.Wolff@BitWizard.nl  |
If it's there and you can't see it, it's TRANSPARENT |  Tel: +31-15-2137555  |
If it's not there and you can see it, it's VIRTUAL   |__FAX:_+31-15-2138217  |
If it's not there and you can't see it, it's GONE! -- Roy Wilks, 1983  |_____|


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu