ln -s

[iago]

This is a question for a linux guy: (*coughthingcough*)

Can symbolic links be uploaded, or can a file be edited to make a symbolic link, like the way a windows shortcut can be?  

I would think not, but I don't want people to be able to upload symlinks to my server

Thanks!

[Yoni]

A symbolic link isn't a file like .lnk in Windows. It's a file system element. It's a secondary entry in the file table that points to an already existing file.

So... No, I guess.

[iago]

A symbolic link isn't a file like .lnk in Windows. It's a file system element. It's a secondary entry in the file table that points to an already existing file.

So... No, I guess.

Ok, good, that's what I thought.  In the code I have here, they check it by doing an ls -l on an unchecked filename and check the first character.  I just killed that function; I don't like people executing arbitrary code

[Yoni]

In the code I have here, they check it by doing an ls -l on an unchecked filename and check the first character.

mv /bin/ls /bin/.ls
gcc evil.c -o /bin/ls

[iago]

In the code I have here, they check it by doing an ls -l on an unchecked filename and check the first character.

mv /bin/ls /bin/.ls
gcc evil.c -o /bin/ls

hmm, I would have just executed the command "myfile;ln -s /etc/passwd", then I could download passwd or whatever the actual password file is at my leasure.  We tested this, and we can actually download passwd through a symbolic link like that

[Kp]

hmm, I would have just executed the command "myfile;ln -s /etc/passwd", then I could download passwd or whatever the actual password file is at my leasure.  We tested this, and we can actually download passwd through a symbolic link like that

Sounds like a really bad FTP server.  Don't you even chroot?  Also, if you're using shadow passwords, the risk is significantly reduced.  If you are using chroot (and you really ought to be if you don't completely trust the clients, and maybe even then), you can supply a stripped down passwd file that only enumerates some users (unidentified users will show up by UID only), and even have bogus names (bogus relative to the "real" /etc/passwd).

[iago]

hmm, I would have just executed the command "myfile;ln -s /etc/passwd", then I could download passwd or whatever the actual password file is at my leasure.  We tested this, and we can actually download passwd through a symbolic link like that

Sounds like a really bad FTP server.  Don't you even chroot?  Also, if you're using shadow passwords, the risk is significantly reduced.  If you are using chroot (and you really ought to be if you don't completely trust the clients, and maybe even then), you can supply a stripped down passwd file that only enumerates some users (unidentified users will show up by UID only), and even have bogus names (bogus relative to the "real" /etc/passwd).

For now, anyway, we only have 2 users, both have the root password, so that's not really an issue.  Our password file is shadowed, too, there's no hashes in it.  

I don't really know how chroot works, but I read about it before for running webservers.  

The File Server is just that: a File Server.  It doesn't have any important functions, and it can't give backdoor access to the rest of the network, so chroot'ing it would change nothing if they managed to get access.

And yeah, the filetransfer sucks.  It's because it was written by students.  We've spent all day adding error handling

[Adron]

A symbolic link isn't a file like .lnk in Windows. It's a file system element. It's a secondary entry in the file table that points to an already existing file.

So... No, I guess.

I think you're confusing hard links and symbolic links. Symbolic links are more like .lnk files in Windows. They contain a path.

[Yoni]

Ok, yes, I probably confused them. But still, symbolic links aren't regular files like .lnk in Windows, they're marked by the file system as a link... Right?

[Adron]

Yes, symbolic links are special in the file system. I think they basically store the (relative or absolute) path of the target as the file contents, and have a special attribute indicating that this is a symbolic link.

You can't seem to create symbolic links on a network (samba) mounted ntfs partition.

The big difference between Windows' lnk files and symbolic links in linux is that all the file opening functions support following symbolic links natively. In Windows, you have to either use a special function to follow links, or parse them yourself.

[Kp]

I don't really know how chroot works, but I read about it before for running webservers.  

The File Server is just that: a File Server.  It doesn't have any important functions, and it can't give backdoor access to the rest of the network, so chroot'ing it would change nothing if they managed to get access.

And yeah, the filetransfer sucks.  It's because it was written by students.  We've spent all day adding error handling

I can give you a basic overview of chroot; for each process, there is a concept of the root directory as part of the process information.  Normally, that root directory really is the root directory -- i.e., it refers to / as the home.  However, if an application uses chroot, it can change that base to refer to something else, such as /home/ftp.  After the chroot call, the server could access /.cshrc to get the file that is really in /home/ftp/.cshrc.  The attractive thing about this is that, if the chroot'd application then attempted to access ../../etc/passwd, it would successfully access in the following way:

/.. => /
/.. => /
/etc/passwd => etc/passwd

That is, each of the .. references would expand into / again, since you can never chdir above the root directory (even if it is a bogus root directory).  Thus, even if an attacker convinced the server to upload files at a location of his choosing, it couldn't write or even read anything outside /home/ftp, regardless of permissions.  This is the attraction of chroot -- a well designed chroot "sandbox" is almost entirely useless to an attacker even if he attains total control over the ftp server, since it locks itself into the sandbox before it even answers his connection.  Afaik, once you have called chroot, there is no going back.  Your descendents will inherit your root directory (which they could chroot to be even deeper, if they desired), and chroot to /../ will expand out to chroot /, which doesn't take you anywhere.

[Adron]

I'm pretty sure that as root you can chroot out. Also, handles open to things outside your current chroot jail are still accessible?