Shulou(Shulou.com)05/31 Report--

May not know what sudo knowledge, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can gain something.

Everybody knows sudo, right? By default, this tool is installed on most Linux systems and is available for most BSD and commercial Unix variants. However, after talking to hundreds of sudo users, the most common answer I got was that sudo is a tool that complicates life.

There are root users and su commands, so why use another tool? For many people, sudo is just a prefix for administrative commands. Only a handful of people mention that when you have multiple administrators on the same system, you can use the sudo log to see who did what.

So, what is sudo? According to the sudo website:

"sudo allows system administrators to delegate permissions by granting certain users the ability to run certain commands as root or other users, while providing audit records of commands and their parameters."

By default, sudo has a simple configuration, and a rule allows a user or group of users to perform almost all actions (more information can be found in the configuration file later in this article):

% wheel ALL= (ALL) ALL

In this example, the parameters mean the following:

The first parameter (% wheel) defines the members of the group.

The second parameter (ALL) defines the host on which group members can run commands.

The third parameter ((ALL)) defines the user name under which the command can be executed.

The last parameter (ALL) defines the application that can be run.

Therefore, in this example, members of the wheel group can run all applications as all users on all hosts. But even this all-permissible rule is useful because it records who does what on the computer.

Alias

Of course, it not only allows you and your best friend to manage a sharing machine, but also allows you to fine-tune permissions. You can replace the items in the above configuration with lists: user lists, command lists, etc. In most cases, you may copy and paste some of the lists in the configuration.

In this case, aliases can come in handy. Maintaining the same list in multiple locations is error-prone. You can define an alias once, and then use it multiple times. So when you no longer trust an administrator, just delete it from the alias. Using multiple lists instead of aliases, it's easy to forget to remove users from one of the more privileged lists.

Enable features for users of a specific group

The sudo command comes with a number of default settings. However, in some cases where you want to override some of these situations, you can use the Defaults statement in the configuration. In general, these default values are mandatory for each user, but you can narrow the settings to some users based on the host, user name, and so on. Here is an example that system administrators of my generation like to play with: "humiliation". These are just some interesting information when someone enters the wrong password:

Czanik@linux-mewy:~ > sudo ls [sudo] password for root:Hold it up to the light-not a brain in sight! # raise the lamp high, the brain is too small to see [sudo] password for root:My pet ferret can type better than you! # my pet marten is also better than you typed [sudo] password for root:sudo: 3 incorrect password attemptsczanik@linux-mewy:~ >

Because not everyone likes the humor of the system administrator, these humiliating messages are disabled by default. The following example shows how to enable this setting only for experienced system administrators (that is, members of the wheel group):

Defaults! insultsDefaults:%wheel insults

I think the people who thank me for bringing these messages back can't be counted with two hands.

Summary verification

Of course, sudo has more serious functions. One of them is summary verification. You can include a summary of the application in the configuration:

Peter ALL = sha244:11925141bb22866afdf257ce7790bd6275feda80b3b241c108b79c88 / usr/bin/passwd

In this case, sudo examines the application summary before running the application and compares it with the feed stored in the configuration. If there is no match, sudo refuses to run the application. Although it is difficult to maintain this information in the configuration (there are no automated tools for this purpose), these summaries can provide you with an additional layer of protection.

Session record

Session logging is also a little-known feature of sudo. After the demonstration, many people left my speech and planned to implement it on their infrastructure. Why? Because of session logging, you can see not only the name of the command, but also everything that happens in the terminal. You can see what your administrator is doing, or they use shell to access the machine and the log will only show that bash is started.

There is currently a limitation. Records are stored locally, so users can delete their traces if they have sufficient permissions. So stay tuned for upcoming features.

Plug-in

Starting with version 1. 8, sudo has been changed to a plug-in-based modular architecture. By implementing most of the functionality as plug-ins, you can write your own functionality to easily replace or extend the functionality of sudo. There are already open source and commercial plug-ins on sudo.

In my presentation, I demonstrated the sudo_pair plug-in, which is available on GitHub. This plug-in is developed in Rust, which means that it is not so easy to compile and even more difficult to distribute its compilation results. On the other hand, the plug-in provides interesting functionality that requires a second administrator to approve (or reject) commands through sudo. Not only that, if there is suspicious activity, you can track the session on the screen and terminate it.

