Snap installs software without user having sudo access

Thank you for your bug report. The auth dialog should prompt you for the password of an user which is admin, are you sure it's prompting for credentials for the current user and not from another admin one?

A dialog box appears. It just shows the Full Name field, and the name shown is "Jason Stover" (login: jason) for the LDAP account. The Local Admin account name is "Jason Local" (login: jlocal).

The passwords between the two accounts is also different incase it was showing the name of the logged in user, but asking for the password of the local account, the passwords wouldn't have matched up.

Could you add a journalctl -b 0 log from a session when you did those actions? Also what happens if you try to snap install a snap from the commandline?

Here's the lines from journalctl -b 0 .... The "sudo" was from me doing: sudo su - ... just prior to the "snap install blender --classic"

--- start cut ---
Nov 05 15:15:39 jms-u18t sudo[18049]: pam_unix(sudo:auth): authentication failure; logname= uid=1031 euid=0 tty=/dev/pts/0 ruser=jason rhost= user=jason
Nov 05 15:15:39 jms-u18t sudo[18049]: jason : user NOT in sudoers ; TTY=pts/0 ; PWD=/home/users/jason ; USER=root ; COMMAND=/bin/su -
Nov 05 15:15:43 jms-u18t gnome-shell[16877]: polkitAuthenticationAgent: Received 3 identities that can be used for authentication. Only considering one.
Nov 05 15:15:46 jms-u18t polkit-agent-helper-1[18065]: pam_unix(polkit-1:auth): authentication failure; logname= uid=1031 euid=0 tty= ruser=jason rhost= user=jason
Nov 05 15:15:46 jms-u18t polkitd(authority=local)[881]: Operator of unix-session:116 successfully authenticated as unix-user:jason to gain TEMPORARY authorization for action io.snapcraft.snapd.manage for unix-process:18050:34595600 [snap install blender] (owned by unix-user:jason)
Nov 05 15:15:46 jms-u18t snapd[860]: api.go:952: Installing snap "blender" revision unset
Nov 05 15:16:02 jms-u18t gnome-shell[16877]: polkitAuthenticationAgent: Received 3 identities that can be used for authentication. Only considering one.
Nov 05 15:16:05 jms-u18t polkit-agent-helper-1[18083]: pam_unix(polkit-1:auth): authentication failure; logname= uid=1031 euid=0 tty= ruser=jason rhost= user=jason
Nov 05 15:16:05 jms-u18t polkitd(authority=local)[881]: Operator of unix-session:116 successfully authenticated as unix-user:jason to gain TEMPORARY authorization for action io.snapcraft.snapd.manage for unix-process:18068:34597431 [snap install blender --classic] (owned by unix-user:jason)
Nov 05 15:16:05 jms-u18t snapd[860]: api.go:952: Installing snap "blender" revision unset
Nov 05 15:16:11 jms-u18t systemd[1]: Reloading.
Nov 05 15:16:11 jms-u18t systemd[1]: Mounting Mount unit for blender, revision 33...
Nov 05 15:16:11 jms-u18t systemd[1]: Mounted Mount unit for blender, revision 33.
Nov 05 15:16:14 jms-u18t audit[18150]: AVC apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap-update-ns.blender" pid=18150 comm="apparmor_parser"
Nov 05 15:16:14 jms-u18t audit[18151]: AVC apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap.blender.blender" pid=18151 comm="apparmor_parser"
Nov 05 15:16:14 jms-u18t kernel: audit: type=1400 audit(1572988574.599:142): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap-update-ns.blender" pid=18150 comm="apparmor_parser"
Nov 05 15:16:14 jms-u18t kernel: audit: type=1400 audit(1572988574.599:143): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap.blender.blender" pid=18151 comm="apparmor_parser"
Nov 05 15:16:15 jms-u18t gnome-shell[16877]: Some code accessed the property 'refreshPropertyOnProxy' on the module 'util'. That property was defined with 'let' or 'const' inside the module. This was previously supported, but ...

Attached is a screenshot of the VM window where the terminal install was done.

Seems to be more appropriate to assign this to snapd than gnome-software.

Addition from change....

$ apt-cache policy snapd
snapd:
  Installed: 2.40+18.04
  Candidate: 2.40+18.04
  Version table:
 *** 2.40+18.04 500
        500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     2.37.4+18.04.1 500
        500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
     2.32.5+18.04 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

snapd asks polkit for the authorization, looking at the log, pokit belives the user is an admin:

ov 05 15:15:46 jms-u18t polkitd(authority=local)[881]: Operator of unix-session:116 successfully authenticated as unix-user:jason to gain TEMPORARY authorization for action io.snapcraft.snapd.manage for unix-process:18050:34595600 [snap install blender] (owned by unix-user:jason)

The policy is defined as follows:

  <action id="io.snapcraft.snapd.manage">
    <description gettext-domain="snappy">Install, update, or remove packages</description>
    <message gettext-domain="snappy">Authentication is required to install, update, or remove packages</message>
    <defaults>
      <allow_any>auth_admin</allow_any>
      <allow_inactive>auth_admin</allow_inactive>
      <allow_active>auth_admin_keep</allow_active>
    </defaults>
  </action>

According to the manual auth_admin means 'Authentication by an administrative user is required'. Any clue why polkit might belive you are an admin user? Perhaps the local policy was tweaked to allow this?

Can you run (this will show a password prompt like during snap installation):

pkcheck -a io.snapcraft.snapd.manage --process $$ -u ; echo $?

My user is in the "admin" group, but that's my LDAP group. /etc/sudoers was changed to have the groups allowed be "sudoA" and "adminA" which my local user is in.

Does the polkit `auth_admin` *NOT* do an actual sudo check but just look at the group name? That's ... not good. I'll need to have some people in the LDAP admin group, but not be allowed to use sudo/install software which that policy defeats the purpose of if that's the case (regulations).

The command above gives:
--- start cut ---
$ pkcheck -a io.snapcraft.snapd.manage --process $$ -u ; echo $?
polkit\56retains_authorization_after_challenge=true
polkit\56temporary_authorization_id=tmpauthz2
0
--- end cut ---

Here's my user info with some company specific info commented out:
--- start cut ---
$ id
uid=1031(jason) gid=500(admin) groups=500(admin),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),116(lpadmin),126(sambashare),501(XXX),502(XXX),503(XXX)
--- end cut ---

And /etc/sudoers ...
--- start cut ---
# egrep '^%[a-z]' /etc/sudoers
%adminA ALL=(ALL) ALL
%sudoA ALL=(ALL:ALL) ALL
--- end cut ---

-J

(Okay... no edit)...

So, I don't have admin access through sudo, but I can still install software on the system. Even software that snap says "may perform arbitrary system changes."

Am I uderstanding this right?

What is the best way to have the behaviour being a sudo check? That's what I would have _thought_ it would be as that's where you specify users the ability to run programs with elevated privileges. Especially if those programs can "perform arbitrary system changes."

-J

I looked at the policy used by PackageKit. I believe gnome-software uses it as a backend, so can you try installing something that is specifically not a snap?

At this point, all snapd does is ask PolicyKit whether given the policy, the user can install a package. PolicyKit responds with yes, therefore the installation can proceed. There's not much we can do inside the declared policy, as the defaults are fine IMO.

From my perspective, this should likely be investigated by someone more familiar with PolicyKit to find out why it's treating your user as admin.

policyKit does not involve sudo in any way, it uses systemd-logind from the session to elevate privileges. if you are marked as admin in the policyKit setup you will indeed be able to do admin things no matter what is written in sudoers ;)

Oliver,

  > if you are marked as admin in the policyKit setup

  Where do you find this? Where is the definition for what `auth_admin` does located? From the freedesktop site it *seems* that it's an "Administrative user," which to me is sudoers. As the system admin I'm not defining an admin user anywhere else but sudoers. If it's just by group that's broken all to hell...

  The freedesktop.org site states[1]:
  > If the system is configured without a root account it may prompt for a specific user designated as the administrative user:

  Where do you designate a user as the administrative user outside of putting them in sudoers?

  I need to implement government regulations. Some users need to be in the admin group from LDAP, but cannot install software on workstations. sudoers *should* control this. The init system has nothing to do with account elevation... unless they're taking that over as well.

  This was a straight up install from Ubuntu. Nothing in my Salt configurations touch polkit settings.

  Since I'm doing LDAP login, there's /etc/pam.d entries in files for LDAP auth that polkit uses. Would this be interfering?

-J

[1] - https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html

I think I may have found it.... It looks like policykit has some rules with entries like:

```
subject.isInGroup("sudo")
```

That's ... broken. Just being in the `sudo` group should *NOT* let me install software or elevate my priviledges, *ESPECIALLY* if the user isn't actually in the sudoers. It's a broken assumption.

