Recently, I filed a bug (1274451) about running virt-manager on Wayland. As it turns out that this is applicable to running gui applications as root on Wayland in general, the scope was changed (see Cole's comments).
As Halfline points out, the decision needs to be made whether to allow gui applications to be run as root. I figured I'd bring this up for discussion in the hopes that a decision may be made whether or not to allow this.
In the instance that the decision is made to not allow gui applications root access, then we will also need to figure out a sane way to have applications that require more than the usual set of user priviledges to continue to work across multiple compositors and window managers that may or may not have the necessary authentication agents built-in.
John.
----- Original Message -----
Recently, I filed a bug (1274451) about running virt-manager on Wayland. As it turns out that this is applicable to running gui applications as root on Wayland in general, the scope was changed (see Cole's comments).
As Halfline points out, the decision needs to be made whether to allow gui applications to be run as root. I figured I'd bring this up for discussion in the hopes that a decision may be made whether or not to allow this.
In the instance that the decision is made to not allow gui applications root access, then we will also need to figure out a sane way to have applications that require more than the usual set of user priviledges to continue to work across multiple compositors and window managers that may or may not have the necessary authentication agents built-in.
We already have those mechanisms: polkit (né PolicyKit) and D-Bus.
This is how we control backlights, LEDs, network connections, Bluetooth, geolocalisation, etc. in a standard Linux desktop.
Cheers
On Fri, 2015-10-30 at 11:41 -0400, John Dulaney wrote:
As Halfline points out, the decision needs to be made whether to allow gui applications to be run as root. I figured I'd bring this up for discussion in the hopes that a decision may be made whether or not to allow this.
Anyone running any X (or wayland) application as root in their desktop session is completely bonkers and deserves every consequence of their poor decision.
In the instance that the decision is made to not allow gui applications root access, then we will also need to figure out a sane way to have applications that require more than the usual set of user priviledges to continue to work across multiple compositors and window managers that may or may not have the necessary authentication agents built-in.
Like Bastien said, we've had this for ages. Typically people resist the solutions here because they consider it "bloat" or "unnecessary complexity"; the irony is not lost on me.
- ajax
On Fri, Oct 30, 2015 at 2:48 PM, Adam Jackson ajax@redhat.com wrote:
On Fri, 2015-10-30 at 11:41 -0400, John Dulaney wrote:
As Halfline points out, the decision needs to be made whether to allow gui applications to be run as root. I figured I'd bring this up for discussion in the hopes that a decision may be made whether or not to allow this.
Anyone running any X (or wayland) application as root in their desktop session is completely bonkers and deserves every consequence of their poor decision.
OK, I'll bite. Why is it bonkers?
It's certainly the case that *gnome* might do something ridiculous if you 'sudo gedit' something, but 'sudo emacs' really ought to be equally acceptable regardless of whether you're using the terminal or X frontend.
In the instance that the decision is made to not allow gui applications root access, then we will also need to figure out a sane way to have applications that require more than the usual set of user priviledges to continue to work across multiple compositors and window managers that may or may not have the necessary authentication agents built-in.
Like Bastien said, we've had this for ages. Typically people resist the solutions here because they consider it "bloat" or "unnecessary complexity"; the irony is not lost on me.
We have pam_sudo (or whatever the thing is called -- it's worked mostly reliably for ages, and it's really quite handy).
ISTM the straightforward solution to all of this would be for Wayland to allow a connection from anyone who can connect to the socket. Then just set permissions on the socket accordingly.
--Andy
Hi,
It's certainly the case that *gnome* might do something ridiculous if you 'sudo gedit' something, but 'sudo emacs' really ought to be equally acceptable regardless of whether you're using the terminal or X frontend.
emacs is probably okay, just by virtue of the fact that if the admin gives the user the right to run emacs as root, they almost definitely trust the user with general root access.
In that same light, it's probably fine if the user running sudo has full access to sudo anyway, but it's considerable riskier if it's a restricted sudo configuration or say consolehelper (or worse a setuid application!). The problem is that X is a big api and it's designed with the notion that everyone who has access to the display is pretty much at the same trust level. It's possible to prod and poke at one client from other clients in pretty arbitrary ways.
As I know you know, it's generally a good idea to have code running with elevated privileges as self contained as possible and accessible with as narrow an interface as possible.
the wayland protocol is a little better than X, it doesn't let clients see much past themselves, or let them influence other clients in as ad hoc of ways. Still, code running with elevated privileges should be *small*, doing whatever job it's supposed to do. And that job shouldn't be interacting with the user. you don't need elevated privileges to interact with the user, so why would put the code to interact with a user in a process running with elevated privileges ?
polkit solves the problem nicely because it encourage separating mechanism from interface, and gives fine grained control via named actions, not programs.
Anyway, that's the argument, as I understand it, in broad strokes.
--Ray
Hi,
It's certainly the case that *gnome* might do something ridiculous if you 'sudo gedit' something, but 'sudo emacs' really ought to be equally acceptable regardless of whether you're using the terminal or X frontend.
emacs is probably okay, just by virtue of the fact that if the admin gives the user the right to run emacs as root, they almost definitely trust the user with general root access.
In that same light, it's probably fine if the user running sudo has full access to sudo anyway, but it's considerable riskier if it's a restricted sudo configuration or say consolehelper (or worse a setuid application!). The problem is that X is a big api and it's designed with the notion that everyone who has access to the display is pretty much at the same trust level. It's possible to prod and poke at one client from other clients in pretty arbitrary ways.
OK, so what are the risks under Wayland?
Today I've found out that I'm unable to merge my rpm config files under Wayland. I've been using this for years:
$ sudo rpmconf -a -f meld
Currently, meld doesn't start this way. I don't know about any good merging tool in CLI. I spent 15 minutes trying to merge my config files with vimdiff, I started hating it with passion, and I ended up with broken configs. What solution are we going to offer people who can't do everything in console and need GUI tools to perform certain administrative tasks (I'm not really sure how polkit fits in this scenario)? Honestly, I'd rather run a nested X server to be able to use meld than to use vimdiff again, and I guess I wouldn't be the only one.
Since the security is improved under Wayland, are non-elevated applications still able to eavesdrop or falsify input/output of elevated applications? The opposite direction is not that important, I think, because if you run something as root (regardless of CLI or GUI), you explicitly trust it to do almost anything to your system. If you decide to trust gedit or meld, I don't see the difference from trusting vim or emacs. Unless there's something in Wayland that is similar to vulnerabilities in X11?
Thanks for explanation.
OK, so what are the risks under Wayland?
...
Since the security is improved under Wayland, are non-elevated applications still able to eavesdrop or falsify input/output of elevated applications? The opposite direction is not that important, I think, because if you run something as root (regardless of CLI or GUI), you explicitly trust it to do almost anything to your system. If you decide to trust gedit or meld, I don't see the difference from trusting vim or emacs. Unless there's something in Wayland that is similar to vulnerabilities in X11?
Thanks for explanation.
Either I missed it, or nobody replied to my question. I'd be really interested to read the answer, if somebody knows it, thanks.
I'm not saying we should not minimize the number of operations that we need to perform as root. Sure we should. But there will always be some root-only ones. In the old days, we said "X11 is not safe, that's why you should use CLI tools as root, GUI tools are not recommended". And now that we can possibly have secure windowing system, we say "GUI tools as root can't be used at all". Which is the opposite answer than I expected from the Wayland hype, I imagined "both CLI and GUI are safe now, use whatever you like". So, what are the attack vectors under Wayland that CLI apps don't have?
On Fri, 2015-10-30 at 14:58 -0700, Andrew Lutomirski wrote:
On Fri, Oct 30, 2015 at 2:48 PM, Adam Jackson ajax@redhat.com wrote:
Anyone running any X (or wayland) application as root in their desktop session is completely bonkers and deserves every consequence of their poor decision.
OK, I'll bite. Why is it bonkers?
It's certainly the case that *gnome* might do something ridiculous if you 'sudo gedit' something, but 'sudo emacs' really ought to be equally acceptable regardless of whether you're using the terminal or X frontend.
Same reason you probably don't want to run your irc client as root: you're trusting the server to be well-behaved, through code that isn't expecting to need to do input validation. Consider this class of security bug:
http://www.x.org/wiki/Development/Security/Advisory-2013-05-23/
Also, at least under X, you're trusting _every other app in the session_ to politely ignore the privileged client. There's nothing to stop another client from blitting a deceptive image into the privileged window, or from creating input-only children of the privileged window and stealing its keystrokes (and forwarding them on to the privileged app however it sees fit, which might not be unmodified).
This is all somewhat hypothetical, granted. Certainly one can construct scenarios where it'd be safe enough. Probably there's selinux policy for X that could fix this kind of abuse, and wayland has a much smaller surface for this class of bug to sneak through.
But, why take the risk exposure, when you could simply not?
ISTM the straightforward solution to all of this would be for Wayland to allow a connection from anyone who can connect to the socket. Then just set permissions on the socket accordingly.
Unless I'm missing something, there's no way to set permissions on a unix socket such that root (or anyone else with CAP_DAC_OVERRIDE) is rejected.
- ajax
On Nov 2, 2015 7:05 AM, "Adam Jackson" ajax@redhat.com wrote:
On Fri, 2015-10-30 at 14:58 -0700, Andrew Lutomirski wrote:
On Fri, Oct 30, 2015 at 2:48 PM, Adam Jackson ajax@redhat.com wrote:
Anyone running any X (or wayland) application as root in their desktop session is completely bonkers and deserves every consequence of their poor decision.
OK, I'll bite. Why is it bonkers?
It's certainly the case that *gnome* might do something ridiculous if you 'sudo gedit' something, but 'sudo emacs' really ought to be equally acceptable regardless of whether you're using the terminal or X frontend.
Same reason you probably don't want to run your irc client as root: you're trusting the server to be well-behaved, through code that isn't expecting to need to do input validation. Consider this class of security bug:
http://www.x.org/wiki/Development/Security/Advisory-2013-05-23/
Also, at least under X, you're trusting _every other app in the session_ to politely ignore the privileged client. There's nothing to stop another client from blitting a deceptive image into the privileged window, or from creating input-only children of the privileged window and stealing its keystrokes (and forwarding them on to the privileged app however it sees fit, which might not be unmodified).
You have the same problem with root-equivalent polkit rights.
This is all somewhat hypothetical, granted. Certainly one can construct scenarios where it'd be safe enough. Probably there's selinux policy for X that could fix this kind of abuse, and wayland has a much smaller surface for this class of bug to sneak through.
We're talking about Wayland, though.
But, why take the risk exposure, when you could simply not?
ISTM the straightforward solution to all of this would be for Wayland to allow a connection from anyone who can connect to the socket. Then just set permissions on the socket accordingly.
Unless I'm missing something, there's no way to set permissions on a unix socket such that root (or anyone else with CAP_DAC_OVERRIDE) is rejected.
Root can connect one way or another and you can't do anything to prevent it. The socket DAC/ACL approach lets users set their own policy (e.g. Android-like things where maybe a gid is the right thing to check), and while discouraging root GUI may make sense, actively trying to prevent it seems both user-hostile and futile.
--Andy
- ajax
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 11/02/2015 03:05 PM, Adam Jackson wrote:
But, why take the risk exposure, when you could simply not?
How else would I edit root-owned files? I don't get it. I mean, I guess I could run an editor in a text window, but I don't want to do that.
And I have no idea how to run things like virt-manager without root.
And finally, it's *my computer*, dammit.
Andrew.
Hi,
2015-11-17 19:30 GMT+02:00 Andrew Haley aph@redhat.com:
And I have no idea how to run things like virt-manager without root.
My impression is that by default in fedora, virt-manager runs as non-root. I guess it might ask for the root password in order to manage the libvirtd that runs as privileged mode, but even in that case the user interface would run as your normal user.
My system has been set up to allow my user to manage VMs in the system-wide libvirtd instance by adding this content to a file named /etc/polkit-1/rules.d/20-libvirt-polkit.rules:
polkit.addRule(function(action, subject) { if (action.id == "org.libvirt.unix.manage") { if (subject.user == "muep") { return polkit.Result.YES; } } });
Of course this does not necessarily let you avoid all cases where you'd run an X11 application as root. But virt-manager seems to be written with the intent that it does not require to be run as root.
- Joonas
On 11/17/2015 05:55 PM, Joonas Sarajärvi wrote:
My impression is that by default in fedora, virt-manager runs as non-root. I guess it might ask for the root password in order to manage the libvirtd that runs as privileged mode, but even in that case the user interface would run as your normal user.
Sure, but even that is a UI regression: applications which ask for the root password discourage long root passwords and train people to type the root password whenever it's asked for. I should not even need to know the root password.
Andrew.
On 17/11/15 18:11, Andrew Haley wrote:
On 11/17/2015 05:55 PM, Joonas Sarajärvi wrote:
My impression is that by default in fedora, virt-manager runs as non-root. I guess it might ask for the root password in order to manage the libvirtd that runs as privileged mode, but even in that case the user interface would run as your normal user.
Sure, but even that is a UI regression: applications which ask for the root password discourage long root passwords and train people to type the root password whenever it's asked for. I should not even need to know the root password.
Well you'll be pleased to know then that virt-manager doesn't normally ask for the root password. If you're in the libvirt group then I don't think it will ask at all, otherwise if you're an administrative user then it will ask for your password.
If you weren't an admin user then it might ask for the root password but I don't think I've ever tried that. It does whatever polkit does for auth_admin basically.
Certainly there is no good reason to run virt-manager as root.
Tom
On 11/17/2015 06:25 PM, Tom Hughes wrote:
On 17/11/15 18:11, Andrew Haley wrote:
On 11/17/2015 05:55 PM, Joonas Sarajärvi wrote:
My impression is that by default in fedora, virt-manager runs as non-root. I guess it might ask for the root password in order to manage the libvirtd that runs as privileged mode, but even in that case the user interface would run as your normal user.
Sure, but even that is a UI regression: applications which ask for the root password discourage long root passwords and train people to type the root password whenever it's asked for. I should not even need to know the root password.
Well you'll be pleased to know then that virt-manager doesn't normally ask for the root password. If you're in the libvirt group then I don't think it will ask at all, otherwise if you're an administrative user then it will ask for your password.
OK, fair enough. That must be more recent than the host system I use.
Andrew.
On Tue, 2015-11-17 at 17:30 +0000, Andrew Haley wrote:
On 11/02/2015 03:05 PM, Adam Jackson wrote:
But, why take the risk exposure, when you could simply not?
How else would I edit root-owned files? I don't get it. I mean, I guess I could run an editor in a text window, but I don't want to do that.
That's kind of a non sequitur. To a first order, there are zero root- owned files you need to edit routinely. And I feel pretty comfortable calling any counterexamples bugs that need fixing.
And finally, it's *my computer*, dammit.
In the threat model being described, no, it is not, there's another agent on the system subverting your use of it.
You are of course free to disregard that risk, or measure it in the event and conclude it's safe enough, and in many cases it will in fact be safe. Great, fine, that's a conclusion a consumer can come to. But in the Fedora context we are the producer, not the consumer. Developing an operating system means considering what is best in the general case, and in the general case, if using the system requires a known-dangerous configuration, we've done our job poorly.
Phrased another way: no, it's not *your computer* we're talking about here. The computer in question rightfully belongs to someone else; we are here discussing how to be responsible for the code they allow us to run on it.
- ajax
On Wed, Nov 18, 2015 at 10:49 AM, Adam Jackson ajax@redhat.com wrote:
On Tue, 2015-11-17 at 17:30 +0000, Andrew Haley wrote:
On 11/02/2015 03:05 PM, Adam Jackson wrote:
But, why take the risk exposure, when you could simply not?
How else would I edit root-owned files? I don't get it. I mean, I guess I could run an editor in a text window, but I don't want to do that.
That's kind of a non sequitur. To a first order, there are zero root- owned files you need to edit routinely. And I feel pretty comfortable calling any counterexamples bugs that need fixing.
And finally, it's *my computer*, dammit.
In the threat model being described, no, it is not, there's another agent on the system subverting your use of it.
You are of course free to disregard that risk, or measure it in the event and conclude it's safe enough, and in many cases it will in fact be safe. Great, fine, that's a conclusion a consumer can come to. But in the Fedora context we are the producer, not the consumer. Developing an operating system means considering what is best in the general case, and in the general case, if using the system requires a known-dangerous configuration, we've done our job poorly.
Phrased another way: no, it's not *your computer* we're talking about here. The computer in question rightfully belongs to someone else; we are here discussing how to be responsible for the code they allow us to run on it.
I don't understand. If a user who has the right to act as root asks to authorize a program to run as root on their behalf, we should grant that request. And, once we grant it, we shouldn't be passive-aggressive and say "sure you can run it, but no graphics for you!".
Sure, if we want to block attacks in which an untrusted non-root program subverts the root program, then great! But we should really start by stopping attacks in which an untrusted non-root program runs sudo itself, edits .bashrc to redirect sudo to something malicious, subverts the (non-root!) terminal in which the user types sudo, etc
IOW, we're solving only one tiny special case of a broad problem, and it's more annoying than helpful.
--Andy
On Wed, 2015-11-18 at 11:53 -0800, Andrew Lutomirski wrote:
I don't understand. If a user who has the right to act as root asks to authorize a program to run as root on their behalf, we should grant that request. And, once we grant it, we shouldn't be passive-aggressive and say "sure you can run it, but no graphics for you!".
The point is, if things in Fedora require "run this bit of GUI as root" in order to function, we've done a poor job. That people have bad habits already is not sufficient justification to encourage them to have more.
To the bug in question: probably we should make it so 'sudo gedit' does work, but I'd still strongly discourage anyone from actually doing so.
- ajax
On Wed, 2015-11-18 at 15:09 -0500, Adam Jackson wrote:
On Wed, 2015-11-18 at 11:53 -0800, Andrew Lutomirski wrote:
I don't understand. If a user who has the right to act as root asks to authorize a program to run as root on their behalf, we should grant that request. And, once we grant it, we shouldn't be passive-aggressive and say "sure you can run it, but no graphics for you!".
The point is, if things in Fedora require "run this bit of GUI as root" in order to function, we've done a poor job. That people have bad habits already is not sufficient justification to encourage them to have more.
To the bug in question: probably we should make it so 'sudo gedit' does work, but I'd still strongly discourage anyone from actually doing so.
ISTR seeing some work lately in gvfs or gio or something which would allow GNOME-y things to acquire necessary perms for changes to files via PolicyKit when necessary.
I've always thought this would be an entirely reasonable feature. There's no inherent security advantage in making people run a console editor as root instead of using their preferred graphical editor, if the graphical editor can use an appropriately restricted permission granting mechanism to do the job. I've certainly had times where I'd quite have liked to edit a system file with gedit rather than nano or vi.
On Wed, Nov 18, 2015 at 12:24 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2015-11-18 at 15:09 -0500, Adam Jackson wrote:
On Wed, 2015-11-18 at 11:53 -0800, Andrew Lutomirski wrote:
I don't understand. If a user who has the right to act as root asks to authorize a program to run as root on their behalf, we should grant that request. And, once we grant it, we shouldn't be passive-aggressive and say "sure you can run it, but no graphics for you!".
The point is, if things in Fedora require "run this bit of GUI as root" in order to function, we've done a poor job. That people have bad habits already is not sufficient justification to encourage them to have more.
To the bug in question: probably we should make it so 'sudo gedit' does work, but I'd still strongly discourage anyone from actually doing so.
ISTR seeing some work lately in gvfs or gio or something which would allow GNOME-y things to acquire necessary perms for changes to files via PolicyKit when necessary.
I've always thought this would be an entirely reasonable feature. There's no inherent security advantage in making people run a console editor as root instead of using their preferred graphical editor, if the graphical editor can use an appropriately restricted permission granting mechanism to do the job. I've certainly had times where I'd quite have liked to edit a system file with gedit rather than nano or vi
If something like Capsicum ever lands, this becomes straightforward.
--Andy
2015-11-18 21:24 GMT+01:00 Adam Williamson adamwill@fedoraproject.org:
On Wed, 2015-11-18 at 15:09 -0500, Adam Jackson wrote:
On Wed, 2015-11-18 at 11:53 -0800, Andrew Lutomirski wrote:
I don't understand. If a user who has the right to act as root asks to authorize a program to run as root on their behalf, we should grant that request. And, once we grant it, we shouldn't be passive-aggressive and say "sure you can run it, but no graphics for you!".
The point is, if things in Fedora require "run this bit of GUI as root" in order to function, we've done a poor job. That people have bad habits already is not sufficient justification to encourage them to have more.
To the bug in question: probably we should make it so 'sudo gedit' does work, but I'd still strongly discourage anyone from actually doing so.
ISTR seeing some work lately in gvfs or gio or something which would allow GNOME-y things to acquire necessary perms for changes to files via PolicyKit when necessary.
I've always thought this would be an entirely reasonable feature. There's no inherent security advantage in making people run a console editor as root instead of using their preferred graphical editor, if the graphical editor can use an appropriately restricted permission granting mechanism to do the job. I've certainly had times where I'd quite have liked to edit a system file with gedit rather than nano or vi. --
I find it quite hilarious that liveusb-creator wouldn't even start for me the last time I tried it on F23. You can have the most secure system in the world but if you can't do what you want to do, what is the point.
And there is quite a big leap to be able to use the command line tools, I really do not think most normal users would be able to do that.
/Andreas
Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 18 November 2015 at 20:24, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2015-11-18 at 15:09 -0500, Adam Jackson wrote:
On Wed, 2015-11-18 at 11:53 -0800, Andrew Lutomirski wrote:
I don't understand. If a user who has the right to act as root asks to authorize a program to run as root on their behalf, we should grant that request. And, once we grant it, we shouldn't be passive-aggressive and say "sure you can run it, but no graphics for you!".
The point is, if things in Fedora require "run this bit of GUI as root" in order to function, we've done a poor job. That people have bad habits already is not sufficient justification to encourage them to have more.
To the bug in question: probably we should make it so 'sudo gedit' does work, but I'd still strongly discourage anyone from actually doing so.
ISTR seeing some work lately in gvfs or gio or something which would allow GNOME-y things to acquire necessary perms for changes to files via PolicyKit when necessary.
I've always thought this would be an entirely reasonable feature. There's no inherent security advantage in making people run a console editor as root instead of using their preferred graphical editor, if the graphical editor can use an appropriately restricted permission granting mechanism to do the job. I've certainly had times where I'd quite have liked to edit a system file with gedit rather than nano or vi.
That's really what's needed, just a pity that all the vfs systems seem to be tied to desktops.
On 18 November 2015 at 20:09, Adam Jackson ajax@redhat.com wrote:
On Wed, 2015-11-18 at 11:53 -0800, Andrew Lutomirski wrote:
I don't understand. If a user who has the right to act as root asks to authorize a program to run as root on their behalf, we should grant that request. And, once we grant it, we shouldn't be passive-aggressive and say "sure you can run it, but no graphics for you!".
The point is, if things in Fedora require "run this bit of GUI as root" in order to function, we've done a poor job. That people have bad habits already is not sufficient justification to encourage them to have more.
To the bug in question: probably we should make it so 'sudo gedit' does work, but I'd still strongly discourage anyone from actually doing so.
Not really getting this. For any configuration task where you replace editing a root owned text file with access through some authorised gui, that gui is still vulnerable. It may have theoretically reduced risks (assuming its permission to alter things is suitably locked down, not sure how well that is down generally), but it still has them and potential vulnerabilities. Versus being able to use a text editor, which is necessary for people using customised systems even in the hypothetical world where everything provided by fedora provides a perfect tool for configuring it. My conclusion would be better security and controls for gui tools that need general access to root owned resources.
On Wed, 2015-11-18 at 21:45 +0000, Ian Malone wrote:
Not really getting this. For any configuration task where you replace editing a root owned text file with access through some authorised gui, that gui is still vulnerable.
That gui's code, unlike emacs, doesn't allow you to write arbitrary data to arbitrary files. I can feed arbitrary input events to an emacs window and have it modify any file the process could modify. It's a lot harder to get, say, virt-manager to write arbitrary data to arbitrary places.
- ajax
On 19 November 2015 at 15:31, Adam Jackson ajax@redhat.com wrote:
On Wed, 2015-11-18 at 21:45 +0000, Ian Malone wrote:
Not really getting this. For any configuration task where you replace editing a root owned text file with access through some authorised gui, that gui is still vulnerable.
That gui's code, unlike emacs, doesn't allow you to write arbitrary data to arbitrary files. I can feed arbitrary input events to an emacs window and have it modify any file the process could modify. It's a lot harder to get, say, virt-manager to write arbitrary data to arbitrary places.
Harder, but you still have the permissions that the application has, whatever route it may be using to modify those files. Emacs (for example) while you are using it does not just access arbitrary files under normal operation unless instructed, an attacker needs to subvert it somehow. There are differences of course, but if an application has rights that allow it access to things then someone taking control of it can access them too.
Am 18.11.2015 um 21:09 schrieb Adam Jackson:
On Wed, 2015-11-18 at 11:53 -0800, Andrew Lutomirski wrote:
I don't understand. If a user who has the right to act as root asks to authorize a program to run as root on their behalf, we should grant that request. And, once we grant it, we shouldn't be passive-aggressive and say "sure you can run it, but no graphics for you!".
The point is, if things in Fedora require "run this bit of GUI as root" in order to function, we've done a poor job
nonsense
"code-editor" needs to run as root to edit *correctly* root-owned config files and yes i am magnitues faster open a dozen config files in a GUI editor with tabs then with nano which is fine for (only small) single files
maybe you only have dedicated configuration tools in your mind, i prefer to install *nothing* which is not strongly needed on machines and the way i do things is backed by running 8 years a dozen Fedora servers never reinstalled from scratch
On Wed, Nov 18, 2015 at 03:09:34PM -0500, Adam Jackson wrote:
To the bug in question: probably we should make it so 'sudo gedit' does work, but I'd still strongly discourage anyone from actually doing so.
Actually, there's a better way. The authors of sudo already considered this. Set "VISUAL" to gedit, and use `sudo -e`. That invokes the editor as non-root on a temporary file, and copies that temp file into place when done.
On 19 November 2015 at 03:18, Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Nov 18, 2015 at 03:09:34PM -0500, Adam Jackson wrote:
To the bug in question: probably we should make it so 'sudo gedit' does work, but I'd still strongly discourage anyone from actually doing so.
Actually, there's a better way. The authors of sudo already considered this. Set "VISUAL" to gedit, and use `sudo -e`. That invokes the editor as non-root on a temporary file, and copies that temp file into place when done.
Completely forgot about that one! I remember using crontab's similar function was the first time I encountered vi, that was lots of fun...
Am 18.11.2015 um 19:49 schrieb Adam Jackson:
On Tue, 2015-11-17 at 17:30 +0000, Andrew Haley wrote:
On 11/02/2015 03:05 PM, Adam Jackson wrote:
But, why take the risk exposure, when you could simply not?
How else would I edit root-owned files? I don't get it. I mean, I guess I could run an editor in a text window, but I don't want to do that.
That's kind of a non sequitur. To a first order, there are zero root- owned files you need to edit routinely. And I feel pretty comfortable calling any counterexamples bugs that need fixing
hopefully all configuration files on your system are root-owned and "routinely" is not black and white because it depens on your use-cases
as serveradmin you *routinely* edit root-owned files and *yes* i pull them from 35 machines to a dedicated admin server and open them all together in a GUI editor with tabs to make changes i want to have on all servers while the file itself is machine specific
why?
because it's much faster than login to each and every machine when i can pull them with a script, edit them centralized and push them back followed by a "distribute-command 'systemctl condrestart affected-service'" and it saves a ton of overhead for configuration management tools with their own security issues all the time
On 18 November 2015 at 23:38, Reindl Harald h.reindl@thelounge.net wrote:
Am 18.11.2015 um 19:49 schrieb Adam Jackson:
On Tue, 2015-11-17 at 17:30 +0000, Andrew Haley wrote:
On 11/02/2015 03:05 PM, Adam Jackson wrote:
But, why take the risk exposure, when you could simply not?
How else would I edit root-owned files? I don't get it. I mean, I guess I could run an editor in a text window, but I don't want to do that.
That's kind of a non sequitur. To a first order, there are zero root- owned files you need to edit routinely. And I feel pretty comfortable calling any counterexamples bugs that need fixing
hopefully all configuration files on your system are root-owned and "routinely" is not black and white because it depens on your use-cases
as serveradmin you *routinely* edit root-owned files and *yes* i pull them from 35 machines to a dedicated admin server and open them all together in a GUI editor with tabs to make changes i want to have on all servers while the file itself is machine specific
why?
because it's much faster than login to each and every machine when i can pull them with a script, edit them centralized and push them back followed by a "distribute-command 'systemctl condrestart affected-service'" and it saves a ton of overhead for configuration management tools with their own security issues all the time
Technically if doing this then the editing only needs to be done as the owner of the copies and it's the process of copying them back that requires root permission on the target machine.
Am 19.11.2015 um 00:57 schrieb Ian Malone:
On 18 November 2015 at 23:38, Reindl Harald h.reindl@thelounge.net wrote:
Am 18.11.2015 um 19:49 schrieb Adam Jackson:
On Tue, 2015-11-17 at 17:30 +0000, Andrew Haley wrote:
On 11/02/2015 03:05 PM, Adam Jackson wrote:
But, why take the risk exposure, when you could simply not?
How else would I edit root-owned files? I don't get it. I mean, I guess I could run an editor in a text window, but I don't want to do that.
That's kind of a non sequitur. To a first order, there are zero root- owned files you need to edit routinely. And I feel pretty comfortable calling any counterexamples bugs that need fixing
hopefully all configuration files on your system are root-owned and "routinely" is not black and white because it depens on your use-cases
as serveradmin you *routinely* edit root-owned files and *yes* i pull them from 35 machines to a dedicated admin server and open them all together in a GUI editor with tabs to make changes i want to have on all servers while the file itself is machine specific
why?
because it's much faster than login to each and every machine when i can pull them with a script, edit them centralized and push them back followed by a "distribute-command 'systemctl condrestart affected-service'" and it saves a ton of overhead for configuration management tools with their own security issues all the time
Technically if doing this then the editing only needs to be done as the owner of the copies and it's the process of copying them back that requires root permission on the target machine
technically i prefer using my "rsync.sh" for any file operations
just to be sure all permissions, extended attributes and so on are correct, /etc/passwd and /etc/groups have the same IDs everywhere
[root@buildserver:~]$ cat /usr/local/bin/rsync.sh #!/usr/bin/bash
# -z compress # -t timestamps # -P progress # -r recursive # -l links # -H hard-links # -p permissions # -o owner # -g group # -E executability # -A acls # -X xtended attributes
# Sicherstellen dass Source UND Target uebergeben wurden if [ "$1" == "" ] || [ "$2" == "" ] || [ "$1" == "$2" ]; then echo "USAGE: rsync.sh <source> <target> [bwlimit]" exit fi
# Standard-Parameter RSYNC_PARAMS="--no-motd --force --delete-after --devices --specials -tPrlpogEAX"
# Wenn in einem der beiden Paramneter ein @ vorkommt Komprimierung einschalten # Ansonsten handelt es sich um zwei lokale Ordner und rsync wuerde die # Daten ohne Sinn komprimieren if [ `grep '@' <<< "$1"` ] || [ `grep '@' <<< "$2"` ]; then RSYNC_PARAMS="--compress --sockopts=SO_SNDBUF=32768,SO_RCVBUF=32768 $RSYNC_PARAMS" fi
if [ "$3" != "" ]; then RSYNC_PARAMS="--bwlimit=$3 $RSYNC_PARAMS" fi
# Eigentliches Kommando ausfuehren nice -n 19 rsync $RSYNC_PARAMS --rsync-path='nice -n 19 rsync' "$1" "$2"
Am 19.11.2015 um 01:00 schrieb Reindl Harald:
Am 19.11.2015 um 00:57 schrieb Ian Malone:
On 18 November 2015 at 23:38, Reindl Harald h.reindl@thelounge.net wrote:
Am 18.11.2015 um 19:49 schrieb Adam Jackson:
That's kind of a non sequitur. To a first order, there are zero root- owned files you need to edit routinely. And I feel pretty comfortable calling any counterexamples bugs that need fixing
hopefully all configuration files on your system are root-owned and "routinely" is not black and white because it depens on your use-cases
as serveradmin you *routinely* edit root-owned files and *yes* i pull them from 35 machines to a dedicated admin server and open them all together in a GUI editor with tabs to make changes i want to have on all servers while the file itself is machine specific
why?
because it's much faster than login to each and every machine when i can pull them with a script, edit them centralized and push them back followed by a "distribute-command 'systemctl condrestart affected-service'" and it saves a ton of overhead for configuration management tools with their own security issues all the time
Technically if doing this then the editing only needs to be done as the owner of the copies and it's the process of copying them back that requires root permission on the target machine
technically i prefer using my "rsync.sh" for any file operations
just to be sure all permissions, extended attributes and so on are correct, /etc/passwd and /etc/groups have the same IDs everywhere
that said - i see no valid reason to have sensible configurations of the whole infrastructure readable by non-root on any machine and on the same machine etckeeper is running on the folders with the centralized configs
On 11/18/2015 06:49 PM, Adam Jackson wrote:
On Tue, 2015-11-17 at 17:30 +0000, Andrew Haley wrote:
On 11/02/2015 03:05 PM, Adam Jackson wrote:
But, why take the risk exposure, when you could simply not?
How else would I edit root-owned files? I don't get it. I mean, I guess I could run an editor in a text window, but I don't want to do that.
That's kind of a non sequitur. To a first order, there are zero root- owned files you need to edit routinely. And I feel pretty comfortable calling any counterexamples bugs that need fixing.
I don't quite understand what you're saying here. There are plenty of config files in a UNIX-like system, and they are supposed to be edited. And if you think otherwise, then I think you are wrong.
And finally, it's *my computer*, dammit.
In the threat model being described, no, it is not, there's another agent on the system subverting your use of it.
You are of course free to disregard that risk, or measure it in the event and conclude it's safe enough, and in many cases it will in fact be safe.
Well, good, as long as I can still do that, I will be happy.
Great, fine, that's a conclusion a consumer can come to. But in the Fedora context we are the producer, not the consumer. Developing an operating system means considering what is best in the general case, and in the general case, if using the system requires a known-dangerous configuration, we've done our job poorly.
Sure.
Phrased another way: no, it's not *your computer* we're talking about here. The computer in question rightfully belongs to someone else; we are here discussing how to be responsible for the code they allow us to run on it.
That is a reasonable point for view. However, the point of Free Software is freedom; and the ability to shoot oneself in the foot is part of that freedom. One of the greatest advantage of Free Software from my point of view is that people can choose. And I know that I am not alone in chooing to use (and to write) Free Software for that reason: freedom is not just about strict licence compliance.
Five years or so ago I publicly defended Wayland because I was assured that things would continue to work after the transition. Being able to edit files with emacs is an essential part of that "continuing to work."
Andrew.
On Thursday 19 Nov 2015 12:48:50 Andrew Haley wrote:
On 11/18/2015 06:49 PM, Adam Jackson wrote:
<snip>
Phrased another way: no, it's not *your computer* we're talking about here. The computer in question rightfully belongs to someone else; we are here discussing how to be responsible for the code they allow us to run on it.
That is a reasonable point for view. However, the point of Free Software is freedom; and the ability to shoot oneself in the foot is part of that freedom. One of the greatest advantage of Free Software from my point of view is that people can choose. And I know that I am not alone in chooing to use (and to write) Free Software for that reason: freedom is not just about strict licence compliance.
Five years or so ago I publicly defended Wayland because I was assured that things would continue to work after the transition. Being able to edit files with emacs is an essential part of that "continuing to work."
I don't see how a lack of access to the GUI when running as root will prevent Emacs from editing root-owned files.
TRAMP (if you wish to stay inside emacs) and "sudo -e" (if you'd rather work outside emacs) both provide mechanisms (that I use today under X11) for emacs to edit root-only files while the vast bulk of emacs runs as my user ID.
Put another way: "sudo emacs /etc/hosts" will break under Wayland. "sudo -e /etc/hosts", "emacsclient /sudo::/etc/hosts" and "emacs /sudo::/etc/hosts" will all still work as they do today, as will "emacs --eval (find-file /sudo::/etc/hosts)"
On 11/19/2015 12:57 PM, Simon Farnsworth wrote:
On Thursday 19 Nov 2015 12:48:50 Andrew Haley wrote:
On 11/18/2015 06:49 PM, Adam Jackson wrote:
<snip> >> Phrased another way: no, it's not *your computer* we're talking about >> here. The computer in question rightfully belongs to someone else; we >> are here discussing how to be responsible for the code they allow us to >> run on it. > > That is a reasonable point for view. However, the point of Free > Software is freedom; and the ability to shoot oneself in the foot is > part of that freedom. One of the greatest advantage of Free Software > from my point of view is that people can choose. And I know that I am > not alone in chooing to use (and to write) Free Software for that > reason: freedom is not just about strict licence compliance. > > Five years or so ago I publicly defended Wayland because I was assured > that things would continue to work after the transition. Being able > to edit files with emacs is an essential part of that "continuing to > work." > I don't see how a lack of access to the GUI when running as root will prevent Emacs from editing root-owned files.
TRAMP (if you wish to stay inside emacs) and "sudo -e" (if you'd rather work outside emacs) both provide mechanisms (that I use today under X11) for emacs to edit root-only files while the vast bulk of emacs runs as my user ID.
Put another way: "sudo emacs /etc/hosts" will break under Wayland.
That's bad.
"sudo -e /etc/hosts", "emacsclient /sudo::/etc/hosts" and "emacs /sudo::/etc/hosts" will all still work as they do today, as will "emacs --eval (find-file /sudo::/etc/hosts)"
I'm complaining about people breaking stuff that Just Works and has worked for *decades*. And they're doing it "because security" or "because I don't do it that way." I see that it's possible to get around the problem in some cases, either by some elaborate shell scripting or (in this case) a special recipe for editing files. But that's really not the point.
Andrew.
On Thursday 19 Nov 2015 13:56:32 Andrew Haley wrote:
On 11/19/2015 01:03 PM, Simon Farnsworth wrote:
"sudo -e /etc/hosts", will ... still work
Hold on, I think I may not be understanding something. If "sudo -e /etc/hosts" will still work, why won't "sudo emacs /etc/hosts" ?
Andrew.
"sudo -e" creates a temporary file owned by you containing the file contents, then has your editor access it; when your editor exits, the temporary file's contents replace the original file.
"sudo emacs" runs emacs as a new user; AIUI, in the current Wayland security model, emacs running as another user cannot access the Wayland server, because it's not the same user.
Am 19.11.2015 um 13:57 schrieb Simon Farnsworth:
Put another way: "sudo emacs /etc/hosts" will break under Wayland
than wayland is currently not useable and ready to replace X11
as user i don't care if the application needs to be fixed or wayland lacks whatever but given that there are a bazillion more applications compared to X11 versus wayland it's pretty clear where to start
"sudo -e /etc/hosts", "emacsclient /sudo::/etc/hosts" and "emacs /sudo::/etc/hosts" will all still work as they do today, as will "emacs --eval (find-file /sudo::/etc/hosts)"
horrible workarounds
On 11/19/2015 08:31 AM, Reindl Harald wrote:
Am 19.11.2015 um 13:57 schrieb Simon Farnsworth:
Put another way: "sudo emacs /etc/hosts" will break under Wayland
than wayland is currently not useable and ready to replace X11
as user i don't care if the application needs to be fixed or wayland lacks whatever but given that there are a bazillion more applications compared to X11 versus wayland it's pretty clear where to start
I think you're arguing that the multitude of X applications does not have fine-grained access controls, so they have to be given overall root privilege---but this is the old OS security model that we've been moving away from for years.
Adam's argument is that we should switch to fine-grained control, just like we switched to fine-grained control with SELinux. We have to find out why the GUI app legitimately requires elevated access and give it just that access. Those 'horrible hacks' that you decry do exactly that: isolate the root-level file access and arrange for it, while running the entire GUI at non-privileged level.
This could be done in other ways too, e.g. by wrapping the GUI with a script that adds user to root file's ACL, edits it and takes ACL away. Your rsync mechanism is actually a perfect example: root access to files on your target systems should be decoupled from root access on your admin system.
On 10/30/2015 10:48 PM, Adam Jackson wrote:
Anyone running any X (or wayland) application as root in their desktop session is completely bonkers and deserves every consequence of their poor decision.
Doesn't most proprietary software come with GUI installers?
Florian
Am 17.11.2015 um 18:56 schrieb Florian Weimer:
On 10/30/2015 10:48 PM, Adam Jackson wrote:
Anyone running any X (or wayland) application as root in their desktop session is completely bonkers and deserves every consequence of their poor decision.
Doesn't most proprietary software come with GUI installers?
at least VMware and ZendStudio does - if i don't trust the vendor starting the installer local or remote with x-forwarding is the smallest of my problems!
2015-11-17 19:56 GMT+02:00 Florian Weimer fweimer@redhat.com:
Doesn't most proprietary software come with GUI installers?
No idea if "most" are, but at least I have seen many proprietary programs that do not require a GUI in installation.
Also in many cases where there is a GUI installer, it works just fine as a normal user and running it without root privileges could be considered somewhat safer. You would at least know if it tries to clobber your config files under /etc or your libraries and programs under /usr.
- Joonas
Am 17.11.2015 um 19:04 schrieb Joonas Sarajärvi:
2015-11-17 19:56 GMT+02:00 Florian Weimer fweimer@redhat.com:
Doesn't most proprietary software come with GUI installers?
No idea if "most" are, but at least I have seen many proprietary programs that do not require a GUI in installation.
Also in many cases where there is a GUI installer, it works just fine as a normal user and running it without root privileges could be considered somewhat safer. You would at least know if it tries to clobber your config files under /etc or your libraries and programs under /usr
depends on what the application is supposed to do and if you want a global setup instead only in the userhome for every user
installing in your userhome has another disadvantage: you are running all day long a application writeable by your user and so there is a risk that another arbitary process modifies it
installing the application as root is a one time risk but after that the binaries are protected against modifying
2015-11-17 20:07 GMT+02:00 Reindl Harald h.reindl@thelounge.net:
depends on what the application is supposed to do and if you want a global setup instead only in the userhome for every user
installing in your userhome has another disadvantage: you are running all day long a application writeable by your user and so there is a risk that another arbitary process modifies it
installing the application as root is a one time risk but after that the binaries are protected against modifying
Sure, there are also installers which really require root privileges to function at all.
The writability of installed files by your normal user is easy to address by e.g. this: - make directory /opt/foo owned by alice - have alice run the installer of foo, installing to /opt/foo - chown -R root:root /opt/foo - adjust system-wide default PATH to include /opt/foo/bin
Of course if you trust the installer to be well written and benign, you might just as well not bother. But this is a fairly easy option.
- Joonas
-
Adam Jackson -
Adam Williamson -
Andreas Tunek -
Andrew Haley -
Andrew Lutomirski -
Bastien Nocera -
Florian Weimer -
Ian Malone -
John Dulaney -
Joonas Sarajärvi -
Kamil Paral -
Matthew Miller -
Przemek Klosowski -
Ray Strode -
Reindl Harald -
Simon Farnsworth -
Tom Hughes