Gentoo Forums :: View topic - polkit!? and gentoo gets a mention

polkit!? and gentoo gets a mention

View unanswered posts
View posts from last 24 hours

Goto page 1, 2, 3 Next

Gentoo Forums Forum Index

Gentoo Chat

View previous topic :: View next topic

Author

Message

josephg
l33t
l33t

Joined: 10 Jan 2016
Posts: 783
Location: usually offline

Posted: Wed Aug 02, 2017 10:21 pm Post subject: polkit!? and gentoo gets a mention

http://forum.manjaro.org/t/how-to-completely-remove-disable-policykit-its-useless-anyway/28487/2

manjaro/pwernub wrote:

Ahoy and thanks for reading.
I am looking for a way to completely get rid of policykit while keeping all the nice things that pretend they depend on it.
If you wonder why i consider it useless: try the following on an unprivileged console:
xinput list (note the id of your keyboard)
xinput test id_of_your_keyboard

then launch something that makes polkit ask you for your password and see every keystroke recorded on the console. Then wonder whoever came up with such placebo security.

_________________
"Growth for the sake of growth is the ideology of the cancer cell." Edward Abbey

duby2291
Guru
Guru

Joined: 17 Oct 2004
Posts: 583

Posted: Wed Aug 02, 2017 10:46 pm Post subject:

Yes, that is highly useful info. Thanks for posting it here.

asturm
Developer

Joined: 05 Apr 2007
Posts: 8935

Posted: Wed Aug 02, 2017 10:48 pm Post subject:

You're running X, and you are worrying about any additional bit to compromise input security?

Tony0945
Watchman

Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA

Posted: Wed Aug 02, 2017 11:20 pm Post subject:

asturm wrote:

You're running X, and you are worrying about any additional bit to compromise input security?

YES!

duby2291
Guru
Guru

Joined: 17 Oct 2004
Posts: 583

Posted: Thu Aug 03, 2017 12:20 am Post subject:

Tony0945 wrote:

asturm wrote:

You're running X, and you are worrying about any additional bit to compromise input security?

YES!

Yes Wayland is available, and yes it's largely working. But it still isn't quite perfect, and to be honest X still gives a better user experience for gamers. So yeah, X isn't exactly secure, but apparently polkit isn't either and that's good to know for sure.

berferd
Tux's lil' helper

Joined: 13 May 2004
Posts: 117

Posted: Thu Aug 03, 2017 12:24 am Post subject:

asturm wrote:

You're running X, and you are worrying about any additional bit to compromise input security?

Yes. X does something useful, unlike policykit.

Ant P.
Watchman

Joined: 18 Apr 2009
Posts: 6920

Posted: Thu Aug 03, 2017 12:44 am Post subject:

asturm wrote:

You're running X, and you are worrying about any additional bit to compromise input security?

Training users to enter their user/root password several times a day (for no good reason) is an idiotic practice regardless of your desire to inflict another flag day on your users. This is a basic lesson Microsoft figured out painfully a decade ago with Vista UAC, Freedesktop pushers need to drop the CADT crap and start fixing the mess they've badly copied from other OSes.

Yamakuzure
Advocate

Joined: 21 Jun 2006
Posts: 2284
Location: Adendorf, Germany

Posted: Thu Aug 03, 2017 11:15 am Post subject:

Woohoo! Hang on!

One note beforehand: I do not like PolKit, just the convenience it brings. But I am convinced, that this convenience could be achieved in a more secure, better designed, and easier to understand way. But until then...

It has been for ages that *nix'ers laughed about those silly windows users being logged in as "Administrators", when it was so easy for *nix'ers to be ordinary users and then using tools like sudo, gksu or kdesu for the maintenance stuff.

Then Microsoft eventually provided something similar. Well, similar in its effect, but far better in its users experience: Ordinary users can get a password prompt for maintenance stuff, and no longer need to run their every day work as "Administrator". And on top of that, Windows users suddenly could start programs with Administrator rights, just like *nix'ers where used to for aeons.

So PolKit is simply allowing to run programs without root privileges, and then ask for a password to do stuff that requires those privileges. Just like the Microsoft UAC does.

manjaro/pwernub wrote:

try the following on an unprivileged console:
xinput list (note the id of your keyboard)
xinput test id_of_your_keyboard

Since when does the classic keyboard sniffing does have anything to do with PolKit? This method works for everything.

Just test your keyboard ID and do an 'su' in another console, and xinput goes:

Code:

~ $ xinput test 16
key release 36
key press 39
key release 39
key press 30
key release 30
key press 36
key release 36
key press 11
key release 11

