selinux.md

rfkrocktk

I've been hacking on this for a bit, but I'm trying to write a policy using the reference policy to contain Syncthing. I've done most of the files level permissions, but I'm having trouble with the networking aspects. My code is here: https://github.com/rfkrocktk/syncthing/blob/feature/selinux/etc/selinux/syncthing.te#L80 I'm still getting the following denied:

type=AVC msg=audit(1469458131.894:6800): avc:  denied  { create } for  pid=18349 comm="syncthing" scontext=unconfined_u:unconfined_r:syncthing_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:syncthing_t:s0-s0:c0.c1023 tclass=tcp_socket permissive=0

and I've created the port:

sudo semanage port -l | grep syncthing
syncthing_admin_port_t         tcp      8384
syncthing_discovery_port_t     udp      21027
syncthing_port_t               tcp      22000

what am I missing in my policy?

grift

allow syncthing_t syncthing_port_t:tcp_socket { create };
allow syncthing_t syncthing_discovery_port_t:udp_socket { create };
allow syncthing_t syncthing_admin_port_t:tcp_socket { create };

these dont make sense

basically its how access control on sockets is done thats a bit confusing

e.g.

to allow a process to connect to a tcp port (lets say process type: myprocess_t, port type: myport_t

allow myprocess_t self:tcp_socket create_socket_perms;
allow myprocess_t myport_t:tcp_socket name_connect;

another example

to allow a process to bind udp sockets to a port (pets say process type myprocess_t and port type myport_t:

allow myprocess_t self:udp_socket create_socket_perms;

allow myprocess_t myport_t:udp_socket name_bind;

so theres two different rules for a single action and sometimes even more example

to allow a process to unix stream socket connect to another process via a unix stream socket (processA_t, processB_t, myunixstreamsocket_t):

allow processA_t self:unix_stream_socket create_socket_perms;
allow processA_t myunixstreamsocket_t:sock_file write_sock_file_perms;

its a bit confusing but

allow syncthing_t syncthing_port_t:tcp_socket { create };

doesnt make sense as per above self rules are rules where the source is the same as the target so:

type=AVC msg=audit(1469458131.894:6800): avc:  denied  { create } for  pid=18349 comm="syncthing" scontext=unconfined_u:unconfined_r:syncthing_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:syncthing_t:s0-s0:c0.c1023 tclass=tcp_socket permissive=0

is: allow syncthing_t self:tcp_socket create; its internal

creating a socket before you can use it (whether its connecting/writing binding/listening accepting something like that yes

grift

but the avc denials are pretty clear about that its just a matter of identifying what belongs to what if you see audit2allow print this:

allow myprocess_t myport_t:tcp_socket name_connect;

then you know myprocess_t needs to create a socket:

allow myprocess_t self:tcp_socket create_socket_perms;

if you see audit2allow print this:

allow myprocess_t myport_t:tcp_socket name_bind;

then you know myprocess_t needs to create a stream socket:

allow myprocess_t self:tcp_socket create_stream_socket_perms;

if you see these:

allow processA_t processB_t:unix_stream_socket connectto;
allow processA_t unixstreamsocket_t:sock_file write;

then you know processA_t is stream connecting to processB_t via unixstreamsocket_t sock file and that processA_t will need to create unix_stream_socket:

allow processA_t self:unix_stream_socket create_socket_perms;

and that processB_t will need to create a unix_stream stream socket:

allow processB_t self:unix_stream_socket create_stream_socket_perms;

1. create a socket
2. use the socket to connect
3. create a stream socket
4. use the socket to bind (for example a port)

and then theres small differences with protocols like for example to bind a udp socket to a port you dont need to create a stream socket because thats not how udp works

so for udp its:

allow myprocess_t self:udp_socket create_socket_perms;
allow myprocess_t myport_t:udp_socket name_bind;

instead of:

allow myprocess_t self:udp_socket create_stream_socket_perms;
allow myprocess_t myport_t:udp_socket name_bind;

but with tcp you would need a stream socket to bind to a port

allow myprocess_t self:tcp_socket create_stream_socket_perms;
allow myprocess_t myport_t:tcp_socket name_bind;

and then to make it just a little more complicated

if myprocess_t needs to bind a tcp socket to a port myport_t <1024

allow myprocess_t self:capability net_bind_service;
allow myprocess_t self:tcp_socket create_stream_socket_perms;
allow myprocess_t myport_t:tcp_socket name_bind;

so thats 3 different rules just to allow a process to bind tcp sockets to a port <1024

good thing I'm not binding under 1024 :) grift will the book you recommended discuss these kinds of things, or are they just kind of tribal knowledge? Monday, July 25 10:09:20 AM grift dunno exactly , what i do remember is that i think its one of the most comprehensive books so good chance that it does to some extent , but not sure but i explained the most common sockets now theres one more unix datagram sockets

the accepting party

Monday, July 25 10:13:28 AM grift allow process1_t self:unix_dgram_socket create_socket_perms; allow process1_t mysocket_t:sock_file manage_sock_file_perms;

the connecting party

allow process2_t self:unix_dgram_socket create_socket_perms; allow process2_t process1_t:unix_dgram_socket sendto; allow process2_t mysocket_t:sock_file write; although it might instead be: s/allow allow process1_t self:unix_dgram_socket create_socket_perms;/allow process1_t self:unix_dgram_socket create_stream_socket_perms;/ not sure if thats a stream socket