On Wed, 12 Sep 2007, Andreas Schwab wrote:
> Brent Casavant <[email protected]> writes:
>
> > I could mmap a temporary tmpfs file (tmpfs so that if there is a
> > machine crash no sensitive data persists) which is created with
> > permissions of 0, immediately unlink it, and pass the file
> > descriptor through an AF_UNIX socket. This does open up a very
> > small window of vulnerability if another process is able to chmod
> > the file and open it before the unlink.
>
> Only the owner can chmod a file, so why is that a vulnerability?
In this particular case because the user may not normally have direct
access to some of the data to be contained in that file.
Decryption keys in a key management system, in particular. If the
keys are passed over secure network links such that they only ever
exist in system RAM, and are not reachable via the filesystem, these
keys can be protected from disclosure to the user (short of /proc/#/mem
type of tricks). However, if there is even a brief window when the
user can gain access to the file, these keys are at risk of disclosure.
The problem can be addressed, in this case, by having the daemon half
of the design create these files, however it would provide a bit more
flexibility if the client side was also capable of creating them. It's
not a make-or-break problem, by any means, but does somewhat motivate
an O_NOLINK flag for open().
Brent
P.S. By the way, there doesn't seem to be a way to remove /proc/#/mem
files. That might be an additional nicety -- programs worried about
being snooped could unlink their own entry. /dev/mem and /dev/kmem
can simply be removed by the sysadmin of such a system. If all of
that were done you'd have to resort to attacking crash dumps, core
dumps, or via something like kdb to extract "hidden" data.
--
Brent Casavant All music is folk music. I ain't
[email protected] never heard a horse sing a song.
Silicon Graphics, Inc. -- Louis Armstrong
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
