On 09/02/2022 04:03, Konstantin Meskhidze wrote:
2/8/2022 3:17 PM, Mickaël Salaün пишет:
On 08/02/2022 04:01, Konstantin Meskhidze wrote:
2/7/2022 3:49 PM, Mickaël Salaün пишет:
[...]
+ /* Create a socket 3 */
+ sockfd_3 = socket(AF_INET, SOCK_STREAM, 0);
+ ASSERT_LE(0, sockfd_3);
+ /* Allow reuse of local addresses */
+ ASSERT_EQ(0, setsockopt(sockfd_3, SOL_SOCKET, SO_REUSEADDR,
&one, sizeof(one)));
+
+ /* Set socket 3 address parameters */
+ addr_3.sin_family = AF_INET;
+ addr_3.sin_port = htons(SOCK_PORT_3);
+ addr_3.sin_addr.s_addr = inet_addr(IP_ADDRESS);
+ memset(&(addr_3.sin_zero), '\0', 8);
+ /* Bind the socket 3 to IP address */
+ ASSERT_EQ(0, bind(sockfd_3, (struct sockaddr *)&addr_3,
sizeof(addr_3)));
Why is it allowed to bind to SOCK_PORT_3 whereas net_service_3
forbids it?
It's allowed cause net_service_3 has empty access field.
/* Empty allowed_access (i.e. deny rules) are ignored in network
* actions for SOCK_PORT_3 socket "object"
*/
ASSERT_EQ(-1, landlock_add_rule(ruleset_fd,
LANDLOCK_RULE_NET_SERVICE,
&net_service_3, 0));
ASSERT_EQ(ENOMSG, errno);
Applying this rule returns ENOMSG errno:
/* Informs about useless rule: empty allowed_access (i.e. deny
rules)
* are ignored in network actions
*/
if (!net_service_attr.allowed_access) {
err = -ENOMSG;
goto out_put_ruleset;
}
This means binding socket 3 is not restricted.
For path_beneath_attr.allowed_access = 0 there is the same logic.
I missed the ENOMSG check; the third rule has nothing to do with it.
However, because the ruleset handles bind and connect actions, they
must be denied by default. There is no rule allowing binding to
SOCK_PORT_3. Why is it allowed?
You can test with another SOCK_PORT_4, not covered by any rule. As
for SOCK_PORT_3, it must be forbidden to bind on it.
Apllying the third rule (net_service_3.access is empty) returns
ENOMSG
error. That means a process hasn't been restricted by the third rule,
cause during search process in network rb_tree the process won't
find
the third rule, so binding to SOCK_PORT_3 is allowed.
Landlock is designed to deny every access rights that are handled (by
a ruleset) by default. All rules added to a ruleset are exceptions to
allow a subset of the handled access rights on a specific object/port.
With the current networking code, a sandboxed process can still bind
or connect to any port except, in this test, partially for two ports.
This approach doesn't help to isolate a process from the network.
I got it. Thanks.
Maybe there is a misunderstanding here. You mean that if there is
just
only one network rule for a particular port has been applied to a
process, other ports' networks actions are automatically restricted
until they will be added into landlock newtwork rb_tree?
Right! That is how it should be.
So it possible to check network rb_tree for emptiness before
every rule search caused by bind/connect hooks.
I'm not sure to understand but the rbtree macros should do the job.
Am I corrent that if there is a proccess with Landlcok restrictions
applied for the filesystem, but landlock networtk rb_tree is empty
that means the proccess is not isolated from the network? I suppose it
would be an additional test case.
If the ruleset/domain doesn't handle network actions, Landlock just
ignores network access request (i.e. allow them). A Landlock domain
denies handled network actions by default, but allows those that are
identified as such in the rbtree. Some network actions can be denied
whatever the network rbtree is empty or not. Please take a look at how
the filesystem actions are allowed.
It is indeed a legitimate test case.
