This shows you the differences between two versions of the page.

Link to this comparison view

internal:accessing-users-files-as-root-safely [2011/03/18 17:18] (current)
solar created
Line 1: Line 1:
 +====== How to access users' files as root safely ======
 +The following is an excerpt taken from [[http://​www.openwall.com/​lists/​oss-security/​2011/​03/​04/​24]]:​
 +Speaking of issues where a more or differently privileged process
 +accesses files in a directory writable by another process, these are
 +surprisingly difficult to "​fully"​ deal with, and the majority of
 +programs are "​affected"​. ​ Of the common Unix commands, only a handful
 +are safe to use in untrusted directories (with possible impact of
 +attacks being a mere DoS against the command itself) - such as "​ln"​.
 +Yes, I actually use "​ln"​ like this:
 +# su - user1
 +$ cp some/​dir/​file . # hopefully the ~/file name was not taken
 +$ exit
 +# ln ~user1/file .
 +# ls -ld file # sanity check that we were not raced
 +# chown user2: file
 +# ln file ~user2/
 +# rm file
 +# su - user2
 +$ mv file target/dir/
 +$ exit
 +# su - user1
 +$ rm file
 +when I need to copy a file from one untrusted user to another. ​ Yes,
 +this is complicated and it has limitations (same fs).  Maybe we need a
 +special tool for this task (I had some ideas on this - "​give"​ and "​take"​
 +commands). ​ But that's the current situation.
 +Almost all other commands and programs are unsafe on untrusted
 +directories. ​ In my opinion, that's the only correct assumption for a
 +sysadmin to make, and any other assumption is naive. ​ Unfortunately,​
 +most sysadmins don't fully realize this (in my experience),​ but that
 +does not make those programs any safer, nor does it prompt us to assign
 +CVE ids against almost all Unix programs.
 +Unfortunately,​ ''​su''​ is not perfect. ​ An excerpt from [[http://​www.openwall.com/​lists/​oss-security/​2011/​03/​05/​6]]:​
 +The admin could "​su"​ to the service pseudo-user,​ but that allows the
 +compromised service to attack the admin'​s terminal, accessing the fd via
 +/proc or ptrace of a process such as "​less"​ running under the "​su"​
 +session. ​ Only "​su"​ itself is immune from such attacks (since it has its
 +"​dumpable"​ flag cleared); its child processes are not.  The attacker
 +would be able to print control characters directly to the terminal fd,
 +and to issue ioctl'​s on it, changing the terminal mode.  This might have
 +a security impact worse than DoS.
internal/accessing-users-files-as-root-safely.txt ยท Last modified: 2011/03/18 17:18 by solar
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate to DokuWiki Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki Powered by OpenVZ Powered by Openwall GNU/*/Linux