GNOME.org
 

Re: Request for comments on security of authentication/authorisation UIs

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 12 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,

--
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-list gnome org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list



--
  Jasper
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]