Re: On running gui applications as root

[Kamil Paral]

> 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?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: On running gui applications as root

[Andrew Haley]

On 11/18/2015 06:49 PM, Adam Jackson wrote:
> On Tue, 2015-11-17 at 17:30 +, 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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Ian Malone]

On 19 November 2015 at 03:18, Matthew Miller  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...

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Ian Malone]

On 19 November 2015 at 15:31, Adam Jackson  wrote:
> On Wed, 2015-11-18 at 21:45 +, 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.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Adam Jackson]

On Wed, 2015-11-18 at 21:45 +, 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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Andrew Haley]

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:
>  
>>> 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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Przemek Klosowski]

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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Andrew Haley]

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.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Simon Farnsworth]

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.

-- 
Simon Farnsworth
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Simon Farnsworth]

On Thursday 19 Nov 2015 12:48:50 Andrew Haley wrote:
> On 11/18/2015 06:49 PM, Adam Jackson wrote:
 
> > 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)"

-- 
Simon Farnsworth
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Reindl Harald]

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



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Adam Jackson]

On Tue, 2015-11-17 at 17:30 +, 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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[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. 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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Andrew Lutomirski]

On Wed, Nov 18, 2015 at 10:49 AM, Adam Jackson  wrote:
> On Tue, 2015-11-17 at 17:30 +, 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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Adam Williamson]

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.
-- 
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

Re: On running gui applications as root

[Andreas Tunek]

2015-11-18 21:24 GMT+01:00 Adam Williamson :
> 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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Andrew Lutomirski]

On Wed, Nov 18, 2015 at 12:24 PM, Adam Williamson
 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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Kamil Paral]

> 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.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Ian Malone]

On 18 November 2015 at 20:24, Adam Williamson
 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.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Reindl Harald]

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





signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Reindl Harald]

Am 18.11.2015 um 19:49 schrieb Adam Jackson:

On Tue, 2015-11-17 at 17:30 +, 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




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Ian Malone]

On 18 November 2015 at 23:38, Reindl Harald  wrote:
>
>
> Am 18.11.2015 um 19:49 schrieb Adam Jackson:
>>
>> On Tue, 2015-11-17 at 17:30 +, 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.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Ian Malone]

On 18 November 2015 at 20:09, 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.
>

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.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Reindl Harald]

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




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Reindl Harald]

Am 19.11.2015 um 00:57 schrieb Ian Malone:

On 18 November 2015 at 23:38, Reindl Harald  wrote:



Am 18.11.2015 um 19:49 schrieb Adam Jackson:


On Tue, 2015-11-17 at 17:30 +, 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   [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"



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Matthew Miller]

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.

-- 
Matthew Miller

Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Andrew Haley]

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.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Joonas Sarajärvi]

2015-11-17 20:07 GMT+02:00 Reindl Harald :
> 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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Tom Hughes]

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

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[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?

Florian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Joonas Sarajärvi]

Hi,

2015-11-17 19:30 GMT+02:00 Andrew Haley :
> 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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Joonas Sarajärvi]

2015-11-17 19:56 GMT+02:00 Florian Weimer :
> 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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Reindl Harald]

Am 17.11.2015 um 19:04 schrieb Joonas Sarajärvi:

2015-11-17 19:56 GMT+02:00 Florian Weimer :

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




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Reindl Harald]

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!




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Andrew Haley]

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.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Andrew Haley]

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.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Adam Jackson]

On Fri, 2015-10-30 at 14:58 -0700, Andrew Lutomirski wrote:
> On Fri, Oct 30, 2015 at 2: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.
> 
> 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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Andrew Lutomirski]

On Nov 2, 2015 7:05 AM, "Adam Jackson"  wrote:
>
> On Fri, 2015-10-30 at 14:58 -0700, Andrew Lutomirski wrote:
> > On Fri, Oct 30, 2015 at 2: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.
> >
> > 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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Ray Strode]

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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Andrew Lutomirski]

On Fri, Oct 30, 2015 at 2:48 PM, Adam Jackson  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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Adam Jackson]

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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: On running gui applications as root

[Bastien Nocera]

- 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
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct