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.
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. 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. 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. 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. 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. On Wed, Mar 26, 2014 at 10:56 AM, Dodier-Lazaro, Steve < s.dodier-lazaro...@ucl.ac.uk> wrote: > Hello, > > Currently on the Wayland ML, a bunch of devs are discussing security > issues [0,1] and the need to restrict userland processes' privileges to > e.g., take screenshots, act as virtual keyboards or read keyboard events > for other apps, etc (basically introducing privileged interfaces that > require explicit user authorisation). We've also been discussing how the > introduction of Wayland allows for redesigning and securing authentication > and authorisation UIs. > > This has led me to question the way authorisation and authentication are > currently done, and to write a couple of proposed requirements for both > tasks. I'd be very keen on hearing the opinions of various DE developers on > a blog post I've written [2], that focuses a lot on the infrastructure > needs (both in Wayland and desktop environments). I'd also like to debate > UX aspects of authorisation and authentication UIs. As far as I'm aware > GNOME Shell implements a polkit agent and so relies on the polkit > infrastructure for all its auth needs. Given the proposals I made (which > really are ideas that need experimentation and refinement), what would fit > within the GNOME way of doing things? What's the viewpoint of the UX people > in GNOME? Can you spot any missing technical (security or UX) requirements > in the post? Anything you disagree with and want me to review? > > Thanks, > > [0] > http://lists.freedesktop.org/archives/wayland-devel/2014-February/013359.html > [1] > http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and-how-to-handle/ > [2] http://mupuf.org/blog/2014/03/18/managing-auth-ui-in-linux/ > -- > 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 > > _______________________________________________ > desktop-devel-list mailing list > desktop-devel-l...@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > -- Jasper
_______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
