Results 1 to 4 of 4
I'm a bit new to securing LINUX, and I've been reading as much as I can find on unix security and decided to have a go on my own box.
...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 03-10-2007 #1Just Joined!
- Join Date
- Mar 2007
- Posts
- 2
Owned by root, but world rwx'able. Dangerous?
I'm a bit new to securing LINUX, and I've been reading as much as I can find on unix security and decided to have a go on my own box.
In the process, I found a directory and all the files in it to be owned by root, in the group root, but everything had everyone/world rwx permissions. None of the files were SUID or SGID root. Apart from the obvious danger of any user being able to manipulate files, is there anyway that this could be leveraged for privlege escalation? The directory is not an important sytem directory, nor contained in the PATH variable for root or any other user. There is also very little danger of someone else being tricked into executing a file in the directory. While I realize I should probably just strip off the world privleges to a degree... I'm mostly interested in HOW someone would go about leveraging this if it is indeed possible.
Running fedora core w/SElinux...
Also... On a different system (BSD), I noticed that a symbolic link pointing /bin/sh to /bin/bash was everyone rwx'able. the actual /bin/bash file did not have the same problem. Is there anyway someone could use this to like, redirect the link to some other place. (Such as a malicious bash script in their home directory or something) Or is it possible for them to delete the link? This isn't my box so I wasn't willing to try it and find out. ...I could recreate the situation on my box, but I don't know how people leverage poorly configured file permissions. (Though I have noticed on other systems, the links are usually not world writable)
Hope someone can help
- 03-13-2007 #2Yes, if root was to execute the file.Apart from the obvious danger of any user being able to manipulate files, is there anyway that this could be leveraged for privlege escalation?
World-writable files are bad news in general. Without quotas or other safeguards in place they can written to arbitrarily to create a DoS situation on that filesystem.
Which BSD was that? bash is not even installed in the FreeBSD base system, and the port installs it to /usr/local.On a different system (BSD), I noticed that a symbolic link pointing /bin/sh to /bin/bash was everyone rwx'able.
- 03-13-2007 #3Just Joined!
- Join Date
- Mar 2007
- Posts
- 2
Yeah... *slaps forhead* for some reason I was thinking it was BSD. But it turns out its debian. Looks like its running a custom 2.4.32 kernel, with a 2.6 as a backup. (That's just my uneducated conclusion from having a peak at readable config stuff and directories) So I could be, and probably am wrong.
But so about the link bit. ...There are also quite a few other symbolic links with world rwx privlages. Can world writable links be modified? Or flat out deleted? Or abused in other ways? Or on a general principle: Is there any reason why a link ought to be world rwx'able? But even if no, are there any specific dangers to them?
- 03-13-2007 #4I don't have a definitive answer, but I just ran a couple quick tests to see how things would behave, w/ regard to symlinks.Is there any reason why a link ought to be world rwx'able? But even if no, are there any specific dangers to them?
I logged in as a user with a restrictive umask and created a symlink. It automatically had 777 permissions, so maybe that is standard. Moreover, the manpages for chmod(1) state that:
This seems to support that all symlinks do and should have 777 permissions.chmod never changes the permissions of symbolic links; the chmod system call cannot change their permissions. This is not a problem since the permissions of symbolic links are never used. However, for each sym-bolic link listed on the command line, chmod changes the permissions of the pointed-to file.
Next, I tried deleting the /bin/sh symlink as a regular user. Permission denied. Probably because /bin directory permissions prevent it.
Code:[helen@troy ~]$ ls -ld /bin drwxr-xr-x 2 root root 4096 Mar 13 05:03 /bin


Reply With Quote
