CODEWITHSUNDEEP
linuxsecurityunix-socket
Sceptical Jule
Sceptical Jule

Reputation: 917

Securing process communication over Unix domain sockets

UNIX domain sockets (not the stream sockets in the IP domain AF_INET) offer a sort of built-in safety mechanism based on ownership/permissions on the file system, i.e. a UDS client can only connect to a UDS server if it was started with the same user or if it belongs to the same user group as the server.

Would I add an additional security layer by checking if the message from the client has a certain password in the beginning? I thought in this way I could maybe block a client if the corresponding linux user was hacked. Are there any other ways to secure the process communication over UDS?

Upvotes: 2

Views: 2224

Answers (2)

Luchostein
Luchostein

Reputation: 2444

If the account gets hacked or if the machine gets compromised, there's not much to do at de app level.

Nontheless, in a properly working system, you should normally discriminate among different users if that's a requirement of your app. In that case, this is the way:

As of man unix(7):

Pathname socket ownership and permissions

In the Linux implementation, pathname sockets honor the permissions of the directory they are in. Creation of a new socket fails if the process does not have write and search (execute) permission on the directory in which the socket is created.

On Linux, connecting to a stream socket object requires write permission on that socket; sending a datagram to a datagram socket likewise requires write permission on that socket. POSIX does not make any statement about the effect of the permissions on a socket file, and on some systems (e.g., older BSDs), the socket permissions are ignored. Portable programs should not rely on this feature for security.

(...)

Ancillary messages

Ancillary data is sent and received using sendmsg(2) and recvmsg(2).

(...)

SCM_CREDENTIALS

Send or receive UNIX credentials. This can be used for authentication. The credentials are passed as a struct ucred ancillary message. This structure is defined in <sys/socket.h> as follows:

struct ucred {
    pid_t pid;    /* Process ID of the sending process */
    uid_t uid;    /* User ID of the sending process */
    gid_t gid;    /* Group ID of the sending process */
};

But, beware of protability!

VERSIONS

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.)

So, in the end, if you need to discriminate those authorized users of your app among valid users of the system where the app is running, you should implement messages for authorization in your app, returning some big random token/cookie to be included and validated in subsequent calls (as in authorization cookies for web calls). Internally, you'd need some ACL support.

Upvotes: 0

Luis Colorado
Luis Colorado

Reputation: 12668

Ok, that's what the passwd(1) program does indeed! (and it does that since the epoch of unix) It asks for the password, so if the user was effectively hacked the account and does not know the password, he will not be able to change the password and will not be able also to access the service. But probably, if the user has been able to bypass the security by other means than getting the pasword, he has broken the security access to the system, and why not become root then? in that case, he will be able to change the password to access your system and restore the old one after accessing, without even knowing it (he has only to copy the encrypted password in the /etc/shadow file, change the password, access your system, and restore the encrypted password from the copy he made) Only if the original user tries to access to the system while the password is changed, he will detect the intrusion, else at the end everything goes as before the change.

Anyway, hacking a unix system at this level gives you more power than that, and he will be able to attack your system on the rear side, accessing the internal datafiles or databases, better as root than as the original user.

Your idea is a good one, if users don't mind to have to use their passwords each time they use a socket, think on the overhead of this. You'll be asking passwords at least from time to time... and the probability of the user being hacked without knowing the password are quite low. As all security related specs, all depends on the value of the information that is saved behind those sockets.

Upvotes: 2

Related Questions