Is there any relevance that can be used to check for “sudo” users in Linux machines?
We tried using the provided relevance on https://bigfix.me/relevance/details/3020373 but it is not returning any results. Not sure if it’s already outdated since it was posted last 2017.
Depends upon what you mean…
The relevance you reference is checking /etc/group for a group named ‘sudo’, which is not a standard (if it ever was).
Generally configuration for sudo is defined in /etc/sudoers as well as optionally multiple include files from /etc/sudoers.d
The files themselves are to a great extent free-form. So it’s probably better to define what you expect to see in your version of the file, and look for things that don’t match.
Here’s an example to look at /etc/sudoers and just return the “real” lines from the files (removing empty lines and comment lines). A default sudoers is actually pretty short -
Q: it whose (it != "" and it does not start with "#") of (it as trimmed string) of lines of files "/etc/sudoers"
A: Defaults !visiblepw
A: Defaults always_set_home
A: Defaults match_group_by_gid
A: Defaults always_query_group_plugin
A: Defaults env_reset
A: Defaults env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS"
A: Defaults env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
A: Defaults env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"
A: Defaults env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"
A: Defaults env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"
A: Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin
A: root%09ALL=(ALL) %09ALL
A: %25wheel%09ALL=(ALL)%09ALLHi Jason,
What we are trying to achieve is to get the usernames of sudo users from a Linux machine.
For Windows, we are using the below relevance to get the Local Admin accounts. Is there any similar relevance like the below for Linux?
(concatenation ", " of (members whose (it as string contains computer name) of local group “Administrators” as string))
“It Depends”.
If you’ve stuck to conventions, you can just check for members of the “wheel” group. By default the wheel group is allowed to run any command via sudo.
But, you could customize sudoers to grant “run any command” permission to other users or groups instead; or to grant “run some specific command” to different groups or users.
Likewise, on Windows, you could customize permissions. If you granted some group enough permissions on the filesystem, registry, and Windows Rights, you could make any account behave like it was an Administrator even if it’s not explicitly in the Administrators group.
Basically, checking “sudoers is in the default config, allowing only ‘root’ and ‘wheel’ members to do things” is one check, and “the ‘wheel’ group has only the members I expect” is another check, and you should implement both.
The lack of a local group inspector for 'nix has long been an annoying gap. Yes, I can use relevance to parse /etc/groups and map UIDs to /etc/passwd, but that’s gross.
(And there’s not an idea for this? I’m gobsmacked.)
Yes, that is indeed gross.
Worse is that when I’ve used Linux in any sizeable deployments, they’re mostly not using /etc/group and /etc/password for user management; they’re bound to Active Directory with either LDAP/Kerberos, or Samba, or another third-party tool; or they’re using NIS+ or any number of other NSS/PAM things.
“most” of these could be made to work generically if one used the NSS libraries, like the getent passwd and getent group commands, but those can lead to two bad trade-offs; most LDAP-kind of things won’t list a user or the user’s groups until they actually try to log in (their NSS libraries use caching, and only cache the things they need).
Certainly could be done but we might have to define a whole suite of ‘expected behavior’ for all kinds of weird cases that are open to debate.
IMO “local group” could mean only /etc/passwd and /etc/groups. Once PAM is involved I’d agree that the splinter cases are possibly-impossible to anticipate.
But then I’d have to agree that the respective utility might be too small to bother.
If it’s not possible to create a property using a relevance, will it be doable to generate a file that will list the sudo users by running a command via action script, and then we can create a relevance to get the contents of the file?
If it’s not possible to create a property using a relevance, will it be doable to generate a file that will list the sudo users by running a command via action script, and then we can create a relevance to get the contents of the file?
This is the approach we are looking into. A local shell script will run on a schedule to parse account with sudo rights then output to a file, with the file then being read by a property.
I’m afraid I dont have a script I can share as I’m not from a Linux sysadmin background but the idea is to leverage Bigfix to deploy the script that someone will develop, create the crontab to run the script on a schedule then use an analyisis to capture machines that have the results scan so only those with the file will process the property to read the file.
I will share the information that we are pulling in for sudoers and hopefully it will help others. One of my team members pulled this together and hopefully it will help someone else. We found when we were investigating that the sudoers file itself didn’t paint the whole picture for administrative privileges, but this data has definitely helped us understand some of our edge cases.
I have uploaded the bes file but here is the data for reference.
//Sudoers File Contents (Single Line)
concatenation " " of substrings separated by “%09” of ((concatenation “;” of (lines whose (it does not start with “#” AND it does not start with “Defaults” AND it as trimmed string != “”) of file “/etc/sudoers” as string)) as string)
//Sudoers File Contents
(lines whose (it does not start with “#” AND it does not start with “Defaults” AND it as trimmed string != “”) of file “/etc/sudoers” as string)
//Sudoers.d Files (Single Line)
concatenation “” of substrings separated by “/etc/sudoers.d/” of (concatenation “;” of ((files of folder “/etc/sudoers.d”) as string))
//Sudoers.d Files
names of files of folder “/etc/sudoers.d”
//Sudoers.d Admins
lines whose (it does not start with “#” AND it does not start with “Defaults” AND it does not start with “Host_Alias” AND it does not start with “Cmnd_Alias” AND it as trimmed string != “”) of (files of folder “/etc/sudoers.d”)
//Sudoers.d Host Aliases
lines whose (it starts with “Host_Alias”) of (files of folder “/etc/sudoers.d”)
//Sudoers.d Command Aliases
lines whose (it starts with “Cmnd_Alias”) of (files of folder “/etc/sudoers.d”)
Linux Sudoers.bes (2.1 KB)