> [Alexander Viro]
>
> > Huh? If attacker can link something outside of chroot jail you
> > are _already_ screwed - he can just access it directly.
>
> A local user can make restricted files available for anonymous FTP if
> he has write access somewhere inside the jail. A bit far fetched, I
> admit. A more plausible scenario is a user jailed in order to have
> access to special resouces in a safe manner, and an accomplice on the
> outside giving him access to additional (setuid) programs by linking
> them into the jail.
... or opens it and passes to attacker's process via anonymous AF_UNIX
socket.
> > > Think chmod() (by the admin after the "rogue" link()).
^^^^^^^^^^^^
> > s/admin/luser with root/. That's what find(1) is for. Blind
> > recursive _anything_ in places you don't control is asking for
> > trouble.
>
> Huh? I'm thinking:
> A creates a file which will contain a list of all students and their
> grades ("umask 002" rules :-)
> B links to the file
> A realizes he forgot to protect the directory
> A fills in the list
> B reads the list at leisure, and makes a fortune on blackmail. Or
> perhaps on private lessons.
>
> The nlink is easily overlooked.
I don't see where admin is mentioned in that scenario, but anyway: if you
are creating a file with sensible information - why the heck would you
make it world-readable in the first place? chmod on a directory might be a
good idea, but chmod 600 on the file is exactly what you need if you want
to stop other people from touching that file. What's that complex about
the idea that permissions on file are there to protect file contents?
The only case when admin is involved (aside of applying clue-by-four to
participants of the story) is when admin uses root for such data. I.e.
uses root for no good reason. IMO "luser with root" is perfectly accurate
in that case.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/