1 |
On Fri, Mar 2, 2018 at 6:42 AM, Heiko Baums <lists@××××××××××××.de> wrote: |
2 |
> Am Thu, 1 Mar 2018 21:45:46 -0500 |
3 |
> schrieb Rich Freeman <rich0@g.o>: |
4 |
> |
5 |
>> If they did move netfilter to userspace, then it would |
6 |
> |
7 |
> most likely be more insecure because a userspace process can be easier |
8 |
> bypassed, killed, hacked or whatever. That's a lot harder with the |
9 |
> kernel if not impossible. |
10 |
|
11 |
It is actually the opposite. The whole appeal of microkernels is that |
12 |
they can potentially be a lot more robust. |
13 |
|
14 |
Consider something like netfilter. The code in netfilter is exposed |
15 |
to unfiltered network traffic. If it contains a bug then a remote |
16 |
attacker might be able to run arbitrary code in kernel space, where |
17 |
there is no separation of privs. That code can access everything on |
18 |
the machine. |
19 |
|
20 |
On the other hand, if netfilter were implemented in userspace such as |
21 |
via a microkernel, then if it contained a bug the remote attacker |
22 |
would be able to MITM all network traffic on the machine, but that |
23 |
would be the extent of the access they have. Granted, it still |
24 |
wouldn't be ideal because it probably would include local traffic that |
25 |
might not be encrypted (think localhost traffic and socket |
26 |
connections/etc). Then again, depending on the implementation |
27 |
different interfaces or connections might run in separate processes in |
28 |
which case a remote attacker might only be able to MITM his own |
29 |
connection. The process running the netfilter code doesn't need |
30 |
anything other than a pipe back to the kernel to receive packets and |
31 |
send packets back, so it can run with minimal privs otherwise. |
32 |
|
33 |
The fact that there are convenient command-line utilities to kill a |
34 |
process does not mean that they are less secure/robust than kernel |
35 |
modules. Generally you have to be running as root to kill a process |
36 |
with a different UID, and bugs that allow this to be exploited are |
37 |
treated as severe by the kernel team (and in a microkernel they would |
38 |
be very severe since it is one of the few things the kernel actually |
39 |
does, and since the kernel doesn't do much the things it does do get |
40 |
more attention). If you are root, then you can also mess with the |
41 |
kernel if you want to. You might not know how to do it, but messing |
42 |
with kernel processes certainly isn't impossible, as is crashing your |
43 |
machine. |
44 |
|
45 |
This is why the Linux maintainers actually prefer to move stuff to |
46 |
userspace when it makes sense. They're not looking to transition to a |
47 |
microkernel, but a lot of the boot-time mounting logic and devfs/etc |
48 |
logic has gone away in favor of initramfs and udev. This allows for |
49 |
alternate implementations, and it helps cut down on the complexity of |
50 |
kernel code. |
51 |
|
52 |
And of course if this is done it is done correctly, and not as some |
53 |
kind of userspace hack on top of an OS to add features that it lacks. |
54 |
|
55 |
-- |
56 |
Rich |