<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <style type="text/css" style="display:none"></style> </head> <body> <div style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;"> <p></p> <div>> Hi Steve, thanks for the thoughtful response.</div> <div>> </div> <div>> PAM's technical implementation allows a number of modules to be tried in</div> <div>> order for authentication. Your API, as a PAM authentication module, is</div> <div>> limited to four operations: ask the user a non-secret question (with a</div> <div>> textual response), ask the user a secret question (with a textual</div> <div>> response), tell the user a piece of information (with no guarantee how this</div> <div>> will be displayed, or if it will be erased upon the next request), or tell</div> <div>> the user about an error (again, with no guarantee).</div> <div>> </div> <div>> This directly limits the types of authentication you can do: you can't</div> <div>> easily do out-of-bound authentication UI like facial detection unless the</div> <div>> thing using PAM knows enough about the stack to put up a webcam display.</div> <div>> </div> <div>> In addition, PAM only supports one module at a time, meaning it's</div> <div>> impossible to run multiple at the same time (enter your PIN, swipe your</div> <div>> fingerprint, or wave a smartcard to unlock); the user first has to fail</div> <div>> three times on the PIN before moving to the next module in the stack.</div> <div><br> </div> <div>On one hand that is a problem, but on the other hand if a module were run in</div> <div>parallel with another one, a policy would be required to decide what to do when</div> <div>one returns "Yes" and the other returns "No". Typically face detection or </div> <div>fingerprint detection is not so hard to spoof, and an attacker would always go</div> <div>for the easy way in if users were to choose which PAM module to use to </div> <div>authenticate. I'm getting offtopic though!</div> <div><br> </div> <div>> This flexibility on the part of the system builder means it's hard for us</div> <div>> to build an API. Additionally, it's hard to do things like automatically</div> <div>> log the user in unless we make the assumption that pam_unix is the first</div> <div>> entry in the stack, and simply replay the user's password to the first</div> <div>> secret question request we get. (This might sound silly, but this is a</div> <div>> problem we had with our Initial Setup tool, which already takes the user's</div> <div>> password as part of the setup process).</div> <div>> </div> <div>> Obviously, there's nothing fundamentally wrong with the security model of</div> <div>> PAM, it's all just in the implementation details. But I'm afraid we're</div> <div>> going to run into the same trap here: you're going to write a specification</div> <div>> and code for a WSM framework, in which we might pass it not enough data,</div> <div>> and the module won't have enough data to determine whether to allow or deny</div> <div>> such an application.</div> <div><br> </div> <div>I would state that the issue here is that you are allowed to provide modules</div> <div>that make a local security decision (on an auth factor) but that cannot also</div> <div>decide on the global policy. If that's a correct translation of your concern,</div> <div>then I believe I understand what you're worried about. I'll explain my personal</div> <div>view on what a WSM should provide below.</div> <div><br> </div> <div><br> </div> <div>> Has this same application spammed the screenshot app more than 10 times in</div> <div>> the last minute? How much disk space is it using right now? Has the user</div> <div>> tried to kill this application before for misbehaving? Do we have any data</div> <div>> on record about this app? Are there updates to this application available?</div> <div> </div> <div>I would rather say then that you want to make decisions on applications at a </div> <div>higher level than just the compositor, possibly using compositor information</div> <div>in the process. That's fine, see below!</div> <div><br> </div> <div><br> </div> <div>[snip]</div> <div>> ></div> <div>> > Here you're not speaking about infrastructure but policy. Who decides who's</div> <div>> > allowed to use the gnome photo service? Who enforces that?</div> <div>> </div> <div>> </div> <div>> In the app sandboxing mechanism we've discussed before, an application can</div> <div>> only use the capabilities it's requested. If it requests the "Chat"</div> <div>> capability, then I'd assume we'd allow it to use the wl_notification_shell</div> <div>> interface along with org.freedesktop.Telepathy, and access "~/Personal</div> <div>> Data/Chat Logs".</div> <div>> </div> <div>> It was just a simple example, and the details need fleshing out, but I feel</div> <div>> it's a powerful metaphor for the user: instead of asking about the</div> <div>> low-level details, it works out a relatively sane high-level definition of</div> <div>> what a role would have, and what low-level operations it might encompass.</div> <div><br> </div> <div>I have rather strong opinions on how and what to sandbox but they would be very</div> <div>offtopic, I'd love to chat about this with you though if you're interested in </div> <div>the topic. Shortly it seems to me you'd be interested in FBAC (http://schreuders.org/FBAC-LSM/).</div> <div>I personally dislike the idea of per-app sandboxing and feel uneasy with having</div> <div>to label apps with any kind of information on what they can be used for, though</div> <div>that's already quite flexible and easy to setup. I just don't trust packagers to</div> <div>make security/usability decisions for me.</div> <div><br> </div> <div><br> </div> <div>> </div> <div>> This policy certainly could be governed by a WSM, but I feel that</div> <div>> implementing a "Wayland Security Module", a "DBus Security Module", and a</div> <div>> "Local Filesystem Access Security Module" would be missing the point: these</div> <div>> are all system APIs, and should be governed together instead of separately.</div> <div>> Allowing me to patch in a WSM that always allows, but keeping the DBusSM</div> <div>> the same isn't much help.</div> <div>> </div> <div>> For a screenshot app, it might want access to wl_screenshooter and</div> <div>> "~/Screenshots". These would be governed by some system policy.</div> <div>> </div> <div>> I just don't think we need a generic infrastructure with hooks and plugins</div> <div>> to enforce a policy.</div> <div><br> </div> <div>If you want to choose to give access to any kind of feature to any app then you</div> <div>need to hook on it, and on any IPC to privileged processes that might be used as</div> <div>confused deputies, at least. In your view, what would be the ideal approach to</div> <div>monitoring access to wl_screenshooter?</div> <div><br> </div> <div> </div> <div>> I'm not so sure. I'd hate to invent a complex set of policies and code for</div> <div>> such a "WSM" without thinking about DBus or filesystem access at all, and</div> <div>> in the end, we have two different systems and policies for two different</div> <div>> things.</div> <div>> </div> <div>> DBus already has policy enforcement for system services in a custom</div> <div>> XML-based rules language, and it's configured with a completely separate</div> <div>> set of tools than SELinux. It's extremely painful to deal with as a system</div> <div>> builder, and adding a third pluggable, potentially-different system is</div> <div>> exactly what I'd like to avoid.</div> <div>> </div> <div>> Wayland and DBus are not isolated, they're going to be used in close</div> <div>> concert together. That's not hypothetical: our Wayland applications expose</div> <div>> a DBus name on them, which we use to find the application menu that we show</div> <div>> in the top shell. This is code that I wrote and am running right now.</div> <div>> </div> <div>> Working on solutions that acknowledge this and don't treat Wayland as</div> <div>> separate are more valuable to me, a desktop builder.</div> <div>> </div> <div>> So, let me ask a very technical question: I am writing the code to</div> <div>> implement WSMs in mutter. What do I do? Do I scan</div> <div>> /usr/lib/wayland-security-modules/, look for .so files, and load them all</div> <div>> with dlopen, and then call wsm_module_register on them? If a client</div> <div>> requests a privileged operation, do I call</div> <div>> wsm_module_can_this_client_do_this_operation in order, looking for an</div> <div>> answer from one of them?</div> <div>> </div> <div>> Why would I go through the trouble of loading WSMs when I could simply use</div> <div>> the same application sandboxing mechanism in the first place? When we</div> <div>> implement sandboxing, we'd probably recommend that system builders don't</div> <div>> modify the stock set of WSMs that we ship with, so why allow the</div> <div>> indirection?</div> <div><br> </div> <div>An app sandboxing will require entire graphic-stack-level isolation anyway,</div> <div>and you can be sure there will be plethora of perfectly legitimate reasons for a</div> <div>user to want an application to bypass its sandbox and access another app's files</div> <div>or share data with other apps. My concern with any fine-grained sandboxing is in</div> <div>figuring out who will maintain the rules, and in particular I don't wanna see</div> <div>situations where developers of apps or packagers are trusted to decide what</div> <div>capabilities an app should be given because the former will lie to propagate</div> <div>malware and the latter will not pay attention. Especially, custom-installed apps</div> <div>would get their configuration straight from the app (and these are the most</div> <div>likely to be malicious). No, I don't buy the idea that a user would review the</div> <div>capabilities of an app before installing it. If it were true nobody would ever</div> <div>have installed Angry Birds on their phone.</div> <div><br> </div> <div>So rather than describing what an app can do, I would rather decide in situation</div> <div>whether it makes sense that an app accesses a service based on what information</div> <div>I have. My approach for my own system would also redirect information from the</div> <div>compositor onto a larger decision engine that does some FS access control, and</div> <div>isolation (of groups of processes rather than single processes). Discussing that</div> <div>further would be offtopic but for me what matters here is that any solution</div> <div>would require some control over the compositor's action (hence the compositor</div> <div>must be asking for permissions somewhere or taking orders from someone) and also</div> <div>that the compositor communicates some information to the decision engine.</div> <div><br> </div> <div>Now, where would WSMs stand in all that? (Disclaimers: this is my opinion, and</div> <div>certainly not a definitive statement! Besides I don't know anything to the </div> <div>Wayland internals compared to you or Martin!) I believe there should be an </div> <div>nterface of functions to be implemented to qualify as a WSM, and there could be</div> <div>one WSM running at a time. The WSM may be a standalone .so or belong to a larger</div> <div>program that implements a DBus/kdbus interface, as long as there is a clear and</div> <div>unique trusted path to that WSM.</div> <div> </div> <div>That interface would allow the WSM to react to 1) receive information about</div> <div>whatever events occur in a compositor / window manager, about privileged</div> <div>interface requests, usage of clipboards (and generally speaking whatever in XACE</div> <div>is still relevant to Wayland), etc. ; 2) react to them by informing the</div> <div>compositor that they cause a violation of the security policy and by providing</div> <div>feedback to be handed over to the user ; and 3) by giving instructions to the</div> <div>compositor later on if necessary, after the engine implementing the interface</div> <div>has used external information to make a decision about a windowed application</div> <div>(path of process, open files, plus whatever semantics your DE offers you on</div> <div>applications (user reporting an app as annoying, history of app interactions,</div> <div>etc)). </div> <div><br> </div> <div>On the other hand, you could have a standalone policy that already limits the</div> <div>harm that can be done strictly speaking at the windows level - namely spying on</div> <div>other apps by restricting access to screenshots, virtual keyboards, etc, or that</div> <div> prevents modal fullscreen windows...</div> <div><br> </div> <div>We may also think that it's a good idea to let compositors expose some of their</div> <div>own internals or some methods to control windows, or window decorations (used by</div> <div>Qubes OS for instance, and I would for sure make use of the ability to modify a</div> <div>window's decorations in my own project). I'd see no issue at all in that as a</div> <div>way to extend the security module's interface if needed (but I'd like to hear</div> <div>more educated opinions about the matter).</div> <div> </div> <div>One unrelated (or maybe not) point I'd like to make on this list is that from</div> <div>the layman user's perspective (which is not accurate but also hardly </div> <div>challengeable), s/he does not observe processes running and then spawning an </div> <div>arbitrary number of windows and doing IPC in any uncontrolled way, but windows </div> <div>being opened and closed (plus some magic apps providing services without a </div> <div>window!). I don't think that it's reasonable to expect a user to conceptualise </div> <div>their security requirements elsewhere than around their own data and what's </div> <div>directly under their nose: windows. So I would assume that a good security UX </div> <div>would articulate rules and feedback around the windows rather than the actual </div> <div>processes/apps. This has a nasty implication if you think of the forms of </div> <div>multitasking that need to be supported, that several windows may belong to the </div> <div>same process, and that you don't quite allocate privileges and access to files </div> <div>to a window but to a process.</div> <div><br> </div> <div> </div> <div>> Having an all-in-one solution that acknowledges that DBus, Wayland, and</div> <div>> library and system calls are all tools in one giant API is a lot better to</div> <div>> me than implementing separate policy enforcement mechanisms that might be</div> <div>> inconsistent and conflict with another. It makes me more sure of the user</div> <div>> experience that we can deliver and of the security of it.</div> <div><br> </div> <div>I think the point we're arguing on is whether there should be a Wayland-stuff/</div> <div>compositor only policy shipped with the interface allowing complete mediation of</div> <div>the graphic stack, or whether there shouldn't. As far as I'm concerned, it can</div> <div>mitigate perfectly valid and harmful threats to have a sound default policy on</div> <div>how windows interact with one another, provided ofc. that no other capabilities</div> <div>allow the same threats to exist elsewhere. I don't think however that a composi-</div> <div>tor alone will ever be in a position to know what else exists on the user's OS</div> <div>and I don't think either that it's the goal of a project like Wayland to </div> <div>redefine even how file systems and IPC work on Linux/*NIX systems in the name of</div> <div>security. I think it's more tractable to go for easy goals that are within </div> <div>direct reach of this project, and to provide enough infrastructure to help those</div> <div>like you or me who believe new desktops can be designed with higher security</div> <div>standards.</div> <div><br> </div> <div>I'm not trying to go anywhere further when it comes to setting best practice</div> <div>because I doubt even as many as two people will agree on what the security-</div> <div>usability requirements should be, because different DEs/contexts of use impact</div> <div>the default policy to be used, etc. I find it easier to fork projects, hack my</div> <div>code into them, build a PoC desktop and evaluate its security and usability.</div> <div>Then I can come and claim that I found how to provide security on Linux desktops.</div> <div><br> </div> <div> </div> <div>> The main reason I wrote this email was because you said "if there were no</div> <div>> complaints, we're going to start writing the code now". It's not that I</div> <div>> don't like what you're doing or think that a security interface is</div> <div>> absolutely bad, I'd just hate for you to rush into the implementation and</div> <div>> not think about it for a little while longer.</div> <div><br> </div> <div>That's not what *I* have said, I would actually rather refine my own idea of how</div> <div>the whole desktop's security model should work before I gave a final draft of</div> <div>what I'd like to see in WSMs, and I also believe others with different ideas of</div> <div>security should do the same so that we improve the odds of having flexible</div> <div>enough an interface.</div> <div><br> </div> <div>Thanks,<br> </div> <div> <div class="BodyFragment"><font size="2"><span style="font-size: 10pt;"> <div class="PlainText">--<br> Steve Dodier-Lazaro<br> PhD student in Information Security<br> University College London<br> Dept. of Computer Science<br> Malet Place Engineering, 6.07<br> Gower Street, London WC1E 6BT<br> OpenPGP : 1B6B1670<br> </div> </span></font></div> </div> </div> </body> </html>