Hi,

Please, no systemd rants :)

This is a rather simple question (I hope). In LWN seems
there is a polkit vulnerability article and it contains
this link:

TinyURL: https://tinyurl.com/tnsve57u
OR
https://github.blog/2021-06-10-privilege-escalation-polkit-root-on-linux-with-bug/

I reading both LWN and the link, they seem to hint it only
happens with systemd. Is that correct ? Or it is general
to polkit ?

I would think all Linux Systems are vulnerable no matter
its init (assuming they use polkit).

Thanks
John

On Fri, 11 Jun 2021 19:28:07 +0000, John McCue wrote:

> Hi,
>
> Please, no systemd rants :)
>
> This is a rather simple question (I hope). In LWN seems
> there is a polkit vulnerability article and it contains
> this link:
>
> TinyURL: https://tinyurl.com/tnsve57u
> OR
> https://github.blog/2021-06-10-privilege-escalation-polkit-root-on-linux-with-bug/
>
> I reading both LWN and the link, they seem to hint it only
> happens with systemd. Is that correct ? Or it is general
> to polkit ?
>
> I would think all Linux Systems are vulnerable no matter
> its init (assuming they use polkit).

The second URL you quoted included a video demonstrating the polkit bug using
only commandline tools available on Slackware (i.e. nothing that /required/
systemd).

It seems like polkit has a timing-sensitive issue around the communication of
an authorization request over dbus, where polkit takes a well-timed failure to
communicate with an authorization prompt (either a GUI prompt or a text prompt)
as proper confirmation of increased privileges.

In other words, if you initiate a request for an action that requires privilege
escalation (via a dbus command) and abort that action (by killing the command)
at a crucial moment before polkit requests authorization to escalate privileges,
polkit does not ask for privilege escalation authorization (treating that abort
as a confirmation of escalated privileges), and executes the requested action
under the escalated privileges.

This mode of failure doesn't look to me to be related to systemd.

--
Lew Pitcher
"In Skills, We Trust"

Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> On Fri, 11 Jun 2021 19:28:07 +0000, John McCue wrote:
>
<snip>

> This mode of failure doesn't look to me to be related to systemd.

Thanks, wanted to be 100% sure, I suspect/hoping it is a local
vulnerability

John

On Fri, 11 Jun 2021 23:37:53 +0000, John McCue wrote:

> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>> On Fri, 11 Jun 2021 19:28:07 +0000, John McCue wrote:
>>
> <snip>
>
>> This mode of failure doesn't look to me to be related to systemd.
>
> Thanks, wanted to be 100% sure, I suspect/hoping it is a local
> vulnerability

The easiest way to get rid of the vulerability is of course to install
the patch if you are running Stable Slackware 14.2:

-8<---------------------------------
Mon Jun 7 18:53:49 UTC 2021
....
patches/packages/polkit-0.113-x86_64-3_slack14.2.txz: Rebuilt.
This update includes a mitigation for local privilege escalation
using
polkit_system_bus_name_get_creds_sync().
For more information, see:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3560
(* Security fix *)
-8<---------------------------------

Also for Slackware current the same issue has already been addressed.

regards Henrik

On Fri, 11 Jun 2021 23:37:53 +0000, John McCue wrote:

> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>> On Fri, 11 Jun 2021 19:28:07 +0000, John McCue wrote:
>>
> <snip>
>
>> This mode of failure doesn't look to me to be related to systemd.
>
> Thanks, wanted to be 100% sure, I suspect/hoping it is a local
> vulnerability

Note that, while the vunerability is "local" to the system, an
attacker can trigger it from within an ssh session. Thus, the
attacker /does not have to be local/ to the system in order to
exploit this attack.

--
Lew Pitcher
"In Skills, We Trust"

Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> writes:

> On Fri, 11 Jun 2021 23:37:53 +0000, John McCue wrote:
>> Thanks, wanted to be 100% sure, I suspect/hoping it is a local
>> vulnerability
>
> The easiest way to get rid of the vulerability is of course to install
> the patch if you are running Stable Slackware 14.2:
>
> -8<---------------------------------
> Mon Jun 7 18:53:49 UTC 2021
> ...
> patches/packages/polkit-0.113-x86_64-3_slack14.2.txz: Rebuilt.
> This update includes a mitigation for local privilege escalation
> using
> polkit_system_bus_name_get_creds_sync().
> For more information, see:
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3560
> (* Security fix *)
> -8<---------------------------------

That's what I did, mechanically, when the update was released but
reading your post got me in a nitpicky frame of mind. Technically, there
is a modestly easier way...

# removepkg -preserve /var/log/packages/polkit-*

So far so good.

But maybe not for everyone. Thought I'd relish in the extra freedom
provided by Slackware's easy going package manager. When would I want
the sort of program that links to things like polkit (and 20 other
desktop libraries probably) to transmit commands to a privileged
process, even if last month's security problem is patched? Is there any
function it serves that isn't better served by doas, su or sudo?

If something breaks I'll at least learn what use polkit has. It doesn't
seem to be needed by emacs, tor-browser, mpv, or ssh, which covers most
of what I do on this computer.

- Mike Sm.

On Mon, 05 Jul 2021 21:24:20 -0400, Mike Small wrote:
> When would I want the sort of program that links to things like polkit
> (and 20 other desktop libraries probably) to transmit commands to a
> privileged process, even if last month's security problem is patched?

My guess is that it is intended for desktop environments, allowing normal
users to point and click to mount USB drives.

> Is there any function it serves that isn't better served by doas, su or
> sudo?

Su assumes that all users know the root password. Sudo needs to be
configured, on a multiuser system you probably do not want every user to
be able to run "sudo bash".

regardss Henrik

On 2021-07-06, Henrik Carlqvist wrote:

>> Is there any function it serves that isn't better served by doas, su
>> or sudo?
>
> Su assumes that all users know the root password.

Arguably, it assumes that every user authorized to use it (to become
root) knows the root password ...

> Sudo needs to be configured, on a multiuser system you probably do not
> want every user to be able to run "sudo bash".

Agreed.

--
----------------------------------------------------------------------
Sylvain Robitaille syl@encs.concordia.ca
Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------

Sylvain Robitaille wrote on 7/8/21 12:25 AM:
> On 2021-07-06, Henrik Carlqvist wrote:

>> Sudo needs to be configured, on a multiuser system you probably do not
>> want every user to be able to run "sudo bash".
>
> Agreed.
>

my first command after a fresh install of any flavor of buntuian is usually
>sudo su

:-)
-rasp

On 2021-07-07, Ralph Spitzner wrote:

> my first command after a fresh install of any flavor of buntuian is
> usually >sudo su

Try that on Slackware, without first configuring sudo to permit it ...

--
----------------------------------------------------------------------
Sylvain Robitaille syl@encs.concordia.ca
Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------

