AFUNIXDatagramSocket bind vs C bind and SELinux rules.

[modelmanjohn]

hi, hoping someone can answer a question involving jav process calling AFUNIXDatagramSocket bind() vs a linux C process calling bind(), and I'm seeing something weird with relation to SELinux.
Both these processes bind to a socket/file in the same directory, but they are a different socket/files. They are opened for reading/listening. The SELinux rules are set that these process can only read from those files.
What I am seeing is that when the Java processes does AFUNIXDatagramSocket bind() - selinux catches it trying to write to the file/socket.
the C process does not do this when it calls bind().
I understand that the processes must write to the directory (to create the file/socket), but its not that. Both processes have SELinux permission to do that. Its the file itself (identified by its socket label). the Java process is clearly doing a write to the socket during the bind. I just don't understand why. We'd like to have the SELinux rules deny writes to the socket (ie, we want to enforce read-only).

[kohlschuetter]

This is most likely coming from the chmod 0666 in bind.c, setting read/write (but not execute) permissions for all.

According to unix(7), default permissions on socket files vary around operating systems, and this call ensures unified behavior across systems (using directory-level access control is the preferred way of restricting access to a socket — also consider using peer credentials, etc.)

Try commenting-out that call in bind.c and recompile locally to see if it makes a difference.

For what it's worth, I think binding is an operation that is very much related to writing as in "providing a server" opposite to reading as in "connecting to a server as a client". You would probably want to restrict that ability to processes that are able to write to the socket they bind to. You may also bind sockets in a separate process with broad permissions, and pass these bound sockets as file descriptors to another process with reduced permissions.

Moreover, but I haven't verified this now, unix(7) says "On Linux, ... sending a datagram to a datagram socket ... requires write permission on that socket.", so I'm not sure how far you can access a unix domain socket without write access... SELinux may effectively give you somewhat fine-grained controls to restrict access to a resource but you may be trying to guard something that is explicitly required by spec...

That may also bite you in case you use junixsocket's support for re-binding a pathname to a unix domain socket (via SO_REUSEADDR), so a crashed server can be replaced by another one. Also see bind.c for what we do there.

[modelmanjohn]

Thanks for responding! I did try to verify if the bind was doing the write by doing a manual clear of the audit log and then immediately do a chmod 777 on the socket file as a test - the write denial did not occur. I think that is more of a "set attribute" (setxattr), yes? (I do agree that that 666 is a good setting tho). So I don't think thats causing the write. Maybe its in another path?
Maybe a clearer example will help.
My socket is called /pathto/cproc2jproc.sock - the c process is the writer/sender, the java process is the reader/receiver. The java process is also the one that creates the socket (I believe thru the bind?), so essentially does the following (file=/pathto/cproc2jproc.sock and is File class)

if(!file.exists()){
    file.createNewFile();
}
server = AFUNIXDatagramSocket.newInstance();
server.bind(AFUNIXSocketAddress.of(file));

and then proceeds to continually loop with server.receive(buffer). It looks like the selinux write denial occurs in the bind.
Constrasting this: we also have a socket called /pathtoo/jproc2cproc.sock - ths jproc is the writer/sender, the cproc is the reader/receiver. The cproc is also the creator.This is what it looks like:

insock=socket(AF_UNIX,SOCK_DGRAM,0);
struct sockaddr_un sockpath;
sockpath..sun_family = AF_UNIX;
strncpy(sockpath.sun_family.sunpath,socketfilepath,strlen(socketfilepath));
bind(insock,(struct sockaddr *) sockpath, sizeof(struct sockaddr_un));

and this is the selinux rule:
allow cproc_t jproc2cproc_t:sock_file { read create getattr setatr relabelfrom relabelto unlink open };
(the rule for the cproc2jproc.sock file is identical, except its allow jproc_t cpro2jproc_t:sock_file)

so if the C-process bind() call was doing a write - it would be denied. But i don't see that. It only seems to be happening in the java bind

I'm not sure how else it could be done without the bind? Or perhaps I'm not understanding correctly.