Gentoo Archives: gentoo-user

From: Rich Freeman <rich0@g.o>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] [OT] Best *SIMPLE* firewall?
Date: Sat, 03 Mar 2018 00:28:24
Message-Id: CAGfcS_=3abyzAw8P-OsciZhSkiytt4iCGncJS82v-eVY7R-HTA@mail.gmail.com
In Reply to: Re: [gentoo-user] [OT] Best *SIMPLE* firewall? by Grant Taylor
1 On Fri, Mar 2, 2018 at 6:34 PM, Grant Taylor
2 <gtaylor@×××××××××××××××××××××.net> wrote:
3 > On 03/02/2018 05:08 AM, Rich Freeman wrote:
4 >>
5 >> On the other hand, if netfilter were implemented in userspace such as via
6 >> a microkernel, then if it contained a bug the remote attacker would be able
7 >> to MITM all network traffic on the machine, but that would be the extent of
8 >> the access they have.
9 >
10 >
11 > I don't know that it would be the extent of the access the attacker would
12 > have. It might also be a beachhead that could be used as a starting point
13 > for future attacks.
14
15 How? You'd need a local priv escalation vulnerability to do anything
16 further. If the same bug existed in kernel space you'd already have
17 kernel privs and own the machine.
18
19 It would be the exact same code whether it is running in userspace or
20 kernelspace. It isn't like code is magically immune to bugs if it is
21 in the kernel. It would probably be maintained by the exact same
22 people either way.
23
24 >
25 >> The process running the netfilter code doesn't need anything other than a
26 >> pipe back to the kernel to receive packets and send packets back, so it can
27 >> run with minimal privs otherwise.
28 >
29 >
30 > I think that more than a simple pipe (as in unix socket) is needed.
31 > Currently, any program that uses IP is expecting a socket to behave like it
32 > currently behaves. I don't think a simple pipe can provide that.
33
34 There would be no change to regular software. They would use the same
35 system calls to open sockets. They would send their packets to the
36 kernel. The kernel would send them to the userspace netfilter
37 process. The userspace netfilter process would send them back to the
38 kernel. The kernel would then send them to the physical layer for
39 transport.
40
41 That is how microkernels work. The kernel is still the central point
42 of contact and the system calls basically work the same way as they do
43 today. However, the kernel offloads as much processing to userspace
44 as possible.
45
46 With filesystems it is no different with a microkernel. You use the
47 same system calls to write to a file. The data to be written goes to
48 the kernel. However, instead of the kernel calling the filesystem
49 layer in kernel space it instead sends the data via IPC of some sort
50 to a filesystem driver running in userspace. It then sends the raw
51 block device instructions back to the kernel, which then passes it to
52 the device driver for the disk.
53
54 >> a lot of the boot-time mounting logic and devfs/etc logic has gone away in
55 >> favor of initramfs and udev.
56 >
57 >
58 > Please provide examples of this "…boot-time mounting logic and devfs/etc
59 > logic…" that used to be in kernel.
60 >
61 > I'll argue that devfs is now in kernel when it used to be files on a file
62 > system or dynamically created by a user space process. As far as I know,
63 > mounting (more than root as RO) has always been driven from user space via
64 > init scripts.
65
66 I'm talking about mounting root. Capabilities such as identifying
67 devices by UUID have not been added to the kernel, with this being
68 done in an initramfs instead. The trends has been in that direction
69 with assembling RAID arrays and such as well. They haven't removed
70 much code that is working, but they haven't been enhancing it either.
71 If you use an initramfs the kernel automatically disables most of the
72 RAID handling.
73
74 I believe there was a period of time after devfs came along but before
75 udev came along that the complexity of hotplug/etc seemed to be
76 growing on the kernel side. This was quickly recognized as a losing
77 battle which is why we have udev today (or its alternate
78 implementations - one of the benefits of moving this stuff out of the
79 kernel is that it makes it easier to use alternate implementations).
80
81 Obviously mounting filesystems other than root have never been in the kernel.
82
83 > Sure, there's a LOT of changes going on in that space, particularly around
84 > (anti)systemd.
85
86 Well, unless you're referring to udev (which got absorbed by systemd
87 though it is more-or-less still separate), I don't think there is
88 actually a great deal that systemd does that would otherwise be done
89 in kernel space. Maybe some of the maintenance of CGROUPS, but that
90 was all done in userspace from the start, as this trend is fairly
91 established now and it was never done in kernel space.
92
93 >> And of course if this is done it is done correctly, and not as some kind
94 >> of userspace hack on top of an OS to add features that it lacks.
95 >
96 > ???
97 >
98
99 I said that because I think your view might be a bit tainted by
100 previous experiences in Windows/etc. There is a difference between
101 designing a kernel subsystem to provide a capability but to offload
102 some of the work to userspace, and trying to layer some kind of
103 capability into an OS that otherwise lacks it. All this stuff is
104 designed into linux so that it is robust.
105
106 There are pros and cons to microkernels, and of course linux will
107 probably never turn into a proper microkernel, and I'm not really even
108 saying it should. However, the fact that stuff is done in userspace
109 doesn't mean that it needs to be done to a lower standard, or that it
110 is inherently less secure. In fact, it is generally MORE secure in
111 the sense that problems get contained.
112
113 And Windows has gotten a lot better on these fronts as well. I'm sure
114 anybody who plays games on windows will have noticed that video card
115 drivers can be updated without a reboot, or even logging out. This is
116 because there is actually more isolation for these drivers in Windows,
117 and the OS can completely restart the video driver without really
118 affecting everything else that is running, despite the fact that
119 windows is even more GUI-centric than X11/linux/etc. Windows isn't a
120 microkernel either, but it does have some isolation features that are
121 a bit more robust than on Linux. (It would not surprise me if Linux
122 contained better isolation in other areas - a lot of this comes down
123 to xorg-server being unable to detach itself from a display - if you
124 could have X11 detatch from the display (while still serving clients),
125 have the kernel remove and reload the video module, and then have X11
126 re-attach, that would accomplish something similar to how Windows does
127 this.)
128
129 In any case, this is all academic, as there are no plans to move
130 netfilter to userspace.
131
132 --
133 Rich