[RFC,0/1] Landlock network PoC

From: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>

Hi, all!
Here is another PoC patch for Landlock network confinement.
Now 2 hooks are supported for TCP sockets:
	- hook_socket_bind()
	- hook_socket_connect()

After architectuire has been more clear, there will be a patch with
selftests.

Please welcome with any comments and suggestions.

Implementation related issues
=============================

1. It was suggested by Mickaёl using new network rules
attributes, like:

struct landlock_net_service_attr {
      __u64 allowed_access; // LANDLOCK_NET_*_TCP
      __u16 port;
} __attribute__((packed));

I found that, if we want to support inserting port attributes,
it's needed to add port member into struct landlock_rule:

struct landlock_rule {
	...
	struct landlock_object *object;
	/**
	 * @num_layers: Number of entries in @layers.
	 */
	u32 num_layers;

	u16 port;
	...
};

In this case 2 functions landlock_insert_rule() and insert_rule()
must be refactored;

But, if struct landlock_layer be modified -

struct landlock_layer {
	/**
	 * @level: Position of this layer in the layer stack.
	 */
	u16 level;
	/**
	 * @access: Bitfield of allowed actions on the kernel object.  They are
	 * relative to the object type (e.g. %LANDLOCK_ACTION_FS_READ).
	 */
	u16 access;

	u16 port;
};
so, just one landlock_insert_rule() must be slightly refactored.
Also many new attributes could be easily supported in future versions.

2. access_masks[] member of struct landlock_ruleset was modified
to support multiple rule type masks.
I suggest using 2D array semantic for convenient usage:
	access_masks[rule_type][layer_level]

But its also possible to use 1D array with modulo arithmetic:
	access_masks[rule_type % layer_level]

3. Kernel objects.
As was disscussed earlier, base Landlock version supports some file access
rules, and inodes objects (files' and directories' inodes) are used to tie
filesystem landlock rules.
For socket operations it makes sense tagging underlying socket inode by
landlock rules and it's perfectly fits to subject-object concept where
proccess is a subject and object is one of kernel objects: inodes, sockets,
ect. But here is one issue that should be also discussed and solved.
Now there is an undergoing work for Landlock support in RUNC and other
container environments:
	https://github.com/opencontainers/runtime-spec/issues/1110
	https://github.com/opencontainers/runc/issues/2859

When RUNC wants to launch a container it first reads a spec.json file
with container specification. Here is an example landlock rules
specification in spec.json:

	"landlock": {
		"rules": [
            	{
			"type": "path_beneath",
			"restrictPaths": {
				"allowedAccess": [
					"LANDLOCK_ACCESS_FS_EXECUTE",
					"LANDLOCK_ACCESS_FS_READ_FILE",
					"LANDLOCK_ACCESS_FS_READ_DIR"
				],
				"paths": [
					"/usr",
					"/bin"
				]
			}
            	},
		{
			"type": "net_service",
			"tcp_net_service":
				"allowedAccess": [
					"LANDLOCK_ACCESS_NET_CONNECT_TCP",
					"LANDLOCK_ACCESS_NET_BIND_TCP",
				],
				"port": [
					"3920"
				],
			}
            	},
	]

For fs part RUNC can easily create rules and tie them to underlying
inodes of filesystem. Then, when it starts a container all fs rules will
be inherited by the container proccess.
But for network rules it's impossible, because there no any socket object
created during RUNC phase. All socket objects are created after an
application has started in the container.
Possible solution:
 - All network rules from spec.json are tied to task_struct object of the
 container process. In this case, RUNC creates network rules, attach them
 to itself and, then rules are inherited by the launched container
 proccess. These rules are global for all sockets in a container and,
 then user could add additional restrictions to any socket connection,
 imposing some kind of granularity.

Konstantin Meskhidze (1):
  landlock: TCP network hooks implementation

 include/uapi/linux/landlock.h |  52 +++++++++
 security/landlock/Makefile    |   2 +-
 security/landlock/fs.c        |   8 +-
 security/landlock/limits.h    |   5 +
 security/landlock/net.c       | 213 ++++++++++++++++++++++++++++++++++
 security/landlock/net.h       |  40 +++++++
 security/landlock/ruleset.c   |  70 +++++++++--
 security/landlock/ruleset.h   |  19 +--
 security/landlock/setup.c     |   3 +
 security/landlock/syscalls.c  | 141 +++++++++++++++-------
 10 files changed, 487 insertions(+), 66 deletions(-)
 create mode 100644 security/landlock/net.c
 create mode 100644 security/landlock/net.h

--
2.25.1

From fee4f0dbec1e4a8fa8d34cec57a8cdbf351e9c12 Mon Sep 17 00:00:00 2001
From: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
Date: Tue, 28 Dec 2021 14:47:39 +0800
Subject: [RFC PATCH 1/1] landlock: TCP network hooks implementation

Support of socket_bind() and socket_connect() hooks.
Current prototype can restrict binding and connecting of TCP
types of sockets. Its just basic idea how Landlock could support
network confinement.

Signed-off-by: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
---
 include/uapi/linux/landlock.h |  52 +++++++++
 security/landlock/Makefile    |   2 +-
 security/landlock/fs.c        |   8 +-
 security/landlock/limits.h    |   5 +
 security/landlock/net.c       | 213 ++++++++++++++++++++++++++++++++++
 security/landlock/net.h       |  40 +++++++
 security/landlock/ruleset.c   |  70 +++++++++--
 security/landlock/ruleset.h   |  19 +--
 security/landlock/setup.c     |   3 +
 security/landlock/syscalls.c  | 141 +++++++++++++++-------
 10 files changed, 487 insertions(+), 66 deletions(-)
 create mode 100644 security/landlock/net.c
 create mode 100644 security/landlock/net.h

--
2.25.1

[RFC,0/1] Landlock network PoC

Commit Message

Comments

Patch