In the default (unconfigured) configuration, sudo asks for the root password.
This allows use of an ordinary user account for administration of a freshly
installed system. When configuring sudo, delete the two
following lines:
Defaults targetpw
ALL ALL = (ALL) ALL
…
################## EOF ################
Using yast2 to configure sudo, I get a warning:
"This rule is a system rule necessary for the correct functionality of sudo. After deleting it some applications may no longer work. Really delete? Yes ] No ] "
My goal is to have certain users be able to run certain commands with root privileges. When they do this, I want them required to enter the OWN password, and not the root password.
hattons wrote:
> Should I remove this line or not?
the second and third line in my /etc/sudoers file reads: “This file
MUST be edited with the ‘visudo’ command as root. See the sudoers man
page for the details on how to write a sudoers file.” does yours also?
i do not know the answer to your question, but if i were gonna remove
that line to see if it does what you expecte/want, i would have saved
an original copy of the file, read the sudoers man, and used visudo to
do the deed…
visudo let me comment out the line. The problem is that “After deleting it some applications may no longer work” may mean that everything appears to work correctly until I try something new six months from now - after editing /etc/sudoers is long-forgotten.
Changing Defaults targetpw' to Defaults !targetpw’ did what I wanted regarding user authentication using the initiator’s password.
Now I need to figure out if there is a way to use auditd to determine who touched a file while using sudo as root. From reading the documentation, it seems that a process run through sudo as root will not preserve the identity of the initiating user.
The SLE Documentation doesn’t say much about sudo, and most of what it does say is negative.
PolicyKit is an application framework that acts as a negotiator between the unprivileged user session and the privileged system context. Whenever a process from the user session tries to carry out an action in the system context, PolicyKit is queried. Based on its configuration—specified in a so-called “policy”—the answer could be “yes”, “no”, or needs authentication. Unlike classical privilege authorization programs such as sudo, PolicyKit does not grant root permissions to an entire process, following the “least privilege” concept.
Yes, but that isn’t that hard to circumvent if the user has access to sufficiently powerful resources such as vi or emacs. If launching them through sudo makes them appear to be running as root with no indication of who launched them, then the user can shell out with root credentials and do whatever root can do without leaving direct fingerprints. I believe visudo addresses that specific problem, but I’m sure there are other exploits available.
I don’t know how easy it would be to merge the audit logs to figure out who did what when, if there are concurrent sudoers.
Unfortunately the customer requirements are “Audit everything done by root on my Linux servers, and make it as easy to do as it is on Windoze.” Of course they want me to tell them this upfront for an environment I have no futher information about. My response is going to be - in more polite terms - ‘don’t be stupid’. Limit the use of, and access to the root user to a bear minimum. Then audit what other, more restricted admin accounts do.
After looking at sudo, it seems like something to use sparingly, and carefully.