Sylvain Robitaille wrote on 7/8/21 7:58 AM:
> On 2021-07-07, Ralph Spitzner wrote:
>
>> my first command after a fresh install of any flavor of buntuian is
>> usually >sudo su
>
> Try that on Slackware, without first configuring sudo to permit it ...
>
I know, I'm using slackware since '99 :-)
this was coined for these systems *buntu that have no(or a disabled( root pw ....

-rasp

On Thu, 08 Jul 2021 08:37:55 +0200, Ralph Spitzner wrote:

> Sylvain Robitaille wrote on 7/8/21 7:58 AM:
>> On 2021-07-07, Ralph Spitzner wrote:
>>
>>> my first command after a fresh install of any flavor of buntuian is
>>> usually >sudo su
>>
>> Try that on Slackware, without first configuring sudo to permit it ...
>>
> I know, I'm using slackware since '99 :-)
> this was coined for these systems *buntu that have no(or a disabled( root pw ....

"sudo su" is so indicative of a Linux newbie.

Those "in the know" forego the extra process and use
sudo -i
instead.

Lew Pitcher wrote on 7/10/21 7:35 PM:

> "sudo su" is so indicative of a Linux newbie.
>
> Those "in the know" forego the extra process and use
> sudo -i
> instead.
>
You're welcome.
congratulations for being able to read a man page...
on slackware I've never needed, nor used sudo.
So, what do I care about this command or it's options, when I'm just doing someone willing to try linux over Window$ ?
I just need it to apt this and apt that an get out of there without having to type a password a zillion times.

-rasp

On Sat, 10 Jul 2021 21:24:57 +0200, Ralph Spitzner wrote:

> Lew Pitcher wrote on 7/10/21 7:35 PM:
>
>> "sudo su" is so indicative of a Linux newbie.
>>
>> Those "in the know" forego the extra process and use
>> sudo -i
>> instead.
>>
> You're welcome.
> congratulations for being able to read a man page...
> on slackware I've never needed, nor used sudo.
> So, what do I care about this command or it's options, when I'm just doing someone willing to try linux over Window$ ?
> I just need it to apt this and apt that an get out of there without having to type a password a zillion times.

Oh? Did someone get up on the wrong side of the commandline this morning?

On 10.07.2021 at 17:35, Lew Pitcher scribbled:

> On Thu, 08 Jul 2021 08:37:55 +0200, Ralph Spitzner wrote:
>
> > Sylvain Robitaille wrote on 7/8/21 7:58 AM:
> >> On 2021-07-07, Ralph Spitzner wrote:
> >>
> >>> my first command after a fresh install of any flavor of buntuian
> >>> is usually >sudo su
> >>
> >> Try that on Slackware, without first configuring sudo to permit it
> >> ...
> > I know, I'm using slackware since '99 :-)
> > this was coined for these systems *buntu that have no(or a
> > disabled( root pw ....
>
> "sudo su" is so indicative of a Linux newbie.
>
> Those "in the know" forego the extra process and use
> sudo -i
> instead.

Those in-the-know won't even use sudo [1] for starting an interactive
shell, because they will also not accept the sudo default configuration
of requiring only the invoking user's own password.

On my system, sudo requires the target user's password, and I use...

$ su -

.... to get an interactive root shell. (All direct root logins are
disabled here except in single-user maintenance mode, which requires
entering the root password.)

[1] Those in-the-know won't even be running Ubuntu or Mint, for that
matter, because those two distributions [2] are way too focused on
attracting Windows users and placating them in their Windows habits.

[2] They are unfortunately not the only ones, and the fact that most of
the GNU/Linux developers in 2021 [3] grew up on Microsoft Windows
and smartphones isn't exactly helping. ("Those who don't understand
UNIX are doomed to reinvent it — poorly.")

[3] Or 3187 for the worshipers of Our Lady of Discord. :D

--
With respect,
= Aragorn

On Sun, 11 Jul 2021 00:42:38 +0200, Aragorn wrote:
> (All direct root logins are disabled here except in single-user
> maintenance mode, which requires entering the root password.)

How did you configure that? Different /etc/securetty in single-user mode?
Disabling ctrl-alt-f1 in xorg.conf? Some other setting?

regards Henrik

On 12.07.2021 at 05:19, Henrik Carlqvist scribbled:

> On Sun, 11 Jul 2021 00:42:38 +0200, Aragorn wrote:
>
> > (All direct root logins are disabled here except in single-user
> > maintenance mode, which requires entering the root password.)
>
> How did you configure that? Different /etc/securetty in single-user
> mode? Disabling ctrl-alt-f1 in xorg.conf? Some other setting?

I've completely emptied /etc/securetty, which takes care of all local
root logins in any of the normal runlevels, as well as root logins via
the serial port.

The file is not sourced for going to single-user mode, so it still
allows a root login then. Actually, single-user mode doesn't even ask
for a user name — only for the root password — and if you hit Ctrl+D
instead (as prompted) then it'll just return to the default runlevel
(or stay in the default runlevel on systemd-based distributions —
systemd runlevels work slightly differently).

And of course, if you want to disable root logins altogether, then you
will also want to do so in /etc/ssh/sshd_config. Many distributions —
though not all — do allow remote root logins by default, albeit only via
authentication keys. But given how many of those ssh keys are stored on
laptops that get stolen from remote sysadmins, it's no wonder that many
sites are getting compromised.

Much safer to log in with an unprivileged account and then use "su -"
to obtain root privileges. And of course, never allow GUI logins as
root. I don't think Slackware does that,but many distributions do, and
the n00bs are all too eager to go there, mess up their system and then
come to us for help in fixing it. <rolling eyes>

--
With respect,
= Aragorn

On Mon, 12 Jul 2021 10:04:06 +0200, Aragorn wrote:

> On 12.07.2021 at 05:19, Henrik Carlqvist scribbled:
>
>> On Sun, 11 Jul 2021 00:42:38 +0200, Aragorn wrote:
>>
>> > (All direct root logins are disabled here except in single-user
>> > maintenance mode, which requires entering the root password.)
>>
>> How did you configure that? Different /etc/securetty in single-user
>> mode? Disabling ctrl-alt-f1 in xorg.conf? Some other setting?
>
> I've completely emptied /etc/securetty, which takes care of all local
> root logins in any of the normal runlevels, as well as root logins via
> the serial port.
>
> The file is not sourced for going to single-user mode, so it still
> allows a root login then.

Ah, /etc/securetty does not apply in single user mode!

> And of course, if you want to disable root logins altogether, then you
> will also want to do so in /etc/ssh/sshd_config. Many distributions —
> though not all — do allow remote root logins by default, albeit only via
> authentication keys. But given how many of those ssh keys are stored on
> laptops that get stolen from remote sysadmins, it's no wonder that many
> sites are getting compromised.

Yes, allowing ssh login with password for root to a machine with the ssh
port open to internet is only a question of how long time it will take
until the root password has been brute force guessed.

> Much safer to log in with an unprivileged account and then use "su -"
> to obtain root privileges.

Absolutely, the root shell is far to powerful for a daily driver. A tiny
mistake can make a big disaster.

regards Henrik