Node:new vulnerabilities, Next:exposed vulnerabilities, Previous:Security, Up:Security
Many security holes can be exploited much more easily if the attacker
can create an arbitrary file on your system. As a simple example, if a
bug allows attackers to run any program on your machine, SFS allows them
to supply the program somewhere under /sfs
. Moreover, the file
can have any numeric user and group (though of course, SFS disables
setuid and devices).
.
in path
Another potential problem users putting the current working directory
.
in their PATH environment variables. If you are browsing
a file system whose owner you do not trust, that owner can run arbitrary
code as you by creating programs named things like ls
in the
directories you are browsing. Putting .
in the PATH has
always been a bad idea for security, but a global file system like SFS
makes it much worse.
Users need to be careful about using untrusted file systems as if they were trusted file systems. Any file system can name files in any other file system by symbolic links. Thus, when randomly overwriting files in a file system you do not trust, you can be tricked, by symbolic links, into overwriting files on the local disk or another SFS file system.
As an example of a seemingly appealing use of SFS that can cause
problems, consider doing a cvs
checkout from an untrusted CVS
repository, so as to peruse someone else's source code. If you run
cvs
on a repository you do not trust, the person hosting the
repository could replace the CVSROOT/history
with a symbolic
link to a file on some other file system, and cause you to append
garbage to that file.
This cvs
example may or may not be a problem. For instance,
if you are about to compile and run the software anyway, you are placing
quite a bit of trust in the person running the CVS repository anyway.
The important thing to keep in mind is that for most uses of a file
system, you are placing some amount of trust in in the file server.
See resvgids, to see how users can run multiple agents with the
newaid
command. One way to cut down on trust is to access
untrusted file servers under a different agent with different private
keys. Nonetheless, this still allows the remote file servers to serve
symbolic links to the local file system in unexpected places.
Any user on the Internet can get the attributes of a
local-directory listed in an Export
directive
(see export). This is so users can run commands like ls -ld
on a self-certifying pathname in /sfs
, even if they cannot change
directory to that pathname or list files under it. If you wish to keep
attribute information secret on a local-directory, you will need
to export a higher directory. We may later reevaluate this design
decision, though allowing such anonymous users to get attributes
currently simplifies the client implementation.