Making the X-server run without root rights
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 199 | |
| Autor | ||
| Lizenz | CC-Namensnennung 2.0 Belgien: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/32572 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
FOSDEM 2014159 / 199
2
3
10
11
12
13
14
17
18
19
23
24
25
27
29
45
46
47
48
49
50
51
52
55
56
57
58
65
67
68
70
72
74
75
76
77
78
79
81
82
84
86
87
89
90
93
94
100
101
102
103
104
106
107
109
110
111
112
113
114
115
119
122
123
124
126
127
128
129
137
139
141
143
145
147
150
154
155
158
161
163
164
165
166
168
171
174
175
176
179
182
183
185
188
190
191
192
194
195
196
00:00
DifferenteMultiplikationsoperatorServerTreiber <Programm>MereologieCodeEin-AusgabeAggregatzustandStrömungsrichtungMathematikURLVirtuelles TerminalZahlenbereichDefaultProzess <Informatik>HardwareATMTropfenComputersicherheitSchaltnetzWurzel <Mathematik>Minkowski-MetrikSchnelltasteSystemaufrufMAPPlastikkarteCASE <Informatik>Rechter WinkelEreignishorizontDatenverwaltungDigital Rights ManagementSchnittmengeKernel <Informatik>Quick-SortPhysikalisches SystemNormalvektorDatenhaltungAttributierte GrammatikMechanismus-Design-TheorieSoftware Development KitVirtuelle MaschineGebäude <Mathematik>Elektronische PublikationFunktionalOffene MengeRichtungPunktFlächeninhaltSchreib-Lese-KopfTermGamecontrollerCodierung <Programmierung>Orbit <Mathematik>HypermediaMetropolitan area networkMomentenproblemMinimumSchlüsselverwaltungDivisionEndliche ModelltheorieSichtenkonzeptRoutingNichtlinearer OperatorDatensatzSoftwaretestLuenberger-BeobachterGraphikkarteGravitationGrößenordnungMailing-ListeBildschirmfensterGruppenoperationProgramm/QuellcodeJSONXML
08:32
GeradeMAPExplosion <Stochastik>DatenflussDigitalisierungDatenverwaltungGruppenoperationTopologieKonfiguration <Informatik>Physikalisches SystemKernel <Informatik>EinheitswurzelATMQuick-SortGamecontrollerPerspektiveEigentliche AbbildungKategorie <Mathematik>Güte der AnpassungBefehl <Informatik>DimensionsanalyseRechter WinkelDemo <Programm>MathematikAutomatische HandlungsplanungMereologieRechenwerkTouchscreenLuenberger-BeobachterLoopWeb-SeiteZahlenbereichComputerspielTreiber <Programm>MultiplikationsoperatorSoundverarbeitungFunktion <Mathematik>PCMCIAKonditionszahlSchreib-Lese-KopfPatch <Software>ProgrammierungElektronischer DatenaustauschResultanteBenutzerbeteiligungsinc-FunktionCodeHydrostatischer AntriebMaßerweiterungWort <Informatik>ServerDistributionenraumSystemaufrufVerzeichnisdienstTheoremGrenzschichtablösungCoxeter-GruppeStandardabweichungDefaultImplementierungTropfenLoginOrdnung <Mathematik>ValiditätProzess <Informatik>SpeicherabzugWrapper <Programmierung>Digital Rights ManagementVirtuelle MaschinePlastikkarteWurzel <Mathematik>Minkowski-MetrikEin-AusgabeSchaltnetzInformationAuswahlaxiomOffene MengeSchnittmengeJSONXMLUML
17:03
Physikalisches SystemGamecontrollerInhalt <Mathematik>InformationSchlussregelMereologieDatenverwaltungGüte der AnpassungTouchscreenFormale GrammatikEndliche ModelltheorieArithmetisches MittelEinfacher RingGarbentheorieLesen <Datenverarbeitung>Prozess <Informatik>PunktspektrumKonfiguration <Informatik>VektorCASE <Informatik>Web-SeiteSchnelltasteGruppenoperationSchlüsselverwaltungSensitivitätsanalyseIntegralElektronische PublikationNeuroinformatikHilfesystemZellularer AutomatDimensionsanalyseOffene MengeLineare RegressionProgrammierungSichtenkonzeptServerObjekt <Kategorie>PunktGrenzschichtablösungVerschlingungKernel <Informatik>ATMVirtuelle MaschineQuick-SortMonster-GruppeRechter WinkelOrdnung <Mathematik>SpielkonsoleBus <Informatik>LoginGemeinsamer SpeicherMultiplikationBootenResultanteMinkowski-MetrikPasswortBitImplementierungVersionsverwaltungJSONXMLUML
25:35
SchlüsselverwaltungEndliche ModelltheoriePhysikalische TheorieZählenMotion CapturingKategorie <Mathematik>BinärcodeServerTaskDatenverwaltungPatch <Software>Konfiguration <Informatik>RuhmasseVersionsverwaltungFunktionalTopologieDisplacement MappingImplementierungKontrollstrukturCoxeter-GruppeMetropolitan area networkTreiber <Programm>ZweiLoginATMRechter WinkelOffene MengeAutomatische HandlungsplanungWurzel <Mathematik>JSONXMLUML
34:07
Rechter WinkelComputeranimation
39:50
Rechter WinkelMAPComputervirusSoftwaretestVorlesung/Konferenz
Transkript: English(automatisch erzeugt)
00:00
I work for Red Hat, I recently transferred from the SPICE team to the graphics team and I have been working for about the last six weeks on getting the X server to run without root rights, which is something long overdue, as the sheet says. So these are today's topics, which I plan to discuss and hopefully we'll have some time for questions at the end.
00:22
The first question is why. This is sort of a mandatory question, I hope no one really seriously asks why, but for those who do. The X server has traditionally always been root because back in the old days when we all had 486 machines, graphics were done from user space with user space mode setting
00:42
and we needed direct hardware access, and doing direct hardware access means you need to be root to make certain system calls like the IOPL call, which gives you IO permissions. But the X server is a quite large, complicated body of code and having it run as root is security-wise not really something which we want.
01:02
And with KMS, all hardware access is now done in user space. So we no longer really need the X server to run as root. So this, hopefully for those who were wondering why would you want to do that, well, mostly for security reasons. What do we need? We need access to dev input event and device nodes and dev DRI card device nodes, which
01:26
are currently open only to root most of the time. We need to do a couple of VT IOPLs for VT switching, so switching to text mode or switching between different X servers which are running. And we need to be able to lock somewhere and our current default lock location is
01:40
root only. So one of the dependencies is device access. Device access is typically restricted. For input nodes it's typically restricted because of things like eavesdropping.
02:01
You don't want if you have a multi-seat system or users logging in remotely be able to listen to what someone else is typing on the keyboard. Just opening up to write, we have a mechanism. It used to be console kit. Now it's done through systemd lognd where we tag devices in the udev database with the uaccess attribute and then automatically the device nodes get opened up.
02:23
The problem is for local users, so users who are present behind what we call a physical console, so something which is local to the machine. That's not enough. DRM set master, which is necessary for kernel mode setting, requires root rights. Having permission on the device node is not enough, it will still not allow you
02:40
to make that call. And some sort of arbiter is necessary for input devices, because if you are doing fast user switching, so you are switching between users on one physical head, then you want to revoke input access to the X server, which is running on behalf of the user, which is stepping away from the machine, so that he won't be able to eavesdrop on other
03:02
people's, what they are typing. These two reasons are why just using uaccess tricks is not enough. Luckily the Wayland people have the same problem and have been thinking about a solution for this. I'm sort of building on top of things mostly done for Wayland here. They came up with a new API, a part of systemd-log-n-d, because systemd-log-n-d already does device
03:25
management and seat management, etc., which starts with the take control, which makes you a session controller, and then you can also take control of various devices which are attached to the head on which that session is the active session. So this is, assuming we modify the X server to use this API and get file descriptors
03:45
over DBUS from systemd-log-n-d, this is sort of a solved problem. So how does this look inside the X server? I have a couple of API and also ABI changes coming up for drivers, which involve something
04:03
I call server-managed file descriptors, because the X server will be managing the file descriptor for the device node instead of the device driver doing it on its own. A driver's preinit for input or full probe function for video, it's called full because there are different probe functions for video cards, a method will be passed an open file descriptor by the X server, if system, server-managed FDs are active.
04:25
This is all optional. People don't need to worry that this is going to become mandatory, at least not in the near future. We also need to still have the X server running on Solaris and whatnot. This is all optional. So it won't get passed an open FD, and if it's a video driver, the FD will already be DRM master.
04:45
A slightly trickier area is switching between VTs. You know you have the X server running on VT1 or VT7, depending on your distro, and you can switch to a text console, or you can even run multiple X servers on different VTs. VTLeaf actually is pretty easy, basically because I chickened out.
05:06
We keep using the VT process VT mode. That means that the VT, the virtual terminal in Linux terms, is put in a special mode where even if you use a hotkey combination to switch away, you won't get switched away immediately. Instead the process gets a signal from the kernel, I want you to go away from this VT,
05:25
and then the process, in this case the X server, has all the time to do all the cleanup it needs to do, safely shut down all the devices, save device state for the GPU and what's not, and then it can signal the kernel, okay, you can continue. We will keep using this in XFlint, because otherwise there is way too much code to audit
05:44
to come to something which is safe for asynchronous switching. For server-based FDs, the server will do a DRN drop master for the video devices, and for input devices it will close them, because they get revoked and after that they're useless after a VT switch.
06:00
But this will happen after the normal leaf VT code has run, etcetera, so nothing much changes for the drivers here. On VTEnter, the story is slightly more complicated, because we will get a signal from the kernel at the same time that systemd.lognd gets a signal from the kernel that our VT is becoming active.
06:22
Normally, in the old case, we used to just as soon as we got the signal from the kernel on VTEnter we would start re-initializing the GPU and what's not, reopening input device nodes, etcetera. We cannot do that because they are being opened for us by systemd.lognd in an asynchronous manner. So what we do is we wait for systemd.lognd to give us debug signals over which it passes
06:45
new FDs for input devices, and it signals us it has retaken the master mode for video devices. We first wait for all the video device nodes to be back in master mode, to be resumed in systemd.lognd terms. And if at that time we already get some file descriptors for input devices, we put those
07:04
on a list. We remember that those need to be resumed later. Once we have all the video device nodes, we basically do the normal VTEnter handling we were always doing. So again, from a driver point of view, there is not a whole lot changing. A driver should not call drop master itself on leaf, it should not call set master itself
07:25
on enter, but that's pretty much all the changes at the driver level. For input devices, if input devices arrive after we have done the VTEnter handling, so they get resumed later, then we just re-enable them immediately, just like we re-enabled
07:41
them immediately on hotplug, if you plug in a mouse or whatever. So that concludes the part where the driver ABI changes are necessary, etc., and the problems with opening device nodes, which we had. Then there's the problem with, we want to keep using VTProcessMode, so we need to
08:01
be able to make a number of VTI octals. Actually this is allowed to do without root rights. If you are in the same session ID as the active session, as in the process management in the Linux kernel sessions, which is controlled by the TTI, by default the kernel, sorry,
08:21
the X server puts itself in a new session ID, it detaches itself from its controlling TTI. So we need to stop doing that, if we want to be able to run as non-root. Because you can only make these high octals if you are either root, or you are in the same session ID as the controlling TTI has.
08:41
So this is again pretty simple. Logging is also not all that hard, we can simply no longer write to far log. We cannot do that as a normal user. So there are two solutions, which will probably both get implemented, and then distributions can choose if they want to enable this, how they will use it.
09:00
One is to log to a place under the user's home directory, which by default is the XtgData home directory, which is sort of the default standard for logging inside home directories. And the other one is to log directly to journald. Some people may ask why not use syslog, because syslog is an easier way to get
09:22
to journald, and it may also be useful in other scenarios. The problem is that the syslog, the system call, is not safe to call from within a signal handler, and we do logging from within signal handlers. Because input IO is driven through signals inside the X server.
09:42
And that's also the problem for this. Leonard has already been reviewing patches to make some journald system called Signal Safe, now you know where those patches are coming from. So as I said before, the X server needs to have a controlling TTI.
10:04
That means that the display manager needs to do slightly more work. Because so far display managers have been cutting a lot of corners and just trusting. They have not really been starting the X server in a valid user session. In the typical sense of PAM, etc.
10:21
So in order to work with systemd.log and these API to control a session, we need to be inside a proper user session. So display managers will need to be changed to things like GDM, KDM, LightDM, etc. They will need to start XORC in a proper user session. So they will need to first set up a user session, set up the PAM session info for that session,
10:43
make sure the controlling TTI is set up right, and then they can start XORC inside it. This also means that display managers will need to start XORC twice. Currently, GDM starts XORC just as root. Then it starts the login screen as a GDM user.
11:02
And after that it re-uses the same XORC server to start the user session. It will need to start XORC twice now. Once to slow the login screen, and once that's done it needs to tear it down. And start it up again as a regular user. Some more work will be needed to maybe make that transition not be ugly.
11:22
And optionally, display managers may want to redirect the XORC logs somewhere. Assuming we're not just going to end up using the journal for those. This one I don't like. My favorite answer to this question, what to do about user space mode setting graphs,
11:42
because there are still a couple around, is just kill them. Kill them with fire. But I'm afraid that won't be an acceptable answer to some of our users. So we need to come up with something else. The first option is probably what I'll be doing somewhere in the next weeks,
12:03
add a setuid root XORC wrapper. Which completely makes no sense. I'm killing XORC running as root, and now I'm adding a setuid root wrapper. But it's probably the easiest way. And I can make it pretty safe. It can just check if there is a kernel mode setting capable card, and if there is one it will just drop root rights immediately,
12:22
10-20 lines of C code. Which hopefully can be audited to be safe. Famous last words. And if there is no kernel mode setting card, then it will just fall back to the unsafe mode. This will probably be optional. So if for this choice I can envision this coming in
12:41
some sort of separate RPM package or DBM package and users can remove it. Or maybe we won't even ship it by default. Further, in the future, it would be interesting to use simple DRM. Simple DRM is something which David Herman did, who gave the presentation before. It's actually part of the stuff he did for Miracast.
13:02
It's the user space driven framebuffer driver. In combination with U-VESA-FB, a framebuffer, to actually use the VESA BIOS to set up a dump framebuffer and then throw simple DRM on top to make it KMS capable. And use that as output on machines which don't have a card
13:20
which is supported by our kernel mode setting driver. These are mostly IDs. I am very much open to discussion and suggestions here. So a demo. Well, you have been watching it. This is my XOR clock.
13:41
Before I showed that you have been watching it. There is one thing since Jesse is in the room. It's saying this to me when I run as non-root. We need to look into that. Yeah, but...
14:00
And it's actually a real error. It's not just saying this I also lose the capability to control my brightness on my laptop screen. I have no idea. Hopefully Jesse will have some time to discuss this with me later. But you want to keep that?
14:26
Or do you want to move it into DRM? I think we'll be sticking with that. We are not going to change my preferences. Absolutely wrong.
14:41
Why we use it for AVL? It may not. No option for that. The thing is we can do access control on device nodes but never on stuff in slash sets. The backlight stuff is only in slash sets and doesn't have a device node. We are responsible for adding this as ADI. It's just what we use.
15:01
You don't have to revoke nothing so the users can keep the crap open. You can't solve it. It's not made for untrusted users to ever break. How bad is this we just opened the brightness control to the world? Maybe. I don't know. I'm just telling from the perspective
15:21
of Sisyphus there is no option to open ever up to untrusted users. Another option would be for us to add it. We've got properties for this on the DRM side so we could just have a property to hide anything. We're just discussing implementation options. I haven't thought about this yet because I only noticed this when I was
15:41
preparing this demo. How do you... Are you ready? Sorry, one more question about the backlights. How are you going to handle backlights in DRM when the backlight device is different from the GPU?
16:02
This MacBook has some separate chip that's not in any way related to the GPU. To which DRM device do you link that? The answer to that is I have no clue. As I said before, I noticed this 30 minutes ago. I just thought this would be a good audience to mention it and maybe get some ideas.
16:23
To show this is really the demo. Over here you see my second line. This is my X process. It's running as user Hans. Basically what I've done is I have disabled graphical login. I've programmed it to run level 3 which is not true because it's using systemd
16:41
and it no longer has run levels. I've told it to only start up with text CCs and then I do startX on the VC and since at least the text mode login knows how to properly set up a user session, unlike GDN. I can just do startX and it just works.
17:06
We were already sort of here anyways. Are there more questions? How too quick did I do it? Very much too quick. Howie? It's not really a question, just something I wanted to mention.
17:21
You keep the TTY ownership to the X server, as you said. In the long run we hope to make X something that is actually forked of the user bus, which basically means it's detached from any TTY because it's a singleton that is shared by all sessions of the same user. That means
17:40
it will not have one TTY to be attached to and it couldn't be attached to that, so there might be something to think about. That's a problem. Maybe do something special for X in the user bus. Is that a problem?
18:05
Yes. For the session management problem you don't really need the X server to run under the same user ID than the session that is running under X in the work that I did to implement previous separation in X for
18:22
OpenBSD. When we start the X server under XDM, it just runs under an X11 user and almost everything works. There is just a little problem with shared memory segments, but the new API that Kees committed a few weeks ago
18:41
that allows to create shared memories and pass a file descriptor to it solves this problem too. I guess we could do something where we make the X server set UID again but make it set UID to another user. I wonder though how useful that is because any program capable of attacking the X server will very likely
19:01
already be running inside the user session so it already has the same rights as X. So why would it bother with attacking the X server? It's just to serve the issues of not having to restart the X server between the display manager and the actual session. You can just use an unprivileged UID and run under this UID.
19:20
And that's not going to work with systemd-lognd integration. systemd-lognd will want to see the X process as part of the session, otherwise it won't allow it to take control of the various devices. It won't allow it to open your mouse, it won't allow it to open your keyboard. Because the user who is the active user for that seed is the only one who is allowed to open the keyboard and the mouse, etc.
19:41
If you start taking multi-head systems, etc. that just won't work what you're suggesting. You need something smarter. Yeah, wait for the mic please. Otherwise the video people become unhappy. We don't have video streaming but... We do?
20:01
Give me the link. If I got you right it will be impossible to use this non-root X without the system there. So in such distributions like Debian where we still do not have this it will be unusable.
20:22
As said, I will keep things working in the old fashion for some hours and whatever. This is all optional. But you won't need systemd lognd. Even if you don't want to use systemd, you will need systemd lognd anyways. Everything is moving to systemd lognd. Consolekit is dead.
20:40
No one is maintaining it. So you need to figure out something like just switch to systemd already. It's just better. Just to quickly mention that lognd has been ported by the Ubuntu people to non-systemd however the tech controls bits, like the device access control
21:01
bits are not included in that version because it's really old. Good luck! More questions?
21:20
Seems like that is your talk. 20 minutes. You do know that you have to fill two slots now, right? I can talk about old winner devices or something. That's reserved for tomorrow. I know. Faster than I expected.
21:47
If you already start the next server for the GDM login, couldn't you keep that running and have if another user wants to login just switch to that next server instead of tearing it down and starting a new one.
22:01
That is actually what we're doing today and what we want to get rid of because the way systemd lognd works is that a certain user is seen as the owner of the active session on a head and that one is the only one which is allowed to open things like the keyboard and the mouse and even if the process
22:21
can keep the file descriptor open a revoke IOCTL will be done on those file descriptors by systemd lognd as soon as another session becomes the active session on that head. So the X server could keep running and it could keep the file descriptors open but it can no longer do anything with the file descriptors including reading from them to get input. So it just won't work as far as I know.
22:41
Can we get the mic back to the front please? So there's of course results in the next question which is if you have the X server for GDM and then later on the X server for the actual session, how do you
23:00
make sure that it doesn't flicker? We have the same problem already when we go from the boot splash screen to X or when we switch on X between multiple consoles. We will have the same problem with Wayland because Wayland is following the same model where you will have one Wayland for the login manager and a separate Wayland for... This is something which needs to be solved by the graphics people, maybe with some
23:21
extra kernel API and just have some way to get the current content on the screen so the X server needs to be able to shut down without corrupting the screen and then a new one needs to be able to get the old screen content and it will fade over or whatever. I know David Herman was thinking about it. Is he back in the room or is he still discussing?
23:41
If you can read out the screen That's a good point. Then maybe we need to have the X server which is dying fade to black and have the other one pick it up from there. I know they're thinking about it.
24:04
The old user space just needs to fade to black and the last thing that has been displayed will stick around. So if you leak some stupid stuff like your password or banking details, that's your problem. We keep everything around until the next server
24:20
picks it up and can transition to whatever it wants to. Something like the display manager which knows that there will be no sensitive info on the screen could even just keep the old content for a better transition. It used to switch back to text mode so is this assuming that there is no text mode anymore or is this restriction
24:40
with switching back to text mode if there's nobody who wants graphics? Gone. If the last thing that kind of controls the well the last year end device closes and everything dies
25:00
we switch, forcefully switch back to the FBCOM under the assumption that just everything died and you actually want to log in through VT and see what happened. But as long as someone keeps open a year end master note someday we're not going to do that. So as long as your system
25:21
login thing or another session keeps the year end device open and otherwise just go FBCOM. The world is a better place without it.
25:46
So what's the status of your work right now? Is there something that could be sent upstream tomorrow or what do you have left to do? Not tomorrow, I have some review comments from Dave early on my first version of the Batchat so I need to
26:00
rework some code but in about a week I should be able to send it upstream. Actually a lot of preparation patches are already upstream. I had to split some functions etc. that's already all upstream. So this is definitely going in the next major release of the Xserver, so 1.16.
26:38
As you already have an Xserver for
26:41
login can't that one keep running and just spawn a new one for the user that logs in on a separate VT or whatever it's being called in the future. Opening a separate VT requires root rights.
27:02
Yes, but that's a task for the login date. Yes, it is possible to keep the Xserver for the display manager running on say VT1 and put the user session on VT2 and then you could even just when you choose the fast user switch option it could even be just a switch to VT1 because GDM is already waiting there.
27:22
That's an implementation detail of the display manager. It's even possible that one display manager chooses one model and another display manager chooses the other model. That was mostly my question. Thank you. At the reason of committing heresy here, did you think about
27:41
if the binary driver can make this work? Yes actually I've already been in contact with the companies behind the binary drivers and for now it won't definitely won't work for AMD because AMD is still banging IO from userspace. For NVIDIA it looks slightly more promising but they also have some work to do.
28:02
For now they will probably just fall into the category which is handled with whatever solution I come up with for user mode setting driver compatibility. Yes.
28:21
But I am keeping an eye out for those drivers and trying to keep them going to work. Somewhat. So if there are no more questions then I wish you a pleasant second lunch break. Thanks for having me.
28:42
So the next presentation has been cancelled so you have an extra long one. Oh! I didn't know that. The plane of the presenter got stuck.
29:00
That's too bad.
51:53
Level test. Hello.