lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <7026ab20-588d-26b6-bc68-316cb7c785a4@huawei.com> Date: Sun, 11 Sep 2022 00:14:58 +0300 From: "Konstantin Meskhidze (A)" <konstantin.meskhidze@...wei.com> To: Mickaël Salaün <mic@...ikod.net> CC: <willemdebruijn.kernel@...il.com>, <gnoack3000@...il.com>, <linux-security-module@...r.kernel.org>, <netdev@...r.kernel.org>, <netfilter-devel@...r.kernel.org>, <anton.sirazetdinov@...wei.com> Subject: Re: [PATCH v7 18/18] landlock: Document Landlock's network support 9/6/2022 11:12 AM, Mickaël Salaün пишет: > > On 29/08/2022 19:04, Konstantin Meskhidze wrote: >> Describe network access rules for TCP sockets. >> Add network access example in the tutorial. >> Point out AF_UNSPEC socket family behaviour. >> Point out UDP sockets issues. >> Add kernel configuration support for network. >> >> Signed-off-by: Konstantin Meskhidze <konstantin.meskhidze@...wei.com> >> --- >> >> Changes since v6: >> * Adds network support documentaion. >> >> --- >> Documentation/userspace-api/landlock.rst | 84 +++++++++++++++++++----- >> 1 file changed, 66 insertions(+), 18 deletions(-) >> >> diff --git a/Documentation/userspace-api/landlock.rst b/Documentation/userspace-api/landlock.rst >> index 2509c2fbf98f..4b099d1b5a9d 100644 >> --- a/Documentation/userspace-api/landlock.rst >> +++ b/Documentation/userspace-api/landlock.rst >> @@ -11,10 +11,10 @@ Landlock: unprivileged access control >> :Date: August 2022 >> >> The goal of Landlock is to enable to restrict ambient rights (e.g. global >> -filesystem access) for a set of processes. Because Landlock is a stackable >> -LSM, it makes possible to create safe security sandboxes as new security layers >> -in addition to the existing system-wide access-controls. This kind of sandbox >> -is expected to help mitigate the security impact of bugs or >> +filesystem or network access) for a set of processes. Because Landlock >> +is a stackable LSM, it makes possible to create safe security sandboxes as new >> +security layers in addition to the existing system-wide access-controls. This >> +kind of sandbox is expected to help mitigate the security impact of bugs or >> unexpected/malicious behaviors in user space applications. Landlock empowers >> any process, including unprivileged ones, to securely restrict themselves. >> >> @@ -30,18 +30,20 @@ Landlock rules >> >> A Landlock rule describes an action on an object. An object is currently a >> file hierarchy, and the related filesystem actions are defined with `access >> -rights`_. A set of rules is aggregated in a ruleset, which can then restrict >> -the thread enforcing it, and its future children. >> +rights`_. Since ABI version 3 a port "object" appears with related network actions > > Version 3 is wrong here, it should be version 4. Please fix everywhere > else too. Ok. > > Why do you quote "object"? Because for filesystem we work with inodes which are kernel objects, but network port is not, so I used quotes here. > > Let's use object (e.g. for filesystem/inode) or data (e.g. for TCP port). > Ok. I will fixt it. > >> +for TCP4/TCP6 sockets families. A set of rules is aggregated in a ruleset, which > > TCP4/TCP6 would not make sense for users, please be explicit, and in > this case "TCP" is enough. Got it. > > BTW, IP4 and IP6 don't exist, they should be replaced *everywhere* with > IPv4 and IPv6. > Ok. Thanks. > >> +can then restrict the thread enforcing it, and its future children. >> >> Defining and enforcing a security policy >> ---------------------------------------- >> >> We first need to define the ruleset that will contain our rules. For this >> example, the ruleset will contain rules that only allow read actions, but write >> -actions will be denied. The ruleset then needs to handle both of these kind of >> +actions will be denied. The ruleset then needs to handle both of these kind of >> actions. This is required for backward and forward compatibility (i.e. the >> kernel and user space may not know each other's supported restrictions), hence >> -the need to be explicit about the denied-by-default access rights. >> +the need to be explicit about the denied-by-default access rights. Also ruleset >> +will have network rules for specific ports, so it should handle network actions. >> >> .. code-block:: c >> >> @@ -62,6 +64,9 @@ the need to be explicit about the denied-by-default access rights. >> LANDLOCK_ACCESS_FS_MAKE_SYM | >> LANDLOCK_ACCESS_FS_REFER | >> LANDLOCK_ACCESS_FS_TRUNCATE, >> + .handled_access_net = >> + LANDLOCK_ACCESS_NET_BIND_TCP | >> + LANDLOCK_ACCESS_NET_CONNECT_TCP, >> }; >> >> Because we may not know on which kernel version an application will be >> @@ -70,9 +75,9 @@ should try to protect users as much as possible whatever the kernel they are >> using. To avoid binary enforcement (i.e. either all security features or >> none), we can leverage a dedicated Landlock command to get the current version >> of the Landlock ABI and adapt the handled accesses. Let's check if we should >> -remove the `LANDLOCK_ACCESS_FS_REFER` or `LANDLOCK_ACCESS_FS_TRUNCATE` access >> -rights, which are only supported starting with the second and third version of >> -the ABI. >> +remove the `LANDLOCK_ACCESS_FS_REFER` or `LANDLOCK_ACCESS_FS_TRUNCATE` or >> +network access rights, which are only supported starting with the second and >> +third version of the ABI. >> >> .. code-block:: c >> >> @@ -87,9 +92,13 @@ the ABI. >> /* Removes LANDLOCK_ACCESS_FS_REFER for ABI < 2 */ >> ruleset_attr.handled_access_fs &= ~LANDLOCK_ACCESS_FS_REFER; >> __attribute__((fallthrough)); >> + /* Removes network support for ABI < 2 */ >> + ruleset_attr.handled_access_net = 0; > > This is not correct. I will refactor the demo code and then update it here. > > >> case 2: >> /* Removes LANDLOCK_ACCESS_FS_TRUNCATE for ABI < 3 */ >> ruleset_attr.handled_access_fs &= ~LANDLOCK_ACCESS_FS_TRUNCATE; >> + /* Removes network support for ABI < 3 */ >> + ruleset_attr.handled_access_net = 0; > > This part should be for the fourth version. Ok. Will be fixed. > > >> } >> >> This enables to create an inclusive ruleset that will contain our rules. >> @@ -129,6 +138,24 @@ descriptor. >> } >> err = landlock_add_rule(ruleset_fd, LANDLOCK_RULE_PATH_BENEATH, >> &path_beneath, 0); >> + >> +It may also be required to create rules following the same logic as explained >> +for the ruleset creation, by filtering access rights according to the Landlock >> +ABI version. In this example, this is not required because all of the requested >> +`allowed_access` rights are already available in ABI 1. > > This paragraph should not be moved. Furthermore, this hunk remove error > handling… Ok. Got it. > > >> + >> +For network part we can add number of rules containing a port number and actions >> +that a process is allowed to do for certian ports. >> + >> +.. code-block:: c >> + >> + struct landlock_net_service_attr net_service = { >> + .allowed_access = LANDLOCK_ACCESS_NET_BIND_TCP, >> + .port = 8080, >> + }; >> + >> + err = landlock_add_rule(ruleset_fd, LANDLOCK_RULE_NET_SERVICE, >> + &net_service, 0); >> close(path_beneath.parent_fd); >> if (err) { >> perror("Failed to update ruleset"); >> @@ -136,13 +163,9 @@ descriptor. >> return 1; >> } >> >> -It may also be required to create rules following the same logic as explained >> -for the ruleset creation, by filtering access rights according to the Landlock >> -ABI version. In this example, this is not required because all of the requested >> -`allowed_access` rights are already available in ABI 1. >> - > > Please add similar standalone code + explanation sections for network here. > Is added section for network not enough? > >> We now have a ruleset with one rule allowing read access to ``/usr`` while >> -denying all other handled accesses for the filesystem. The next step is to >> +denying all other handled accesses for the filesystem. The ruleset also contains >> +a rule allowing to bind current proccess to the port 8080. The next step is to >> restrict the current thread from gaining more privileges (e.g. thanks to a SUID >> binary). >> >> @@ -280,6 +303,13 @@ It should also be noted that truncating files does not require the >> system call, this can also be done through :manpage:`open(2)` with the flags >> `O_RDONLY | O_TRUNC`. >> >> +AF_UNSPEC socket family >> +----------------------- >> + >> +Sockets of AF_UNSPEC family types are treated as AF_INET(TCP4) socket for bind() >> +hook. But connect() hook is not allowed by Landlock for AF_UNSPEC sockets. This > > Users don't know what is a hook. Such kernel internals are not required > to explain things. Ok. I will change it to action. > > >> +logic prevents from disconnecting already connected sockets. >> + >> Compatibility >> ============= >> >> @@ -339,7 +369,7 @@ Access rights >> ------------- >> >> .. kernel-doc:: include/uapi/linux/landlock.h >> - :identifiers: fs_access >> + :identifiers: fs_access net_access >> >> Creating a new ruleset >> ---------------------- >> @@ -358,6 +388,7 @@ Extending a ruleset >> >> .. kernel-doc:: include/uapi/linux/landlock.h >> :identifiers: landlock_rule_type landlock_path_beneath_attr >> + landlock_net_service_attr >> >> Enforcing a ruleset >> ------------------- >> @@ -406,6 +437,13 @@ Memory usage >> Kernel memory allocated to create rulesets is accounted and can be restricted >> by the Documentation/admin-guide/cgroup-v1/memory.rst. >> >> +UDP sockets restricting >> +----------------------- > > I don't think this section is needed. There is a lot of missing access > types for now and it is not useful to list them all. The "Current > limitations" section lists limitations about the currently implemented > access types (e.g. filesystem, TCP). Ok. I will delete it in future patch. > > >> + >> +Current network part supports to restrict just TCP sockets type. UPD sockets sandboxing > > typo: UDP Got it. Will be fixed. > >> +adds additional issues due to unconnected nature of the protocol. UDP sockets support >> +might come in future Landlock versions. >> + >> Previous limitations >> ==================== >> >> @@ -435,6 +473,13 @@ always allowed when using a kernel that only supports the first or second ABI. >> Starting with the Landlock ABI version 3, it is now possible to securely control >> truncation thanks to the new `LANDLOCK_ACCESS_FS_TRUNCATE` access right. >> >> +Network support (ABI < 3) > > ABI < 4 Ok. > >> +------------------------- >> + >> +Starting with the Landlock ABI version 3, it is now possible to restrict TCP >> +sockets bind() and connect() syscalls for specific ports allowing processes >> +to establish secure connections. > > Try to avoid talking about syscall directly but highlight actions > instead. Using Landlock doesn't create "secure connections", > unfortunately. ;) If I change it to restricted connections, that would be better? > > >> + >> .. _kernel_support: >> >> Kernel support >> @@ -453,6 +498,9 @@ still enable it by adding ``lsm=landlock,[...]`` to >> Documentation/admin-guide/kernel-parameters.rst thanks to the bootloader >> configuration. >> >> +To support Landlock's network part, the kernel must be configured with `CONFIG_NET=y` >> +and `CONFIG_INET=y` options. > > Might be better: > To be able to explicitly allow TCP operations (e.g., adding a network > rule with `LANDLOCK_ACCESS_NET_TCP_BIND`), the kernel must support TCP > (`CONFIG_INET=y`). Otherwise, sys_landlock_add_rule() returns an > `EAFNOSUPPORT` error, which can safely be ignored because this kind of > TCP operation is already not possible. > > >> For TCP6 family sockets `CONFIG_IPV6=y` must be switched on. > > This is not required because if IPv6 is not supported there is nothing > to do for IPv6 sockets. Ok. I will delete it. > > >> + >> Questions and answers >> ===================== >> >> -- >> 2.25.1 >> > .
Powered by blists - more mailing lists