Knowledge Base (Posts about sudo)

gksu: Turn warning back on

bgstack15 — Tue, 15 Oct 2024 13:13:00 GMT

Problem

Gksu (yes, the long-gone program throws a notice message if you have sudo NOPASSWD access, indicating you were able to do this operation without a password/authentication. And if you check the box to hide this notice in the future, you won't ever see again.

Solution

Use gconftool-2 to control it. Apparently the gksu uses the slightly-less-deprecated gconf idea (binary registry, sounds familiar? And now replaced with dconf which is different somehow?).

Show the current status.

gconftool-2 --get /apps/gksu/display-no-pass-info

Turn the warnings back on.

 gconftool-2 --set /apps/gksu/display-no-pass-info --type boolean true

Backstory

I was checking on one of my favorite utilities, xdgmenumaker, and it is authored by a guy named gapan. Well, one of his other pinned repositories is salixtools-gtk, which had a nifty user management program. I was setting up a system for an offsite user who will have to manage local users, and I found salixtools-gtk's gtkusersetup program really nice.

I learned that it takes a user with access to /etc/shadow so either a member of Debian group shadow, or some setgid business, or sudo. Or, as the .desktop file for that project suggets, gksu. Which I had forgotten about; I don't normally use root functions from a graphical environment so hadn't needed it. But of course all good things must have ended before I came around, because now "they" want you to use policykit or other loennart-level dumb things.

I got really scared when I couldn't find a ~/.config file for gksu anywhere. Come to find out it's buried in some binary thingy (worse than the xfce4 xml files that only update upon a normal exiting of xfce4) that you can't just use Unixy tools to control. I forget exactly how I learned it was gconf. I think I used strace to read what it was doing or maybe got lucky examining other possible places on my $HOME filesystem. I shouldn't have to search so hard.

Freeipa sudorule all users mount -av

bgstack15 — Sun, 07 Apr 2024 13:00:10 GMT

This rule demonstrates the users category "all" which is deceptively on the sudorule-mod command and not add-user one.

I want my users to be able to get to /mnt/public and some systems (on wireless networks) wait for the user session to start before mounting /mnt/public. And sometimes the autofs daemon is misbehaving, so /net/public (which mounts the same nfs export) isn't always available. Sometimes I just want to run sudo mount -av. If something shouldn't be mounted with that, then use flag noauto in /etc/fstab, but I have decided anything in /etc/fstab is allowed to be mounted by all users.

ipa sudorule-add "all-users-mount-av"
ipa sudorule-add-host "all-users-mount-av" --hostcat="all"
ipa sudorule-mod "all-users-mount-av" --usercat="all"
ipa sudorule-add-runasuser "all-users-mount-av" --users 'root'
ipa sudocmd-add --desc="mount -av" "/usr/bin/mount -av"
ipa sudorule-add-allow-command "all-users-mount-av" --sudocmds "/usr/bin/mount -av"
ipa sudorule-add-option "all-users-mount-av" --sudooption '!authenticate'
ipa sudorule-mod "all-users-mount-av" --desc="all users may run mount -av on any system"

And now a random user can run the comand I've been needing for months!

$ sudo -l -U user1
Matching Defaults entries for public on server8:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty,
    env_keep+="ftp_proxy http_proxy https_proxy no_proxy", env_keep+="FTP_PROXY HTTP_PROXY HTTPS_PROXY NO_PROXY",
    env_keep+="DEBUG DEBUG_LEVEL DRYRUN VERBOSE", env_keep+="DRYRUN VERBOSE", env_keep+="DRYRUN VERBOSE MYA_PREFIX
    DEBUG AUTOMOUNT_USER"

User user1 may run the following commands on server8:
(root) NOPASSWD: /usr/bin/mount -av

Hm, maybe I should clean up the duplicate DRYRUN, VERBOSE flags. Ah well, different problem for a different day.

Ipa sudorule all commands

bgstack15 — Fri, 10 Jun 2022 13:07:58 GMT

It was not the most clear to me how to write a sudo rule with "ALL" as the command set. I'm sure this was documented somewhere offline or on the Internet. Here's my cheat sheet for next time.

To grant user3 access to full sudo access on host server2:

ipa sudorule-add 'user3-server2-root'
ipa sudorule-add-host 'user3-server2-root' --hosts server2
ipa sudorule-add-user 'user3-server2-root' --users 'user3'
ipa sudorule-add-runasuser 'user3-server2-root' --users 'root'
ipa sudorule-mod 'user3-server2-root' --cmdcat='all'
ipa sudorule-add-option 'user3-server2-root' --sudooption '!authenticate'

The big deal is the --cmdcat which is short for command category. So instead of listing specific commands, it is the "ALL" equivalent.

Sudoers policy

bgstack15 — Thu, 27 Dec 2018 13:41:50 GMT

Summary of policy

Full sudo access will not be granted.
Sudo su (switch user) access will be granted to service accounts upon request.
Sudo access to specific commands run as specific users is granted upon request.
Sudo chmod is unnecessary because the owning user can already chmod files.
Sudo chown will be granted when applied to specific directories.

Annotated policy

Full sudo access will not be granted, with exceptions granted only by the Linux Engineering team.
1. Full sudo is what is assumed when users ask for "sudo access" without any qualifiers. Users may not mean this; they might mean sudo su $SHAREDACCOUNT but this cannot be assumed. Requests should be explicit as to what user they should run as, and what commands to run.
2. Exceptions will be granted for development/sandbox environments as approved by the Linux Engineering team.
Sudo su (switch user) access will be granted to service accounts as requested through PARs and approved by the Linux Engineering team.
1. Normal access to servers is through individual user accounts, who then switch user to a shared account to manage files and services. Some teams connect directly as a shared account which is not recommended but outside the scope of this policy.
2. Usage of sudo to switch user, when using rules like the example below, include these commands:
```
    sudo su - apache
```
  sudo su apache sudo -i apache sudo -su apache
Sudo access to specific commands run as specific users is granted as requested through PARs and approved by the Linux Engineering team.
1. Perhaps not shells are needed, but just specific commands run as a different user. Switching users to an interactive shell is normal activity.
Sudo chmod is unnecessary because the owning user can already chmod files.
1. A user should not run chmod against files that are not his because this is an unacceptable escalation of privilege.
Sudo chown will be granted when applied to specific directories.
1. If sudo chown * were to be granted, the user could take over system files and is not permissible.
2. Permissible options involve a specific directory name, with the recursive flag.
[appdeployer ~]$ sudo chown -R appdeployer.appdeployer /opt/appdeployer/v5

The entry in sudoers:

appdeployer hostname = (root) /bin/chown -R appdeployer.appdeployer /opt/appdeployer/v5, /usr/bin/chown -R appdeployer.appdeployer /opt/appdeployer/v5

Definitions

Term	Meaning
Full sudo	sudo su root or any other command that uses sudo to achieve a
root shell
PAR	Permission access request ticket

Example sudoers

DB example

This is an example sudoers file.

# file: /etc/sudoers.d/30_db_dbas_sudo
# managed by ansible
# last updated 2018-12-10 20:11Z

User_Alias DBUSERS = %db_dbas, !db
Host_Alias DBHOSTS = l*dbr*, l*dbr*.ad.example.com, l*dbr*.ipa.example.com
Host_Alias DBHOSTS_DEV = l2*dbr*, l2*dbr*.ad.example.com, l2*dbr*.ipa.example.com
Cmnd_Alias BECOME_CMNDS = /bin/su - db, /bin/su db
Cmnd_Alias DBCMNDS = /bin/ls, /bin/ps
Cmnd_Alias DBCMNDS_DEV = ALL

# Users may switch to shared local user
Defaults:DBUSERS !authenticate
DBUSERS DBHOSTS = (root) BECOME_CMNDS
DBUSERS DBHOSTS = (db) ALL

# Local user may run these commands
Defaults: db !authenticate
db DBHOSTS = (root) DBCMNDS
db DBHOSTS_DEV = (root) DBCMNDS_DEV

Webstats example

Another example

# file: /etc/sudoers.d/60_webstats
# managed by ansible
# last updated 2019-01-29T13:12Z
User_Alias WEBSTATSUSERS = %webstats_linux@EXAMPLE.COM
Host_Alias WEBSTATSHOSTS = webstats1*,webstats1*.example.com
Cmnd_Alias WEBSTATSCMNDS = /bin/su - htdocs, /bin/su htdocs, /usr/bin/top *

Cmnd_Alias NGINX_CMNDS = /bin/systemctl start nginx.service, /bin/systemctl restart nginx.service, /bin/systemctl stop nginx.service, /bin/systemctl reload nginx.service, /bin/systemctl status nginx.service, /bin/systemctl enable nginx.service, /bin/systemctl disable nginx.service, /bin/systemctl start nginx, /bin/systemctl restart nginx, /bin/systemctl stop nginx, /bin/systemctl reload nginx, /bin/systemctl status nginx, /bin/systemctl enable nginx, /bin/systemctl disable nginx
Cmnd_Alias PHP_CMNDS = /bin/systemctl start php56-php-fpm.service, /bin/systemctl stop php56-php-fpm.service, /bin/systemctl restart php56-php-fpm.service, /bin/systemctl status php56-php-fpm.service, /bin/systemctl enable php56-php-fpm.service, /bin/systemctl disable php56-php-fpm.service, /bin/systemctl start php56-php-fpm, /bin/systemctl stop php56-php-fpm, /bin/systemctl restart php56-php-fpm, /bin/systemctl reload php56-php-fpm, /bin/systemctl status php56-php-fpm, /bin/systemctl enable php56-php-fpm, /bin/systemctl disable php56-php-fpm
Cmnd_Alias EXTRA_CMNDS = /usr/bin/top *, /usr/local/bin/wsprodapp-permissions.sh, /bin/systemctl daemon-reload, /usr/bin/chown -R htdocs.htdocs /mnt/wsprodapp, /usr/bin/chmod -R u+rwX\,g+rwX /mnt/wsprodapp
Cmnd_Alias HTDOCSCMNDS = NGINX_CMNDS, PHP_CMNDS, EXTRA_CMNDS

# Users may switch to htdocs
WEBSTATSUSERS WEBSTATSHOSTS = (root) WEBSTATSCMNDS
WEBSTATSUSERS WEBSTATSHOSTS = (htdocs) ALL

# htdocs may run these commands
Defaults:htdocs !authenticate
htdocs WEBSTATSHOSTS = (root) HTDOCSCMNDS
User_Alias KUBUSERS = %container_sudoers@AD.EXAMPLE.COM, %containers
Runas_Alias KUBRUNAS = root, containers
Host_Alias KUBHOSTS = k8s*,k8s*.example.com
Cmnd_Alias KUBCMNDS = /usr/bin/docker *, /bin/systemctl start docker.service, /bin/systemctl start docker, /bin/systemctl stop docker.service, /bin/systemctl stop docker, /bin/systemctl restart docker.service, /bin/systemctl restart docker, /bin/systemctl reload docker.service, /bin/systemctl reload docker, /bin/systemctl enable docker.service, /bin/systemctl enable docker, /bin/systemctl disable docker.service, /bin/systemctl disable docker, /bin/systemctl status docker.service, /bin/systemctl status docker, /bin/systemctl daemon-reload, /bin/su containers, /bin/su - containers
KUBUSERS KUBHOSTS=(KUBRUNAS) NOPASSWD: KUBCMNDS

Full sudo

If the Linux Engineering team grants full sudo access, it can be done in this way.

# FS_RUNDECK_USERS is for Full Sudoers
User_Alias FS_RUNDECK_USERS = %appgroup1, %appgroup2
Host_Alias FS_RUNDECK_HOSTS = rundeck*, rundeck*.example.com
Cmnd_Alias FS_RUNDECK_CMNDS = /bin/su, /bin/su - root, /bin/su -
Runas_Alias FS_RUNDECK_RUNAS = root

FS_RUNDECK_USERS FS_RUNDECK_HOSTS = (root) FS_RUNDECK_CMNDS
FS_RUNDECK_USERS FS_RUNDECK_HOSTS = (FS_RUNDECK_RUNAS) ALL

Guidelines for sudoers.d/ filenames

Best practice for sudoers.d/ files is to have them sorted numerically. The company uses number ranges between 00 and 99.

10_low_level_sudo
20_linux_admins_sudo
60_application_group_sudo

Audit sudo docker usage

bgstack15 — Sat, 28 Oct 2017 13:32:45 GMT

tl;dr

grep -E "sudo:.*docker.*exec.*" /var/log/secure | grep -vE -- "(-u|--user)"
grep -E "sudo:.*docker.*exec.*" /var/log/secure | grep -E -- '(-u|--user)\s*root'

Explanation

One way to secure docker is to allow users to run it with sudo. Alternatively, you can add users to a group named "docker," but this doesn't provide the auditing that sudo has by default. So you can whip up a nice, neat little sudoers.d file similar to:

User_Alias CONT_POC_USERS = %container_sudoers@ADDOMAIN
Runas_Alias CONT_POC_RUNAS = root
Host_Alias CONT_POC_HOSTS = cn-node-5*, cn-node-5*.example.com
Cmnd_Alias CONT_POC_CMNDS = /usr/bin/docker *
CONT_POC_USERS CONT_POC_HOSTS=(CONT_POC_RUNAS) CONT_POC_CMNDS

With a security posture where you will not allow anything to run in a container as root, you can audit compliance with a few regular expressions.

grep -E "sudo:.*docker.*exec.*" /var/log/secure | grep -vE -- "(-u|--user)"
grep -E "sudo:.*docker.*exec.*" /var/log/secure | grep -E -- '(-u|--user)\s*root'

I haven't figured out how to have the negative and positive searches in one string, so any input there would be appreciated! Also, I have not figured out how to actually enforce running the docker exec command only with a -u username flag, without writing a much more complicated whitelist of docker build , docker commit , docker container *, docker cp * et al statements which seems like a lot of work but might ultimately be necessary.

Find used files in /etc/sudoers.d/

bgstack15 — Mon, 23 Oct 2017 20:02:44 GMT

Sudo, when given the #includedir /etc/sudoers.d/ directive, will read files in that directory. According to its man page, it does not interpret files whose names include a dot or end with a tilde ~. You can list the files that are available for sudo to interpret with this statement:

find /etc/sudoers.d/ -type f ! -regex '\/etc\/sudoers\.d\/.*\..*'  ! -regex '\/etc\/sudoers\.d\/.*~'

sudoers Match AD group

bgstack15 — Tue, 01 Nov 2016 15:12:40 GMT

Using AD groups in sudoers

When you need to add an Active Directory group to the sudoers, you need to know a few things. I learned from the sudoers man page that alias names can only be in capital letters, numbers, and underscores. Also, when you use an AD group in a sudoers file (in my case, /etc/sudoers.d/70_web-dev_grp), you prepend the group name with a percent sign. Also, I'm pretty sure you need to have the casing of the group name exactly correct, but I haven't tested other casings and don't plan to. If you know anything about this, comment and let me know! User_Alias WEBDEVGRP = %Web-dev_grp WEBDEVGRP ALL=(ALL) /sbin/apachectl

Reference

http://serverfault.com/questions/436037/sudoers-file-allow-sudo-on-specific- file-for-active-directory-group/444875#444875

Solve sudo sending useless emails "problem with defaults entries"

bgstack15 — Mon, 06 Jun 2016 19:34:32 GMT

sudo problem with defaults entries

I ran into a problem on my Ubuntu 16.04 Server LTS instance. Whenever a user (whether sssd-ad authenticated user, or local user, or root) uses sudo, it works. But it also sends the administrator a useless email:

host1.example.com : Jun  6 14:40:44 : root : problem with defaults entries ; TTY=pts/2 ; PWD=/root ;

I started removing the defaults entries in /etc/sudoers (using the visudo) command one by one, but after removing them all it still sent the annoying emails. Here are the defaults I was working from:

Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

How do I make sudo stop sending me useless emails?

This problem is caused by sudo looking for directives in a place it cannot find them: sss. Check the /etc/nsswitch.conf file and modify the sudoers entry.

sudoers:        files **sss**

The sss should not be there. The sssd-ad package adds itself there, but very few environments store sudoers directives in sss. It's far more likely your directives are local, so you should have a /etc/nsswitch file entry like the following:

sudoers:        files

References

A user of RHEL6 had the same issue. https://bugzilla.redhat.com/show_bug.cgi?id=879633 The issue is solvable, including on Ubuntu 16.04 https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1249777