In a recent demonstration at the All Things Open conference, I made an infamous demonstration:

Czanik@linux-mewy:~ > sudo rm-fr /

Look at the commands displayed on the screen. Everyone held their breath to see if my laptop was destroyed, but it dodged a bullet.

Journal

As I mentioned at the beginning, logging and alerts are an important part of sudo. If you don't check the sudo log regularly, then the log doesn't have much value in using sudo. The tool alerts the events specified in the configuration via email and logs all events to syslog. You can open the debug log to debug rules or report errors.

alert

Email alerts are a bit out of date now, but if you use syslog-ng to collect log messages, sudo log messages are automatically parsed. You can easily create custom alerts and send them to a variety of destinations, including Slack, Telegram, Splunk, or Elasticsearch. You can learn more about this feature from my blog on syslong-ng.com.

Configuration

We talked a lot about sudo features and even saw a few lines of configuration. Now, let's take a closer look at how sudo is configured. The configuration itself is available in / etc/sudoers, which is a simple text file. However, it is not recommended to edit this file directly. Instead, use visudo because this tool also performs syntax checking. If you don't like vi, you can change the editor you want to use by pointing the EDITOR environment variable to your preferred editor.

Before you start editing the sudo configuration, make sure you know the root password. (yes, even on Ubuntu where root users don't have a password by default. Although visudo checks syntax, it is also easy to create a configuration that is syntactically correct and locks you out of the system.

If you have a root password on hand in an emergency, you can also edit the configuration directly. When it comes to sudoers files, there is one important thing to remember: read the file from top to bottom, subject to the final setting. This fact means to you that you should start with the universal setting and put an exception at the end, otherwise, the universal setting will override the exception.

You can see a simple sudoers file based on CentOS below and add the lines we discussed earlier:

Defaults! visiblepwDefaults always_set_homeDefaults match_group_by_gidDefaults always_query_group_pluginDefaults env_resetDefaults env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS" Defaults env_keep + = "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE" Defaults secure_path = / sbin:/bin:/usr/sbin:/usr/binroot ALL= (ALL) ALL%wheel ALL= (ALL) ALLDefaults:%wheel insultsDefaults! insultsDefaults log_output

The file starts by changing multiple default values. Then there is the usual default rule: root users and members of the wheel group have full permissions on the computer. Next, we turn on "humiliation" for the wheel group, but disable them for everyone else. Session logging is enabled on the last line.

The above configuration is grammatically correct, but can you find logic errors? Yes, there is one: the latter generic setting overrides the previous more specific settings, allowing everyone to disable "humiliation". Once the positions of the two lines are swapped, the settings work as expected: members of the wheel group will receive interesting messages, but other users will not.

Configuration management

Once you have to maintain sudoers files on multiple machines, you probably want to centrally manage the configuration. There are two main possible open source approaches. Both have their advantages and disadvantages.

You can use one of the configuration management applications that you can also use to configure the rest of the infrastructure: Red Hat Ansible, Puppet, and Chef all have modules for configuring sudo. The problem with this approach is that updating the configuration is far from real-time. Similarly, users can still edit sudoers files locally and change settings.

The sudo tool can also store its configuration in LDAP. In this case, the configuration changes are real-time and the user cannot mess up the sudoers file. On the other hand, this method also has limitations. For example, you cannot use aliases or sudo when the LDAP server is not available.

New function

A new version of sudo is coming soon. Version 1.9 will contain many interesting new features. The following are the most important planning functions:

The recording service centrally collects session records and has many advantages over local storage:

It is more convenient to search in one place.

Records can be made even if the machine that sent the records is turned off.

Records cannot be deleted by people who want to delete their traces.

Instead of adding new functionality to sudoers, the audit plug-in provides API for the plug-in to easily access any type of sudo log. This plug-in allows you to create custom logs from sudo events using the plug-in.

The approval plug-in does not need to use a third-party plug-in to enable session approval.

And my personal favorite: plug-in Python support, which makes it easy to extend sudo with Python code instead of using C native coding.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.