That manjaro post is just a hoax. One against PolKit in particular.
I'd even say that it is bullshit. Because the cause, why PolKit asks for the (then sniffed) password, is the need for root privileges, that would have otherwise been obtained by 'sudo'ing that program. And with the users password sniffed, you could 'su - <user>' them and 'sudo' yourself, so that's not better.
...actually, it is even worse, because said program is running with root privileges for it's entire life...
_________________
Important German:

"Aha" - German reaction to pretend that you are really interested while giving no f*ck.
"Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.

steveL
Watchman

Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

Posted: Thu Aug 03, 2017 12:50 pm Post subject:

Yamakuzure wrote:

One note beforehand: I do not like PolKit, just the convenience it brings. But I am convinced, that this convenience could be achieved in a more secure, better designed, and easier to understand way. But until then...

It has been for ages that *nix'ers laughed about those silly windows users being logged in as "Administrators", when it was so easy for *nix'ers to be ordinary users and then using tools like sudo, gksu or kdesu for the maintenance stuff.

Then Microsoft eventually provided something similar. Well, similar in its effect, but far better in its users experience:

That assertion is questionable, at best.

Quote:

Ordinary users can get a password prompt for maintenance stuff, and no longer need to run their every day work as "Administrator". And on top of that, Windows users suddenly could start programs with Administrator rights, just like *nix'ers where used to for aeons.

Those two seem to be the same thing.

Quote:

So PolKit is simply allowing to run programs without root privileges, and then ask for a password to do stuff that requires those privileges. Just like the Microsoft UAC does.

Yes, but M$ UAC is crap; that's the point others have been making.

And from where I'm sitting, reading the above, polkit is not providing anything we didn't already have.

Quote:

root privileges for its entire life...

Sound like polkit to me ;-) (The serious point being that it's overly complex, and has an embedded js interpreter, using a fast-moving and notorious engine: not what I want in a root process on my machine.)

Note I'm not disagreeing with you about keyboard sniffing (it occurred to me that it's hardly unique to any process, but I didn't try it, so kudos.)

Just about the utility of Polkit, and indeed the desirability of having users conditioned to click "ok" because they get so many "confirmation dialogs".
This is much worse nowadays, with the ubiquity of "smart" phones, and the constant need to give permissions to apps (with no choice about it.)

If you take away the "multiseat" delusion, is polkit still necessary? Even if it is, which I doubt, it needs to be redone from scratch, as you've said it needs to be reworked; preferably by not being done at all, and just using PAM sensibly.

josephg
l33t
l33t

Joined: 10 Jan 2016
Posts: 783
Location: usually offline

Posted: Thu Aug 03, 2017 1:43 pm Post subject:

Yamakuzure wrote:

Just test your keyboard ID and do an 'su' in another console, and xinput goes:

Code:

~ $ xinput test 16
key release 36
key press 39
key release 39
key press 30
key release 30
key press 36
key release 36
key press 11
key release 11

That manjaro post is just a hoax. One against PolKit in particular.

so i was curious and just did what you asked.

Code:

$ xinput test <keyboard id>

which logged all keys as you said.
but it logged nothing, when i changed console to tty2, logged in as another user and did all sorts of things including startx and logout.
i switched back to my x session on tty1, and it started logging again on keyboard activity.
ps: i don't use polkit.
_________________
"Growth for the sake of growth is the ideology of the cancer cell." Edward Abbey

R0b0t1
Apprentice

Joined: 05 Jun 2008
Posts: 264

Posted: Thu Aug 03, 2017 2:19 pm Post subject:

duby2291 wrote:

The real problem can't be solved unless you install a mandatory access control system, as I can simply use /proc files or system calls like ptrace to execute my code in the context of another running process. I don't need to receive key events to figure out your password.

Last edited by R0b0t1 on Thu Aug 03, 2017 6:43 pm; edited 1 time in total

duby2291
Guru
Guru

Joined: 17 Oct 2004
Posts: 583

Posted: Thu Aug 03, 2017 4:33 pm Post subject:

R0b0t1 wrote:

duby2291 wrote:

The real problem can't be solved unless you install a mandatory access control system, as I can simply use /proc files or systems calls like ptrace to execute my code in the context of another running process. I don't need to receive key events to figure out your password.

I never tried to say that X was secure. It definitely isn't, I agree. But the news here is that polkit isn't secure either, and that's still news worthy of knowing about. One flaw doesn't "unflaw" another one, they are still both flaws.

miket
Guru
Guru

Joined: 28 Apr 2007
Posts: 488
Location: Gainesville, FL, USA

Posted: Thu Aug 03, 2017 4:39 pm Post subject:

R0b0t1 wrote:

And even then, it's something not to trust. The thing is you are granting other people access to the same machine.

As far as Polkit/Consolekit goes, though, it seems to me not to be very easy to root out of our systems. The problem is that there are tons of packages that are hardwired to talk to Polkit, and patching all of these--and keeping up with the patches--would be a daunting task.

What I had in mind is a minimalistic replacement for Polkit that still listens on D-Bus (ugh!) and still gives yes/no answers to the likes of udisks, but does not use Javascript.

I shiver yet again when I think about Javascript. Yes, you can do cute stuff with it in the browser, but its extreme sloppiness WRT to things like variables' defaulting to global scope, nonintuitive type munging, and the fact that referencing a non-declared, non-initialized variable very often "works" without raising an obvious error, makes it quite unsuited for use in a system like Polkit. Maybe "PollutedKit" is a better name.

duby2291
Guru
Guru

Joined: 17 Oct 2004
Posts: 583

Posted: Thu Aug 03, 2017 4:45 pm Post subject:

miket wrote:

R0b0t1 wrote:

It's been my experience that minimilist "passthrough" type interfaces are much easier to maintain and over the longterm much more stable. Highly integrated "conglomerate" interfaces tend to be buggy and insecure due to layers of abstraction no human person can understand.

josephg
l33t
l33t

Joined: 10 Jan 2016
Posts: 783
Location: usually offline

Posted: Thu Aug 03, 2017 5:14 pm Post subject:

duby2291 wrote:

Highly integrated "conglomerate" interfaces tend to be buggy and insecure due to layers of abstraction no human person can understand.

What if... that was the (covert) design goal?
_________________
"Growth for the sake of growth is the ideology of the cancer cell." Edward Abbey

miket
Guru
Guru

Joined: 28 Apr 2007
Posts: 488
Location: Gainesville, FL, USA

Posted: Thu Aug 03, 2017 5:42 pm Post subject:

duby2291 wrote:

It is very true that each system needing service, say the mountable-drive code in the DE, could communicate directly with the drive-mounting service, what we have in the current DE's is very different. Have you ever walked through the KDE code to find all the places? I went through the Solid codebase to find where to patch the interfaces for power management and device mounting, but was still stymied because I couldn't figure out where else in the whole codebase (it wasn't in Solid) that KDE4 was talking to Polkit to identify the user and to get the initial idea of whether the user could shut down the machine or mount a drive. Then, once you've tamed KDE (now at version 5 under the name du jour, you have be ready to patch things every time a new release comes out. Now you have to do this for most of the other DE's.

I hate the incredible fan-in to Polkit for these decisions, but I'm looking for a practical way to avoid its excesses without having to modify everything that wants to talk to it.

Side note re. the services we could have in an ideal world: a lot has been written about how it is better to avoid SUID executables for things like mounting. On that line, others have said that capability attributes, the "new SUID", is a better approach. I don't argue for either one, actually. I still like the idea of daemons to do these things. The difference is that they listen on Unix sockets and not to D-Bus. A client process needing service would need to have the Unix permissions to open those sockets. No access, no service.

R0b0t1
Apprentice

Joined: 05 Jun 2008
Posts: 264

Posted: Thu Aug 03, 2017 6:40 pm Post subject:

duby2291 wrote:

Sorry, I was just trying to add to that by saying nothing can really be secure unless it makes major changes to the way the kernel isolates resources. I had a more in-depth post about this on the mailing list that I couldn't find to cite. Apparently people are wanting to implement a bunch of things in Wayland/X11 that will break useful programs but that won't actually solve the problem.

josephg wrote:

duby2291 wrote:

Highly integrated "conglomerate" interfaces tend to be buggy and insecure due to layers of abstraction no human person can understand.

What if... that was the (covert) design goal?

The suggestion that systemd is receiving such wide adoption due to actions of either the CIA or NSA shouldn't be too ridiculous, as there are documented instances of those agencies planting agents in trusted positions to intentionally offer bad advice.

Hu
Moderator

Joined: 06 Mar 2007
Posts: 21619

Posted: Fri Aug 04, 2017 1:27 am Post subject:

Much like the idea of a minimal PolKit-compatible replacement lets you avoid patching all PolKit clients, using file capabilities instead of suid programs lets you avoid patching every script (and user) accustomed to using those suid programs. Replace the program with a capability-based non-suid equivalent and callers can still use it to do its intended job(s) with no patches to either side. In many cases, the conversion from suid to capability-based is sufficiently trivial that it is viable to carry that patch downstream for an extended period. Replacing the suid program with a more complex daemon with authentication mechanisms is an interesting goal, but it is not a trivial drop-in replacement the way file capabilities are supposed to be. Carrying a patch to programs that need to contact the daemon is likely much more invasive and application specific.

miket
Guru
Guru

Joined: 28 Apr 2007
Posts: 488
Location: Gainesville, FL, USA

Posted: Fri Aug 04, 2017 5:20 am Post subject:

Hu wrote:

Much like the idea of a minimal PolKit-compatible replacement lets you avoid patching all PolKit clients, using file capabilities instead of suid programs lets you avoid patching every script (and user) accustomed to using those suid programs.

Well yes, for those programs (seemingly reduced in number nowadays) that expect to use the exec() call to get service from programs like passwd, fusermount, sudo, and su (the original user of the SUID bit), it would be dead easy to drop the 's' bit and add the needed capabilities and leave everything else alone. None of those four use capabilities right now.

What I had in mind in my wished-for world had nothing to do with changing clients of SUID binaries but rather to imagine how DE's could avoid the extravagance of going through even a denatured Polkit. I talked about sockets because some of the solutions might lend themselves better to persistent execution: a daemon for mountable devices come to mind. A client could connect to a service's event-message socket to subscribe to event broadcasts and then request service via another socket. This does not preclude using an executable instead to request service.

Hu wrote:

Replacing the suid program with a more complex daemon with authentication mechanisms is an interesting goal, but it is not a trivial drop-in replacement the way file capabilities are supposed to be.

Actually, the thing I had in mind was for the service code, whether invoked by an executable or by taking requests on a socket, would never have responsibility for checking authorization--that would be entirely up to the standard Unix mechanism of file ownership, group membership, and access-mode mask.

Hu wrote:

Carrying a patch to programs that need to contact the daemon is likely much more invasive and application specific.

Most assuredly so! That's why I was trying to avoid it.

steveL
Watchman

Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

Posted: Fri Aug 04, 2017 2:00 pm Post subject:

miket wrote:

And you've come full-circle, to a standard executable.

I'm not seeing the attraction of a "daemon"; there's no long-lived process (and lots of reasons not to have one), no costly startup; and no need to optimise this case even.

Similarly, I don't see the point of kludging a library call over dbus, when you can just use a library call, and will thus execute much more efficiently, as well as no longer need the code linked-in, to talk dbus at all.

Shame really, as a "desktop bus" is not a bad idea; this is just a shitty implementation from a shitty team, based on their actions and behaviour over years, as many others have commented (argue with Torvalds about it.)
dcop was much better, and just needed optimising to be as performant as the gtk ORB; or the inverse: run dcop over the ORB. The worst move was the one taken, to use the new-fangled, pig of a performer (12 times slower than dcop, which was 2 or 3 times slower than the ORB) that didn't have the same utility as dcop, and has not engendered any of the "scriptable desktop" we were promised, and already had in KDE-3.
Broken promises seem to be the only consistent outcome, when it comes to Poeterring and the fdo cult.

I agree that, where you do need a service (as opposed to an action), it's much better to talk to it over a (UNIX) socket, than dbust. Or a named FIFO. or.. cf: APUE; "Advanced Programming in the UNIX Environment", Stevens (2nd ed 2005), or UNP vol 2 *UNIX Network Programming, Volume 2: Interprocess Communications" also by Stevens, (2nd ed, 1999). (I know you know, but there's always people who don't, yet.)

Most things currently affixed 'd' ('fubard') should not be services. What's happening there is a takeover, something socio-political, which geeks are usually crap at handling. (They'd rather stay in their comfort-zone, like every other human being.)

Sure, the individual developer still sees oneself as solely working to get a result; the wider atmosphere has changed, however. It's not so friendly, not so collaborative, because corporate interests don't work like that. Unless ofc you are using the officially-approved One True Way, in which case we'll spread false cheer all over you, while subtly disparaging the people you used to hang with.

This is not in your interests, nor ours: we're just marks^W consumers in this demi-monde, not users, nor QA, nor programmers (who are going to be as influential as plumbers currently are, by 2030.)
It is aimed solely at stealing from us, coopting our work, then charging us for the "privilege" of using what we made ourselves, in our own time, under our own initiative.

Anyhow, enough wittering from me; it's really good to see you, miket. :-)

steveL
Watchman

Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

Posted: Fri Aug 04, 2017 2:17 pm Post subject:

Hu wrote:

Agreed, but the former really is indication that mike's right, and it should be called "Pollution-Kit", as it's poisoning the codebase.

Talk about horsemen of the QApocalypse.. ;)

Yamakuzure
Advocate

Joined: 21 Jun 2006
Posts: 2284
Location: Adendorf, Germany

Posted: Mon Aug 07, 2017 9:35 am Post subject:

josephg wrote:

but it logged nothing, when i changed console to tty2, logged in as another user and did all sorts of things including startx and logout.
i switched back to my x session on tty1, and it started logging again on keyboard activity.

That's because your TTY 2, outside of X, isn't using xinput, is it? ;-)

_________________
Important German:

"Aha" - German reaction to pretend that you are really interested while giving no f*ck.
"Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.

steveL
Watchman

Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

Posted: Mon Aug 07, 2017 1:54 pm Post subject:

R0b0t1 wrote:

No, you just need "privilege", or permission.

I must be missing something, as I don't see what else anyone would expect; if you log into a machine, expect that root can sniff your activity.

Everything you type in to a computer has to be duplicated, by definition, before anything can be done with it.

That seems pretty basic to me, but then I grew up before computers where everywhere, when electronics, like mathematics, was not seen as a "different field" to computing; it is the basis, and not a different field at all, any more than biology is a "different field" to medicine.[1] (Human specialism is another matter.)

The notion that I can sniff my own keyboard activity is hardly shocking.

Sure, I agree that you don't want anything dodgy running to try and sniff your activity (so er, don't start it); but getting rid of all this other dodgy crap first, is more of a priority in infosec terms, since it is woefully ill-conceived, terribly-implemented, and totally unnecessary; all of which makes it a massive target for ongoing vectors.

And frankly, its aims and intents seem more in line with a cracker than a hacker.

--
[1] "Dr Poeterring will see you now.. No, he doesn't know anything about biology, but that's ok: he's a RedHat-certified medical doctor, not a biologist."

steveL
Watchman

Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

Posted: Mon Aug 07, 2017 2:17 pm Post subject:

miket wrote:

I agree it's a PITA; the question I have though, is what KDE does on non-UNIX platforms, like Winbloze, or on Unices that are never going to "adopt" systemdbust, like solaris, or openbsd.

KDE has always been a showcase for Qt, which gives platform-independence at the API level, or it has no use, and no value.
I cannot believe Trolltech (or whoever owns them now) would be so stupid as to throw away their showcase, and confine it to Linux and systemdbust machines only (that really is niche.)

R0b0t1
Apprentice

Joined: 05 Jun 2008
Posts: 264

Posted: Mon Aug 07, 2017 4:07 pm Post subject:

steveL wrote:

R0b0t1 wrote:

No, you just need "privilege", or permission.

I must be missing something, as I don't see what else anyone would expect; if you log into a machine, expect that root can sniff your activity.

My point is that any process a user is running needs to be considered to have the privileges of the most privileged process that user is running. Within a user ID there is no security enforcement that goes on in the vanilla kernel - you need SELinux or another MAC system. I don't think we disagree, I'm just pointing out how potentially bad the situation is.

I can have a rogue process start to debug another one, or modify another process' state by modifying /proc/<pid> files. So if you have a virtual terminal open, I can scan the process' memory to see your password. If you have a virtual terminal open logged in as root I can write to its memory to synthesize command input. No change to X11 will fix a problem like this, and most proposed changes to "fix" X11 "holes" just make it hard to write usable software for X11 without solving the real problem.

steveL wrote:

For Windows, KDE maintains its own buildsystem called Craft. Craft contains recipes to build dbus, which has Windows support in the main codebase. Most large KDE projects were ported to Windows individually some time ago. With the introduction of Craft, it seems like all KDE dependencies are being ported to Windows. For the BSDs it seems like most KDE dependencies run as-is and don't need much modification, but there are still problems keeping the software from working (unless the porting work is complete - it's hard to tell, BSD users seem uninterested in KDE for the most part).

Interestingly, Craft contains verbiage in it that implies it is descended from Portage.

Display posts from previous:

	Gentoo Forums Forum Index Gentoo Chat	All times are GMT Goto page 1, 2, 3 Next
Page 1 of 3

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Copyright 2001-2024 Gentoo Foundation, Inc. Designed by Kyle Manna © 2003; Style derived from original subSilver theme. | Hosting by Gossamer Threads Inc. © | Powered by phpBB 2.0.23-gentoo-p11 © 2001, 2002 phpBB Group
Privacy Policy