Socket FDs sharing control #33
Comments
|
From pidfd_getfd(2):
In my understanding, Landlock already restricts the directions in which ptrace accesses are granted (you can only ptrace processes in the same domain or in nested domains). Compare https://elixir.bootlin.com/linux/latest/source/tools/testing/selftests/landlock/ptrace_test.c If I am reading the man page right, I suspect this might already be covered? |
|
Aside from To obtain an opened file from a higher-privileged process, This is the case both for For It helps me to think of file descriptors as "capabilities" (in the sense of https://en.wikipedia.org/wiki/Capability-based_security, not in the sense of Linux capabilities). When viewing things that way, I believe this lets us create processes with sound security properties? I might well be missing something here or not understanding your goal correctly... |
|
About FD passing (with If we want to be sure that a sandbox doesn't use a specific protocol, then we first need to make sure that this sandbox doesn't have an open channel (e.g. socket, other IPCs) with a more-privileged process willing to help, which would be a kind of sandbox escape. Ultimately, this is not something the kernel/Landlock can really help with because it is a matter of user space semantic and user space policy on the service side. However, if the sandbox is initially secure (e.g. well-controlled socket and other IPCs access), it should be OK. Other security mechanism such as polkit should be used to extend the security policy to non-sandboxed processes if they are exposed inside sandboxes. |
Talking about capabilities, I wanted to highlight the current behavior in TCP port control. Landlock restricts connect and bind actions according to the caller, not the creator of the socket. I think it makes sense because a new connection/binding has a close semantic to opening a file i.e., getting access to new data. However, we need to keep that in mind for ongoing and future access controls, especially dealing with FD, sockets, and other IPCs. There are pros and cons for each "mode", but we could also handle both mode if needed (with explicit Landlock request). |
|
Hello @l0kod, @gnoack ! Sorry for the late reply and thank you for the detailed answer. It turns out that the Does everyone agree that we don't need any changes to the API and a single access right for this rule is OK? |
I agree. I think we can control meaningful
It looks good to me. Control of socket creation will be a great and simple way to improve control over the network. |
|
Thank you! Considering the results of the discussion, I close the issue. |
[ Upstream commit e28acc9 ] Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb #33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <[email protected]> Reviewed-by: David Ahern <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit e28acc9 ] Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb #33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <[email protected]> Reviewed-by: David Ahern <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Motivation of socket access-control feature is to restrict actions of adding sockets in a sandboxed process. This can be useful to limit the range of allowed protocols or even to disable the addition of new sockets in sandboxed process.
Processes can share socket FDs with each other. Linux currently supports the following mechanisms:
SCM_RIGHTSin unix(7)).While inheritance in the first case isn't an issue, since landlock doesn't care about the actions performed before sandboxing, the other 2 cases seem to be an issue. A process can get sockets of undesirable family and type after sandboxing by obtaining corresponding FD from another process.
Landlock should support restriction on sharing socket FDs between processes in order to properly limit desired protocol range.
Related to #6
The text was updated successfully, but these errors were encountered: