> Hi Steve, > > We've talked about this somewhat before on the Wayland ML. You proposed some > ability to decouple the security policy from the compositor with Wayland > Security Modules. My opinion is still the same as before: it's a mistake to > decouple the security policy and desktop environment. The two need to be > designed hand-in-hand in order to have a safe, testable, usable experience.
Hi Jasper! This is not quite what I want, but true in part. I'm a XFCE guy, I believe in modular DEs where people can replace a component because they dislike it / have access to a more innovative one / have special needs, etc. So, I don't quite like when a DE becomes more and more monolithic and acknowledges only its own way of performing each and every task of a user's day-to-day experience. The reasons I want to reach some level of agreement between all major DEs are: - You can then take an app from another DE and have it respect your current security policy because it speaks the same language: no being locked to some specific technology! - I'm a normal human being, not made by combining the DNA of Stallman, Schneier and Torvalds all together! I can't possibly design a whole desktop computing experience centered around what I know of security and usability (and yet I know a lot!), that'd match the expectations of a sufficiently large user base, without taking to the existing experts in building consistent user experiences! You and I may be able to build better experiences for our user base simply by exchanging on how to make security usable. Given how auth UIs are managed in Linux (including GNOME) there is a need for some form of guidelines on how to implement them (which is the specific topic of this article, many more to come on other topics). > It's more complicated, in terms of code, testing, auditing, and user > interaction to have two independent moving parts try to come together to form > a security policy. True, but if we can do it (and my belief is we do can!) then users get a much better experience! Example? If GNOME implements secure File Open dialogs that give access to a file only after the user selected it in a third-party process's GUI, how do you make KDE apps compatible? Let them have access to everything? Then guess what happens when a user installs malware? It does not build against your optional GNOME-only security :) And really, who expects to have GNOME users who don't use a single Qt app? VLC, LibreOffice and Skype should come to mind. No matter how much of a special experience GNOME creates with its own apps, users will still occasionally need the odd Qt app that works differently. And by the way, if just KDE and GNOME agree on using third-party secure file dialogs (by using a common IPC API), then I no longer have to tolerate the Qt File Dialogs and you've no idea how happy that'd make me as a XFCE/GNOME user! > It's also unfortunate that your solution, "WSM"s, only focuses on security > Wayland protocol, rather than some other protocols or technologies we use, > like DBus or CORBA. WSM is a placeholder name for the security component managed by the compositor (e.g. mutter/Shell in GNOME's case) and implementing at least the API in the Wayland protocol (so far clipboard, virtual input devices and access to recording capabilities in Martin and I's plans). We can call it DE Proprietary Logic Security Non-Module That Still Talks a Little Bit to Neighbours if you want ;) > In my opinion, one needs to design an entire operating system, from the > desktop to the kernel, with security in mind, rather than bolting it onto the > side one protocol at a time. Yes, one does! I'm doing my PhD on precisely this topic and am constantly reminded that I'm too ambitious. Truth is nobody can fix and repair the whole of Linux userland in just one go. It's too big and there's too much app rewriting to do. It'll take years before somebody's solution takes off and becomes a de factor standard, but that doesn't mean some obvious fixes can't be applied just yet. Do you think it's ok to have authentication dialogs that don't tell you who they send your password to just because we don't have a solution to no-hassle desktop app sandboxing? > I think every Linux user has experienced issues with modules like SELinux > preventing applications from doing things that the application needs to do. > Application developers rarely write applications with certain operations > failing. Users often don't know why applications are failing and are > confused. The policy doesn't really have much documentation to explain why > certain operations are dangerous, and why the application is attempting to do > a dangerous operation. The only way to change the policy is to run a random > program in a terminal as root. > > From the user's point of view, SELinux hasn't really helped their computer be > any more secure, and is just "getting in the way", so they disable it. The > full experience is extremely subpar, since it was bolted onto the side > instead of being designed and integrated into the system. SELinux is *not* for userland, will never be. It's got partly to do with what it does and partly to do with the nature of human action. First SELinux does atomic-syscall MAC, you'd need at the very least a temporal logic to provide for indirect information flows / covert channels. Then sometimes what distinguishes a user's actions from malware's actions is not sequences of syscall but some contextual information: what data is open, or where is it sent? The second issue is less obvious, and yet: users can do *a lot* of stuff with computers, often unexpected or contrary to common sense. There will never be One Policy To Rule Them All. There's always gonna be situations where users want/need/are perfectly right to bypass security policies. The usec researcher's version: http://discovery.ucl.ac.uk/1389948/ and the anthropologist's version: http://www.cambridge.org/ve/academic/subjects/computer-science/artificial-intelligence-and-natural-language-processing/plans-and-situated-actions-problem-human-machine-communication-2nd-edition > Hashem Nasarat points you to Stef Walter's talk at GUADEC, who makes a lot of > the same points about this. Security is mostly a human problem, rather than a > technical problem, and attempting to solve human problems with code and > pluggable modules usually results in the human buying a Mac. Security is a socio-technical problem indeed, however technical issues cannot be discarded just because it's so hard to account for the human factors. If you re-read the article, for instance nobody in the Linux world proposed before that authentication dialogs authenticate to the user before asking for a secret, nobody posited that we should habituate our users to that and nothing else because otherwise they will be failed by spoofs. At the moment even security experts cannot tell if an auth dialog is legitimate, so how can we help humans build a proper mental model of authentication experiences if we don't even have the *techniques* to differentiate the good from the fake? How exactly do I not account for the prevalence of human factors in the stuff I discuss? I could give lectures on how most usable security researchers don't care the least about making their stuff applicable to users and how they ignore elementary aspects of usability and economics of infosec, simply because it doesn't matter to their citation count and career advancement. The reason why I discuss with Linux communities rather than conference committees is because I care enough to do practical stuff that runs on people's computers and betters their lives. I'm not trying to defend my church, I don't care the least whether one will call their code a module or something else, as long as some ideas have been explored and evaluated, and some problems have been fixed. Thanks, -- Steve Dodier-Lazaro PhD student in Information Security University College London Dept. of Computer Science Malet Place Engineering, 6.07 Gower Street, London WC1E 6BT OpenPGP : 1B6B1670
_______________________________________________ gnome-keyring-list mailing list gnome-keyring-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-keyring-list
