5

If I created a folder /tmp/me with permissions 700, and started a process under me that starts a listen socket under /tmp/me/socket.

  • I currently assume that a connection to that socket originated from a process that is running on the very same server (malicious or otherwise), and was not a connection from another server (unless through one of the processes).
  • Can I also assume that the only users who can access that socket are me, and root?

I am asking about Solaris in particular.

Note: I'm aware that setting permissions on the socket file itself is not effective on various Operating Systems. That is why I chose to contain the socket file within a directory me.

700 Software
  • 13,807
  • 3
  • 52
  • 82

2 Answers2

7

I currently assume that a connection to that socket originated from a process that is running on the very same server

Correct. Filesystem sockets must be read by a process that has access to the file.

Can I also assume that the only users who can access that socket are me, and root?

Yes. Since me is the only user with permissions, they are the only ones who may enter that folder and view the socket. root, of course, is root.

Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171
  • There used to exist some Unix variants that ignored file permissions for local sockets. I can't remember which, though. – user1686 Sep 29 '13 at 05:22
  • Within man unix under debian linux you can read " This behavior differs from many BSD-derived systems which ignore permissions for UNIX domain sockets. Portable programs should not rely on this feature for security." But context of this sentence starts wih "In the Linux implementation, sockets which are visible in the filesystem honor the permissions of the directory they are in." So i can't tell if it applies to unxid domain permissions or to directory owning unix domain entry... – philippe lhardy Mar 12 '14 at 19:50
  • well discussion is there : http://unix.stackexchange.com/questions/83032/which-systems-do-not-honor-socket-read-write-permissions – philippe lhardy Mar 12 '14 at 19:55
2

Yes, you can do this, but it may not be the best design since, on some systems, such as HP-UX, the permissions of the socket file are ignored. While the permissions of the parent directory will still be applied, these may be harder to administer than the permissions on the socket file itself.

Unix domain sockets provide another means for verifying the identity of the remote process: SCM_CREDENTIALS, as documented in unix(7). This is foolproof since only root* is allowed to pass forged credentials. Unfortunately, this does not appear to be any more standard than putting filesystem permissions on the socket file:

SCM_CREDENTIALS and the abstract namespace were introduced with Linux 2.2 and should not be used in portable programs. (Some BSD-derived systems also support credential passing, but the implementation details differ.)

* On Linux, technically, the foreign process need only have the CAP_SETUID capability, but this is a root-equivalent capability under any vaguely reasonable system configuration anyway (in other words, if an attacker has that capability, they effectively have root). The foreign process is also allowed to give you any of its real, effective, and saved user/group IDs, which is not a vulnerability either, for similar reasons (TL;DR: Any process is allowed to swap these credentials around whenever it likes).

Community
  • 1
Kevin
  • 906
  • 6
  • 12
  • 1
    *"Yes, you can do this, but it may not be the best design since, on some systems, such as HP-UX, the permissions of the socket file are ignored. "*. As per my understanding, the OP precisely set the right `700` on the parent folder (`/tmp/me`) and did not mentioned setting any right directly on the socket (`/tmp/me/socket`). – WhiteWinterWolf Jun 20 '16 at 08:54
  • Thanks @WhiteWinterWolf. I've edited my question to clarify this for future visitors. – 700 Software Jun 20 '16 at 12:49