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 |