You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Virtual sockets do not currently have any support for limiting access I am aware of other than a blanket ban on socket operations. Ideally, there would be a way to have fine-grained limits on allowable end points for both virtual sockets and generic netlink sockets, but allowing general access to these classes without granting permission to sockets in general might be a worthwhile improvement.
The text was updated successfully, but these errors were encountered:
pcmoore
changed the title
Create socket ObjectClasses for vsock and generic netlink sockets
RFE: create object classes for vsock and generic netlink sockets
Apr 5, 2022
We have the vsock_socket and netlink_generic_socket object classes for AF_VSOCK and AF_NETLINK/NETLINK_GENERIC respectively, which provide all of the basic per-socket access controls, e.g. bind, connect, etc. We can add permissions to these two object classes, but we first need a documented reason for adding additional control points.
if vsock_socket has the port number restrictions like INET it is probably fine, I just need to do some test policies and see if I can get the behavior I need. I missed it because it wasn't listed on the documentation page.
For netlink_generic sockets, I would need to ask a co-worker. They would like to limit which netlink_generic endpoints particular processes can access to avoid the case where one compromised daemon could access all available netlink_generic interfaces. It might be possible with the existing control points.
According to https://selinuxproject.org/page/ObjectClassesPerms#common_socket there is currently both common_socket and netlink_socket (#netlink_socket) object classes as well as several specializations of netlink_sockets.
Virtual sockets do not currently have any support for limiting access I am aware of other than a blanket ban on socket operations. Ideally, there would be a way to have fine-grained limits on allowable end points for both virtual sockets and generic netlink sockets, but allowing general access to these classes without granting permission to sockets in general might be a worthwhile improvement.
The text was updated successfully, but these errors were encountered: