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 Previous 1, 2, 3 Next

Gentoo Forums Forum Index

Gentoo Chat

View previous topic :: View next topic

Author

Message

Yamakuzure
Advocate

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

Posted: Tue Aug 08, 2017 8:10 am Post subject:

R0b0t1 wrote:

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.

What?

R0b0t1 wrote:

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.

No. All security relevant files for io and memory have mode 0400. Apart from /proc/<pid>/mem, which would be needed to manipulate the process memory. That one has 0600.

However, what is bad about being able to monitor and manipulate ones own processes?
Yes, you can, but only within the bounds of your very own privileges.

Not being able to do so, or even needing to have root access, would be catastrophic for me as a developer! I do not have root access to all machines I develop on.

R0b0t1 wrote:

So if you have a virtual terminal open, I can scan the process' memory to see your password.

No, you can't, unless you are me or root.

Maybe it helps to read this question about Reading living process memory without interrupting it ...

R0b0t1 wrote:

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.

If I let you access my root console, you either have neutralized me in any way, or I am an idiot. You must do so physically.

Writing to any process memory to synthesize user input is impossible unless you are the owner of the process or root. Period.

Code:

sed@sed-notebook ~ $ ps aux | grep bash | grep root
root 19343 0.0 0.0 23312 4612 pts/4 S Aug07 0:00 bash
sed@sed-notebook ~ $ # *yay* a root bash!
sed@sed-notebook ~ $ LC_ALL=C ls -lh /proc/19343/ | grep -P " (io|page|maps|mem|stack)"
ls: cannot read symbolic link '/proc/19343/cwd': Permission denied
ls: cannot read symbolic link '/proc/19343/root': Permission denied
ls: cannot read symbolic link '/proc/19343/exe': Permission denied
-r-------- 1 root root 0 Aug 8 10:02 io
-r--r--r-- 1 root root 0 Aug 7 23:44 maps
-rw------- 1 root root 0 Aug 8 09:53 mem
-r-------- 1 root root 0 Aug 8 10:02 pagemap
-r-------- 1 root root 0 Aug 8 10:02 stack
sed@sed-notebook ~ $ # HA! /proc/<pid>/maps can be read by everyone. Let's dump it and scan the root shells memory! *harrharrharr*
sed@sed-notebook ~ $ LC_ALL=C cat /proc/19343/maps >> foo.dump
cat: /proc/19343/maps: Permission denied

Awww... what a pity...
_________________
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.

depontius
Advocate

Joined: 05 May 2004
Posts: 3509

Posted: Tue Aug 08, 2017 11:41 am Post subject:

Yamakuzure wrote:

If I let you access my root console, you either have neutralized me in any way, or I am an idiot. You must do so physically.

This has always been at the center of my security philosophy for my home computing network. If you've got physical access to my console, my problem isn't that you've got access to my computers, my problem is that there is an intruder in my home. That's the start point for home computing security. The laptop is the only computer where physical access is an issue, darned evil maids.
_________________
.sigs waste space and bandwidth

R0b0t1
Apprentice

Joined: 05 Jun 2008
Posts: 264

Posted: Tue Aug 08, 2017 4:12 pm Post subject:

Yamakuzure wrote:

R0b0t1 wrote:

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.

What?

By default there's no restrictions that prevent a user from modifying their own processes in creative ways. Compromising a single process a user is running is essentially the same as compromising that user account. Admittedly what I'm proposing is technically challenging as far as attacks go, but it's still possible.

The rest of your post unfortunately seems to have ignored this caveat I had in my original message:

R0b0t1 wrote:

Within a user ID

I am not talking about scanning the memory of the root console, I am talking about scanning the memory of or modifying the state of a virtual terminal emulator (running within X11 or Wayland) that a user has logged in as root.

Yamakuzure wrote:

R0b0t1 wrote:

So if you have a virtual terminal open, I can scan the process' memory to see your password.

No, you can't, unless you are me or root.

It seems like you agree this is possible.

What I'm trying to get at is that this is the same type of "hole" that X11 has. It's not possible to fix it by modifying X11, and modifying Linux to fix it (with, say, SELinux) tends to make a system unusable in the opinion of the majority of users.

Hu
Moderator

Joined: 06 Mar 2007
Posts: 21631

Posted: Wed Aug 09, 2017 2:12 am Post subject:

To elaborate on R0b0t1's point: for a given user joe, classic Linux provides little isolation to keep joe's processes from manipulating each other. Developers find this very convenient when debugging. Users, when they're aware of it, find it very inconvenient from a security perspective. If you keep an xterm open and that xterm has run /bin/su to get a root shell, then any process that cares to manipulate that xterm can feed input to the pseudo-tty that the privileged shell is consuming. This is a security problem. It does not require console access. It only requires code execution as user joe - the same user running all the other complicated programs on the desktop. Given the wonderful security track record of certain large complex programs (in particular, Firefox, but also various audio/video player libraries), dismissing the problem on the grounds that nobody ever gets code execution on a Linux desktop is not as sound as many users would like.

josephg
l33t
l33t

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

Posted: Wed Aug 09, 2017 8:26 am Post subject:

Hu wrote:

If you keep an xterm open and that xterm has run /bin/su to get a root shell, then any process that cares to manipulate that xterm can feed input to the pseudo-tty that the privileged shell is consuming. This is a security problem. It does not require console access. It only requires code execution as user joe - the same user running all the other complicated programs on the desktop.

is this with or without polkit.. if i as a user open a root shell in xterm, any other program that is currently running can grab root access??

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

asturm
Developer

Joined: 05 Apr 2007
Posts: 8936

Posted: Wed Aug 09, 2017 9:30 am Post subject:

Nothing to do with polkit.

Yamakuzure
Advocate

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

Posted: Wed Aug 09, 2017 10:22 am Post subject:

Hu wrote:

Yes. You either live in a nutshell, or you have to use some common sense in your daily work.
The biggest security threat is not some obscure way (*) to get input through program A to program B, the biggest threat is just this one:

The Threat That Sits Between The Chair And The Monitor! (tm)

And no. This has nothing to do with PolKit.

(*) Think about it. For that to work you have to:

Have an xterm open
Have su'd in that xterm
Have a process running that is actually able to manipulate xterm
And that process can only come from the user themselves or root.
And that process must have come from somewhere...
Oh, and that process must be able to actually fake user input into xterm.

This fascinatingly sounds like: "Wow, an e-mail from my bank! *yay* Let's open that foo.pdf.exe document!".
_________________
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.

R0b0t1
Apprentice

Joined: 05 Jun 2008
Posts: 264

Posted: Wed Aug 09, 2017 1:56 pm Post subject:

Yamakuzure wrote:

This fascinatingly sounds like: "Wow, an e-mail from my bank! *yay* Let's open that foo.pdf.exe document!".

Like Hu said, and like I was trying to convey, presenting this as something that is unlikely to happen is not really valid. If at any point one of your running programs is compromised it can launch a thread (or another program) that waits for you to open a privileged virtual terminal emulator. The kinds of attack I'm proposing only require you to do something as simple as visiting a website, or, in the worst cases, can be fully remote if you are running a daemon as your user (which can be rather common on large multiuser systems).

What needs to happen is rather complex, but just because you don't know how to do it or that you think it is too much work does not mean no one will do it.

steveL
Watchman

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

Posted: Wed Aug 09, 2017 3:30 pm Post subject:

R0b0t1 wrote:

Within a user ID

Sure, within a user-id, there is no containment; that's because the uid is the unit of containment.

From my pov, this is a bit like saying "Ew.. I cannot mkdir inside a file". Yes, obviously not; that's the basic design.

R0b0t1 wrote:

So if you have a virtual terminal open, I can scan the process' memory to see your password.

This simply does not follow; the use of "I" and "you" implies two different uids.
As such this statement does not stand up, under your own definition.

steveL
Watchman

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

Posted: Wed Aug 09, 2017 4:02 pm Post subject:

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

Sorry, the question was more at code-level than packaging; are they going to implement polkit for Winbloze, Solaris and any POSIX platform? (I'd be amazed if so, both at the stupidity, and the arrogance to think they could, and should.)

If not, then surely they can stop peddling the lie that they absolutely need that crap to run.

They're only supposed to need Qt, or they're not worth much to the company that funds them.
If some "executive" is over-enthusiastic about throwing away platform-independence, the chances are s/he'll be working elsewhere soon enough.

The same argument applies to any Linux-specific dependency. By all means specify and implement a platform-neutral layer to do whatever; just stop pretending that it must require anything specific on any platform, as that is embarrassingly dumb, and can only reflect woeful inexperience, at best.

Oh, and if what you're specifying, is simply a rebranding of a long-existing term you were ignorant of, do not expect domain-specialists to respond at all; and if they do, that they are laughing at you, is not an indication of "hatred" (that's all in your mind) but of sheer baffled amusement that you are both so ignorant of the domain, and yet so certain of the correctness of your pig-in-a-poke.
What you're really (not) hearing is: "Are you sure you're a coder? Do you even know what that means?"

This is not elitist, nor exclusionary; s/coder/doctor/ or /plumber/ and reconsider, if that's a concern.

Quote:

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

Cool :-)

R0b0t1
Apprentice

Joined: 05 Jun 2008
Posts: 264

Posted: Wed Aug 09, 2017 4:43 pm Post subject:

steveL wrote:

R0b0t1 wrote:

Within a user ID

Then you are probably in the minority with your opinion, as most people see the "holes" in X11 and expect there to be some kind of fix. There really isn't, and possibilities like I detailed are the reason why.

steveL wrote:

R0b0t1 wrote:

So if you have a virtual terminal open, I can scan the process' memory to see your password.

This simply does not follow; the use of "I" and "you" implies two different uids.
As such this statement does not stand up, under your own definition.

"I" is if I am an attacker who has compromised one of your processes. I'm not sure I would read my post to expect that permission enforcement didn't exist, because I explain how I expect it to exist earlier in my post.

steveL wrote:

R0b0t1 wrote:

The reply was code level, but I do not have the same information that the KDE developers do. The large KDE projects with many developers were ported to Windows directly and rely mainly on Qt. It seems like KDE is attempting to handle smaller projects by porting all of their dependencies to Windows. In the case of Polkit, I am not sure it makes sense to port it to Windows because its function is handled by Windows. There is no effort I was able to find to port it to Windows.

If something is very tightly coupled with Polkit and is in KDE, it seems like refactoring those portions to allow a lack of Polkit is part of the porting work. At the same time the programs that have tight coupling with Polkit may not make sense on Windows, or may need to be completely reengineered anyway.

I don't think it's possible to say that Polkit, or something like it, is unnecessary. Window's implementation of the security most people associate with Polkit seems to be very low level and is implemented in the kernel. It looks very similar to SELinux on closer inspection. However, it is disabled by default, and you can only see most of the options without poking special things on the server releases of the OS.

SELinux seems to me to be the replacement for Polkit. Unfortunately, it is still very hard to administrate.

Last edited by R0b0t1 on Thu Aug 10, 2017 1:25 am; edited 1 time in total

Hu
Moderator

Joined: 06 Mar 2007
Posts: 21631

Posted: Thu Aug 10, 2017 1:03 am Post subject:

josephg wrote:

is this with or without polkit.. if i as a user open a root shell in xterm, any other program that is currently running can grab root access??

No, only programs that can ptrace the xterm. By default, this limits it to programs running as you or running as root. Other unprivileged users cannot ptrace the xterm, and so are not an issue.

Yamakuzure wrote:

The biggest security threat is not some obscure way (*) to get input through program A to program B, the biggest threat is just this one:

The Threat That Sits Between The Chair And The Monitor! (tm)

I disagree that this is categorically true. Yes, some users are sloppy. Some users are not. All users are affected by this design. Many affected users who might otherwise be careful seem not to be aware of this weakness. As a case in point, you seem to overestimate the complexity required. Careful users are necessary but insufficient to the security of the system.

Yamakuzure wrote:

And no. This has nothing to do with PolKit.

Correct.

Yamakuzure wrote:

(*) Think about it. For that to work you have to:

Have an xterm open
Have su'd in that xterm
Have a process running that is actually able to manipulate xterm
And that process can only come from the user themselves or root.
And that process must have come from somewhere...
Oh, and that process must be able to actually fake user input into xterm.

This fascinatingly sounds like: "Wow, an e-mail from my bank! *yay* Let's open that foo.pdf.exe document!".

Doesn't everyone leave terminals open?
I usually leave a root shell around. I decorate it differently and make it a point to use it only for tasks that I know require privilege. It beats re-entering the root password every time, which is arguably even more dangerous since xinput can snoop that.
So - any process running as me, anywhere in the same PID namespace. Seems like a pretty low bar, since almost everything I run starts as me and does not attempt to change to an isolated user.
Yes. If this process runs only code I approve, that's fine. That just means I need to avoid running anything with a remote code execution vulnerability. That should be easy, right? I mean, it's not like our browsers don't routinely run unvetted code from the Internet that we just hope the Javascript sandbox can contain.
Yes
So, anything that can ptrace the xterm and, if you don't use a terminal emulator that refuses synthesized X events, also anything with an unrestricted X11 cookie. That's not a short list.

I don't think an exe from the bank would run well on Linux. It's probably not even open source.

There are ways to harden against some aspects of this, but the underlying problems require a stronger process isolation model, and that will impede developers if they continue to follow old habits. The ptrace_scope patchset helps some. PID namespaces can help too. Untrusted downloads can be crippled by mounting all user-writable areas as noexec. Everything has trade-offs.

Tony0945
Watchman

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

Posted: Thu Aug 10, 2017 1:36 am Post subject:

Hu wrote:

I usually leave a root shell around. I decorate it differently and make it a point to use it only for tasks that I know require privilege. It beats re-entering the root password every time, which is arguably even more dangerous since xinput can snoop that.

I setup the sudoers conf file so that my user (ME!) can su without a password, so I don't leave a root terminal laying around. This is arguably more dangerous, but not any more than Windows where my user is an Administrator.

josephg
l33t
l33t

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

Posted: Thu Aug 10, 2017 7:47 am Post subject:

Hu wrote:

1. Doesn't everyone leave terminals open?
2. I usually leave a root shell around. I decorate it differently and make it a point to use it only for tasks that I know require privilege. It beats re-entering the root password every time, which is arguably even more dangerous since xinput can snoop that.

so any program that starts (automatically or manually) would be running either as a daemon started by root or as you, the current user. and if any program runs xinput, then it can snoop all your keystrokes everywhere, including passwords. is that right? doesn't sound secure at all!

Tony0945 wrote:

even more dangerous, as any program can run "su(do) command" and have "command" run as root. duh!

arguably this is more of a risk with closed-source programs!

but many of the current bloatware software (even open-source) programs, are so mahoosive that no one can reasonably vet all code, unless you know exactly what you are looking for and where! what is the assurance that nothing unexpected is happening?
_________________
"Growth for the sake of growth is the ideology of the cancer cell." Edward Abbey

mv
Watchman

Joined: 20 Apr 2005
Posts: 6747

Posted: Thu Aug 10, 2017 9:19 am Post subject:

R0b0t1 wrote:

as most people see the "holes" in X11 and expect there to be some kind of fix. There really isn't, and possibilities like I detailed are the reason why.

Keyboard sniffing (or also event sending?) over X is a much larger attack surface than any of the other "holes" that you describe:

Even programs started as unprivileged (different) users can do keyboard sniffing if for some reason you have to give them access to X. This is not the case for the other attacks you mention
Even without a special access control system, current kernels can restrict ptrace (yama). Maybe historically this option was "stolen" from grsec, but anyway it does not require running a full-fledged access control system

ct85711
Veteran
Veteran

Joined: 27 Sep 2005
Posts: 1791

Posted: Thu Aug 10, 2017 1:47 pm Post subject:

Quote:

The part you are not thinking of that, all programs are inherently insecure if it takes a input. Be that the human doing the input is the threat or the program receiving the input is the threat, you are going have to have certain parts you have to assume it is going to be relatively safe. This is even more so on closed-source programs, as you don't know if the program it self is a threat. In the end, almost all programs need some kind of input to be useful, so you can't get rid of the threat either way.

steveL
Watchman

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

Posted: Thu Aug 10, 2017 5:04 pm Post subject:

steveL wrote:

R0b0t1 wrote:

Then you are probably in the minority with your opinion

So what? If "the majority" is simply wrong about something, I'm happy to be in the minority.

Quote:

as most people see the "holes" in X11 and expect there to be some kind of fix. There really isn't, and possibilities like I detailed are the reason why.

No, "the reason why" is because the uid is the unit of containment.
To continue the analogy: just because someone complains the "majority" wants to mkdir inside a file, and that therefore it must happen, and filesystems should change how they handle inodes, "because innovation"; does not mean it's going to happen.

Whatever is trying to be implemented, can likely happen (man tar); but only when you've got past the X-Y problem, which frankly is what the whole affair feels like.[1] ("Developers" are notoriously bad at all the basic problems one sees in #bash, especially the ones related to an inability to step back from the problem, and definitely the ones which require self-insight to deal with. Thankfully, most of the regular crowd are sysadmins.)

So, if there's a wider discussion on application containment, by all means: let's have that discussion, instead.
Polkit is not the answer; it's the Z in X-Y problem: what the user reaches for as a solution to Y, which they don't understand either, even if were not the wrong tool to use.

R0b0t1 wrote:

So if you have a virtual terminal open, I can scan the process' memory to see your password.

steveL wrote:

This simply does not follow; the use of "I" and "you" implies two different uids.
As such this statement does not stand up, under your own definition.

R0b0t1 wrote:

"I" is if I am an attacker who has compromised one of your processes.

Then you should have written "an attacker who has compromised one of your processes", which is a whole different (but quite standard) thing; you didn't, you just wrote the all-encompassing statement you did, like it was a logical consequence, when it clearly is nothing of the sort.

R0b0t1 wrote:

I'm not sure I would read my post to expect that permission enforcement didn't exist, because I explain how I expect it to exist earlier in my post.

IDK what you're talking about here. All I said was that you need permission, or "privilege"; as Hu has also pointed out.
Your sweeping statement made no mention of permission, wrt "your" magical ability to sniff any process.

It's no big deal to be picked up for a generalisation. *shrug*

steveL wrote:

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.)
..are they going to implement polkit for Winbloze, Solaris and any POSIX platform? (I'd be amazed if so, both at the stupidity, and the arrogance to think they could, and should.)

If not, then surely they can stop peddling the lie that they absolutely need that crap to run.

R0b0t1 wrote:

The large KDE projects with many developers were ported to Windows directly and rely mainly on Qt. It seems like KDE is attempting to handle smaller projects by porting all of their dependencies to Windows. In the case of Polkit, I am not sure it makes sense to port it to Windows because its function is handled by Windows. There is no effort I was able to find to port it to Windows.

OK, so no, they're not porting polkit. Thanks for doing the research.
So no, it's not absolutely necessary, and it never was.

Though this reads as if KDE were a Linux project, that is only now being "ported" elsewhere; that is incorrect. KDE has always been cross-platform, a UNIX GUI on top of Qt and X, even if most development has traditionally been Linux-based. (Linux desktop developers nowadays appear to be Mac-based, only ever running Linux in a VM; reliability has lessened accordingly.)

R0b0t1 wrote:

If something is very tightly coupled with Polkit and is in KDE, it seems like refactoring those portions to allow a lack of Polkit is part of the porting work. At the same time the programs that have tight coupling with Polkit may not make sense on Windows, or may need to be completely reengineered anyway.

This reads like KDE was conceived with Polkit, and the "porting effort" is a new thing, subsequent to the decision to force polkit on linux. Both are incorrect.

The question remains: YTF did anyone introduce "tight coupling" with Polkit?
To introduce tight coupling at this level, above the platform-independent API.. words fail.

I remain hopeful that KDE is more modular as KF5, as that was the plan a couple of years ago. If so, you should be able to rip out and replace whichever module; however, miket indicated that the codebase is scattered with calls to dumbass interfaces. This is either incompetence (someone does not understand what 'modularity' means), or sabotage, the "gentle Putsch" of enforced dependencies that the entire FLOSS community has been subjected to, for the last 5 or 6 years. The former is often a vector for the latter, pushed by social means.

Polkit has not helped anything here; it's just a dependency enforced for political and commercial reasons, not technical ones.
The technical reasoning is very unsound, as has been discussed to death on these forums; in fact it's practically non-existent. Certainly, the various "revelatory blogposts" we're linked to in lieu of specs, are not what I'd recognise as technical reasoning, judging from their content.

So, yeah, it's good that they're having to "refactor" and "cope" without polkit; it's insane that they didn't do that in the first place, however, with calls to the interface wrapped by a platform-dependent module, that spells out what you are actually trying to do (if that is even understood: there really is no need to "acquire a display" at this level.)
OFC, to do so, would have been to allow KDE to run happily without polkit on Linux, with only minor adjustment: and that's why they did not do the basics first time around, imo.
It is also why I call those "wasted years" for FLOSS: we could have been collaborating over a solid base, instead of sniping about the dodgy ground, which only helps corporations seeking vendor lock-in, against the interests of users.

Quote:

I don't think it's possible to say that Polkit, or something like it, is unnecessary.

Yes it is. I've been doing so for years.
And I was running KDE without Polkit for decades; so please don't tell me it is "necessary". Especially when the approach is touted as stupendously different to everything else (yet we had better desktops back in the late 90s, on comparatively restricted hardware.)

Though "something like it" is simply weasel-wording, afaic; it means you can always say "Oh, look that's a bit like Polkit, so we didn't really waste 5 years of everybody's time with that crapfest," which could've been avoided if only we'd done some thinking upfront, and maybe even listened to all the domain experts and sysadmins, at some point in our journey of idiocy.

PAM is cool; and no, it's nothing like polkit. Though I'm sure some nub will find a way to say it's "just the same" because it runs on a computer.
Or how we should all be grateful to RedHat, as PAM came from their stable, back in the days when computers were still boring, and they weren't just the tail-end of a multinational conglomerate.
Note that in the "early" days, PAM was rubbished by the polkit team; two or three years later, polkit became all about "handling" PAM for you (with user-supplied javascript, no less, rather than the boring old config files you still need.)

Things change, and corporations are the least reliable entities in the world. (Don't believe the hype.)

--
[1] AFAIC, Poeterring's entire career to date, is a series of X-Y misunderstandings, combined with stubborn arrogance passing itself off as determination.
Poeterring "doesn't know how to do Y either", so gets into a discussion with the domain experts (like LAD, kernel-networking folks, dhcp developers, etc) who are puzzled, and ask around the problem to see what X really is. OFC they have plenty of solutions to X, since it's usually something pretty basic, or something core to their work.
Poeterring is already invested in Y, however, his custom (so must be kewl) "solution" to the wrong problem, and does not want to let go of it; he'd rather code his own Z to paper over the borked design, and bake it in stone (wherafter it will be a "standard" and everyone will be thinking in the same borked terms, neologisms that only he can define; since their meaning changes over time, as he learns a tiny bit more this year via CVE.)
Cue accusations of "hater" at anyone who doesn't concur, and a retreat to the bunker, where faithful minions have learnt to agree with everything the madman says, else suffer blistering social approbation.
Lather, rinse, repeat.. Unfortunately, it's a positive-feedback loop, since there is no point where someone can give him a verbal slap in the face, and he might actually listen. As such, it's going to keep getting worse, until the wheels finally come off the rails.

josephg
l33t
l33t

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

Posted: Thu Aug 10, 2017 8:01 pm Post subject:

steveL wrote:

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.)
..are they going to implement polkit for Winbloze, Solaris and any POSIX platform? (I'd be amazed if so, both at the stupidity, and the arrogance to think they could, and should.)

If not, then surely they can stop peddling the lie that they absolutely need that crap to run.

i cannot believe that anyone would willingly call themselves Trolltech
if they were not a tech company, perhaps i would understand their ignorance as to the nuances of that word

steveL wrote:

Quote:

I don't think it's possible to say that Polkit, or something like it, is unnecessary.

i agree, and i've always removed polkit wherever possible. i don't have polkit consolekit etc on my gentoo. unnecessary bloat increasing complexity and hidden obscurity.

i'm amazed by certain new too-big too-complex too-integrated bloatwares being introduced, backed by overwhelming media onslaught to throw away everything older replacing them with newer (better?) technologies. all my older kit were (still are?) happily functioning more efficiently more akin unix philosophy, until someone in their infinite wisdom decided to deprecate perfectly stable things. and then they use arguments like only older greybeards etc want certain things, and anyone younger should want different things.
_________________
"Growth for the sake of growth is the ideology of the cancer cell." Edward Abbey

Ant P.
Watchman

Joined: 18 Apr 2009
Posts: 6920

Posted: Thu Aug 10, 2017 9:23 pm Post subject:

josephg wrote:

i cannot believe that anyone would willingly call themselves Trolltech
if they were not a tech company, perhaps i would understand their ignorance as to the nuances of that word

I'm sure you can find plenty of people who agree with you at the bottom of a slashdot thread from 1998, where such schoolyard insults belong along with the ones for GIMP, GNU, GNOME etc.

R0b0t1
Apprentice

Joined: 05 Jun 2008
Posts: 264

Posted: Fri Aug 11, 2017 1:10 am Post subject:

mv wrote:

R0b0t1 wrote:

as most people see the "holes" in X11 and expect there to be some kind of fix. There really isn't, and possibilities like I detailed are the reason why.

Keyboard sniffing (or also event sending?) over X is a much larger attack surface than any of the other "holes" that you describe:

Even programs started as unprivileged (different) users can do keyboard sniffing if for some reason you have to give them access to X. This is not the case for the other attacks you mention
Even without a special access control system, current kernels can restrict ptrace (yama). Maybe historically this option was "stolen" from grsec, but anyway it does not require running a full-fledged access control system

If you give them access to your X11 session it seems to follow that they should have access to the resources that X11 manages. However, that user needs to authorize anyone else besides themselves in some way, and this authentication needs to be turned off for X11 to be insecure. You can't sniff someone else's X session without a secret given to that user by X11.
Ptrace seems to have been used as an example because it was easy to understand. You also need to restrict permissions to /proc/<pid> files, and other mechanisms that I might not know of. Novel ways to manipulate the state of other processes keep being discussed and I'm not sure if more have been added.

Following up on #1: There have been various attempts to create security mechanisms within a desktop, but none I know of are actually pleasant to use or create a situation that can't be subverted in some other way. Even Microsoft, when faced with a particularly nasty class of exploits that allowed privilege escalation to SYSTEM, rewrote the way Windows manages user login sessions (to be more like how Linux does things) rather than actually change the desktop abstraction. My point wasn't that this can't be solved, just that it can't be solved inside of X11.

steveL wrote:

R0b0t1 wrote:

Then you are probably in the minority with your opinion

So what? If "the majority" is simply wrong about something, I'm happy to be in the minority.

Sometimes how people view a subject does dictate reality, and this is one of those times. How processes behave on Linux (and Windows, for that matter) doesn't live up to most user's expectations. It's easy enough to describe what is, it's far harder to justify that it should be the way it is, especially when the way it is contradicts user expectations.

steveL wrote:

Quote:

as most people see the "holes" in X11 and expect there to be some kind of fix. There really isn't, and possibilities like I detailed are the reason why.

Then what to processes do? They surely contain something. Unfortunately there is no security boundary between processes like users expect there to be. It's easy enough to add this because someone has already implement it, it just makes a lot of things very annoying to set up.

steveL wrote:

Whatever is trying to be implemented, can likely happen (man tar); but only when you've got past the X-Y problem, which frankly is what the whole affair feels like.[1] ("Developers" are notoriously bad at all the basic problems one sees in #bash, especially the ones related to an inability to step back from the problem, and definitely the ones which require self-insight to deal with. Thankfully, most of the regular crowd are sysadmins.)

So, if there's a wider discussion on application containment, by all means: let's have that discussion, instead.
Polkit is not the answer; it's the Z in X-Y problem: what the user reaches for as a solution to Y, which they don't understand either, even if were not the wrong tool to use.

R0b0t1 wrote:

So if you have a virtual terminal open, I can scan the process' memory to see your password.

steveL wrote:

This simply does not follow; the use of "I" and "you" implies two different uids.
As such this statement does not stand up, under your own definition.

R0b0t1 wrote:

"I" is if I am an attacker who has compromised one of your processes.

R0b0t1 wrote:

I'm not sure I would read my post to expect that permission enforcement didn't exist, because I explain how I expect it to exist earlier in my post.

Your insistence on arguing semantics is confusing and makes me disinclined to reply further. In any case, I wrote that sentence as if it were a logical consequence of something because it was a logical consequence of something: as I stated in the post, there are very few if any security boundaries within a UID. If I control a process with your UID I more or less control every process with that UID unless you have added some hard to use security extensions to your kernel.

It's difficult to respond in a concise way to the rest of your post, but the general theme is that you seem to be misunderstanding what I have said. KDE is well written, but inasmuch as anything within KDE needs Polkit to run (so I'm not saying to what extent it does need Polkit) they seem to be handling dependencies in the way I described.

steveL wrote:

It's no big deal to be picked up for a generalisation. *shrug*

steveL wrote:

R0b0t1 wrote:

In your second paragraph you contradict yourself: KDE has always been cross platform, but it initially focused on Unix.

Despite how early on KDE decided to be cross platform, there are still parts that do not have very good (or any) support on Windows. Invariably it seems like software is written for one OS before any others, and that OS is the one the main author uses. There are very few projects that initially produce cross platform code that supports all platforms to the same degree.

I never said that KDE was designed alongside Polkit. I said if there is code that uses Polkit, these things are probably true, and then did my best to justify those things. Consequently I can't really respond some of the rest of your post because it's talking about something I never implied were true. However, I can verify that KF5 is more modular and cleaner than previous versions of the framework, and is partly the reason I like to suggest Plasma 5.

steveL wrote:

Polkit has not helped anything here; it's just a dependency enforced for political and commercial reasons, not technical ones.
The technical reasoning is very unsound, as has been discussed to death on these forums; in fact it's practically non-existent. Certainly, the various "revelatory blogposts" we're linked to in lieu of specs, are not what I'd recognise as technical reasoning, judging from their content.

So, yeah, it's good that they're having to "refactor" and "cope" without polkit; it's insane that they didn't do that in the first place, however, with calls to the interface wrapped by a platform-dependent module, that spells out what you are actually trying to do (if that is even understood: there really is no need to "acquire a display" at this level.)
OFC, to do so, would have been to allow KDE to run happily without polkit on Linux, with only minor adjustment: and that's why they did not do the basics first time around, imo.
It is also why I call those "wasted years" for FLOSS: we could have been collaborating over a solid base, instead of sniping about the dodgy ground, which only helps corporations seeking vendor lock-in, against the interests of users.

Quote:

I don't think it's possible to say that Polkit, or something like it, is unnecessary.

If you don't use Polkit (or something like it) then as far as I'm aware you aren't making use of certain features that many desktop users expect to exist. That's fine. I don't intentionally use Polkit or Consolekit either. But there are certain use cases that need security features that Linux does not offer by default, and it is these features that I consider make something "like Polkit." You don't need to implement those things similarly to how Polkit does so to make them usable.

Some of your comments on what you think I said about KDE, and KDE, make me think you have never tried to make a program cross platform. If you design for cross platform support very early on you will have a better time, but there are still many cases where wanting to do a specific thing on a different operating system simply doesn't make sense. Even for very general goals, like "wake the computer up from sleep," you will have very different solutions: on Windows, you can create an OS-level timer object and simply specify that it should wake the computer up; for Linux, you must access the RTC directly (if it is present) and consequently need superuser permissions to set an alarm (you can also set only a single alarm, and would need to manage multiple wakeup sources yourself). If you are trying to use Window's security subsystem you will find it extremely different from Linux and consequently code that manages things within that subsystem generally isn't portable to any other OS. The security subsystems are very specialized and use different verbiage and in a lot of places entirely different interfaces.

Even writing something that wraps high precision timers or asynchronous IO that works on both Windows and Linux is quite painful because each implements basically the same thing, but with enough differences to make no easy solution viable. A lot of times you get the best results by maintaining separate code for both platforms even if there are abstraction libraries available.

mv
Watchman

Joined: 20 Apr 2005
Posts: 6747

Posted: Fri Aug 11, 2017 8:03 am Post subject:

R0b0t1 wrote:

If you give them access to your X11 session it seems to follow that they should have access to the resources that X11 manages.

That's the problem: You must either grant full access to all resources (includng keyboard sniffing) or none. AFAIK, there is not possibility to allow e.g. only opening some window and reading keys only when this window is active, or something similar. xauth provides generation of some "untrusted" cookies, but this is really not fine-grayned enough and is usually not sufficient for e.g. standard tasks of a web-browser.

Quote:

There have been various attempts to create security mechanisms within a desktop, but ...

Indeed, as long as a "window" and similar concepts are not part of the underlying system to provide access to resources (I mean here that resources for certain windows are associated to certain uids/gids only), this security gap is almost impossible to close. This is a big advantage which MS windows has security-wise: It can mix these levels (hardware and windows access) as necessary and need not take care about compatibility of different independent projects.

Quote:

Ptrace seems to have been used as an example because it was easy to understand. You also need to restrict permissions to /proc/<pid> files

Also these things are (theoretically) doable without a fancy access control: grsec had a very simple solution by just allowing to adjust permissions of /proc on the .config level. (Indeed practically nobody needs write access except perhaps for some developers when debugging; for these purposes, one might provide sudo-scripts which allow a certain specified access.) I don't know why so far this simple solution has not been part of the KSPP. Let's hope it is just a quesiton of time.

CasperVector
Apprentice

Joined: 03 Apr 2012
Posts: 156

Posted: Fri Aug 11, 2017 11:33 am Post subject:

mv wrote:

This is a big advantage which MS windows has security-wise: It can mix these levels (hardware and windows access) as necessary and need not take care about compatibility of different independent projects.

And perhaps Plan 9? Considering that windows are simply represented as virtual files in Plan 9.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

josephg
l33t
l33t

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

Posted: Fri Aug 11, 2017 4:18 pm Post subject:

mv wrote:

hmm.. and here i had the understanding that only the window with keyboard focus would receive any keystroke(s). are you all suggesting that is not true and every window/program can capture every keystroke whether running in foreground or background?

mv wrote:

and microsoft windows is more secure in this aspect? mind boggling!
_________________
"Growth for the sake of growth is the ideology of the cancer cell." Edward Abbey

mv
Watchman

Joined: 20 Apr 2005
Posts: 6747

Posted: Fri Aug 11, 2017 5:54 pm Post subject:

josephg wrote:

i had the understanding that only the window with keyboard focus would receive any keystroke(s). are you all suggesting that is not true

Just follow the instructions from the first posting and verify on your own machine that keyboard sniffing is easy. Key events are not related with any focus: The focus is a concept of the windows manager but not of X. That's the problem.

Quote:

and microsoft windows is more secure in this aspect?

It has the potential to be more secure in this aspect. This does not necessarily mean that it actually is.
Somebody mentioned that the situation might also be different under wayland.

R0b0t1
Apprentice

Joined: 05 Jun 2008
Posts: 264

Posted: Fri Aug 11, 2017 6:41 pm Post subject:

mv wrote:

R0b0t1 wrote:

If you give them access to your X11 session it seems to follow that they should have access to the resources that X11 manages.

Quote:

There have been various attempts to create security mechanisms within a desktop, but ...

That is as far as I can tell the proper way to fix it, but when I did some work trying to see how such a solution might be implemented it quickly became apparent that it would be a lot of work, and that there are huge swaths of programs that would have what some would consider overly broad access to desktop resources. It seems easier to simply prevent most programs being run from using X11, and only allowing trusted applications to run with any graphical presence. This situation would mirror a common SELinux install scenario where everything but the main user is confined. This is, unfortunately, the only setup which seems to not get in people's way.

mv wrote:

Quote:

Ptrace seems to have been used as an example because it was easy to understand. You also need to restrict permissions to /proc/<pid> files

The KSPP seems like an interesting project, but unfortunately there are a lot of issues in this area that are really issues with the interfaces the kernel exposes to userspace. I would like to see some of grsec's improvements added to the kernel. The resistance to adding such changes seems to be that they change the kernel/userspace contract.

josephg wrote:

mv wrote:

You can request all key events and get them. By default, you are typically asking for key events associated with a window element, which are filtered by testing for whether a window is currently focused or if the mouse is over a window.

josephg wrote:

mv wrote:

and microsoft windows is more secure in this aspect? mind boggling!

I'm not sure I would call it more secure. His comment applies, as far as I am aware, more to subsystems like removable volumes and audio devices. There is one centralized solution (Windows security contexts) if you want to secure those things. Otherwise, the session logged in at the computer has access.

On Windows, all programs on a desktop have the privileges of the most privileged process on the desktop. This conclusion comes directly from Microsoft, despite the use of shellcode in the exploit that caused this comment. Even within a Windows user account it seems possible to eventually execute a process in such a way that it can interact with processes which get Administrator permission from UAC, and steal that authority in the same way you can with virtual terminal emulators on Linux.

Display posts from previous:

	Gentoo Forums Forum Index Gentoo Chat	All times are GMT Goto page Previous 1, 2, 3 Next
Page 2 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