I changed the /etc/sudoers file so the `sudo` group does *NOT* have permissions explicitly for this reason.

the requirement for policykit (and dropping of gksu/gksudo) came with the switch to gnome upstream, its a hard requirement for the desktop nowadays.

while the default here might be wrong (and should be reviewed by someone from the desktop team), this is definitely not a snapd related bug. i added a gnome-software task and will close the snapd one ...

The above still stands... but that isn't it for `snap` ... I changed all the `isIngroup("sudo")` to use `sudoA` since that's the actually group that's in sudoers...

And snap is still letting me install the blender snap in `--classic` mode. So.... How do you find out what polkit rules are running at any given time?

The `io.snapcraft.snapd.manage' action has:
```
<allow_any>auth_admin</allow_any>
```

But where is what `auth_admin` does defined? It *looks* like it's seeing it as a local login and just allowing it. If I log in through SSH and try the same command I get:

$ snap install blender --classic
error: access denied (try with sudo)

Being a locally logged in user does not mean you should have the ability to install software. Again, that's an incorrect assumption being made.... :/

The polkit definition of the admin group is in
/etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf

Did you update that file to reflect that your admin group has a different naming?

Thank You!!!

Can you set it like:
```
[Configuration]
AdminIdentities=
```

So *nothing* is considered an Admin?

That file has `unix-group:sudo;unix-group:admin` ... by default from what I can tell. But at least that I know this thing exists and hey, you can elevate privileges without being in sudoers (Ugh... another thing to restrict for regulations).

Does that deal only with the *name* of the group, or what it sees as the GID?

I mean, I can make another user named `bob` with a UID of 0 ... so I'm still effectively root even if I'm logged in as bob. Does this work that way with GID's? Or is it looking explicitly at the name only even if the name is irrelevant is actual system usage?

Meaning, I can have groups named: Admin, AdminA, AdminB, AdminC .... with different members but the same GID. In this way anything on the filesystem owned by the `Admin` group, can be accessed by any of the Admin groups since it's the GID that matters.

Does PolicyKit take GIDs into account, or just the name?

Having no group listed by default would means admin users wouldn't be able to use polkit which is not what we want. https://gitlab.freedesktop.org/polkit/polkit/issues/24 discusses a bit the group checking logic

That's what I want though. I want control through sudoers, not polkit.

The file: /etc/polkit-1/localauthority.conf.d/50-localauthority.conf ... still contains:
```
[Configuration]
AdminIdentities=unix-user:0
```

I don't know why you need to say root is an admin, but whatever it's there... And that *should* be the only admin. No other user should have administrative privileges on their own, without using sudo or becoming root. Full stop.

This isn't for a single desktop home system, but a corporate controlled system. A user that can install software just because they want to isn't going to fly (or pass Government regulations we need to). And not all admins are created equal.

As an addition... If I remove the 51-ubuntu-admin.conf file, when I run `snap install blender --classic`, it pops up a dialog box asking for the "Administrator" password.

Entering roots password will install it.

This is the behaviour wanted. Not install it with only the users authentication.

Not sure whether removing files that came with distro packages is the best idea long term. I think a better option would be to drop in a custom rule that runs before the default ones. As usual ArchWiki has some examples: https://wiki.archlinux.org/index.php/Polkit#Administrator_identities

Specifically, if I'm reading this right, putting the following rule in /etc/polkit-1/rules.d/00-override.rules should be enough:

/* Always authenticate Admins by prompting for the root
 * password, similar to the rootpw option in sudo
 */
polkit.addAdminRule(function(action, subject) {
    return ["unix-user:root"];
});

Having this it's easy to build a package that can be later distributed to other workstations.

Unfortunately it isn't that easy in my case. I need to have every action attempted logged. That will still give it to me, but modifying what's happening by changing what's being requested.

So, if a normal user attempts something, the best case is for it to ask for the users password and fail when they don't have permission to do the action, or the password entered is wrong.

Second best, is to fall back to asking for the root password. I can deal with the logging inaccuracy.

But not always ask for the root password in every case which is what that override will do.

I'm going to be needing to implement some custom polkit/apparmour stuff eventually anyway (now that I've seen this), but this came about as I am not a Debian/Ubuntu person. So I hit something that _shouldn't_ have been happening in my mind (hey, no sudoers access, no way to run as root) ... It threw me that it was happening.

But thanks to everyone for digging into this with me.

Maciej, that looks like javascript polkit and I believe we're staying on the pre-javascript version of polkit.

Thanks