Network Security Hacks [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Network Security Hacks [Electronic resources] - نسخه متنی

Andrew Lockhart

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید







Hack 6 Delegate Administrative Roles

Let others do your work for you without giving
away root privileges.

The sudo utility can help you delegate some
system responsibilities to other people, without giving away full
root access. It is a setuid root binary
that executes commands on an authorized user's
behalf, after she has entered her current password.

As root, run /usr/sbin/visudo to edit the list
of users who can call sudo. The default
sudo list looks something like this:

root ALL=(ALL) ALL

Unfortunately, many system administrators tend to use this entry as a
template and grant unrestricted root access to all other admins
unilaterally:

root ALL=(ALL) ALL
rob ALL=(ALL) ALL
jim ALL=(ALL) ALL
david ALL=(ALL) ALL

While this may allow you to give out root access without giving away
the root password, this method is truly useful only when all of the
sudo users can be completely trusted. When
properly configured, the sudo utility provides
tremendous flexibility for granting access to any number of commands,
run as any arbitrary uid.

The syntax of the sudo line is:

user machine=(effective user) command 

The first column specifies the sudo user. The
next column defines the hosts in which this sudo
entry is valid. This allows you to easily use a single
sudo configuration across multiple machines.

For example, suppose you have a developer who needs
root access on a development machine,
but not on any other server:

peter beta.oreillynet.com=(ALL) ALL

The next column (in parentheses) specifies the effective user that
may run the commands. This is very handy for allowing users to
execute code as users other than root:

peter lists.oreillynet.com=(mailman) ALL

Finally, the last column specifies all of the commands that this user
may run:

david ns.oreillynet.com=(bind) /usr/sbin/rndc,/usr/sbin/named

If you find yourself specifying large lists of commands (or, for that
matter, users or machines), then take advantage of
sudo's Alias syntax. An Alias
can be used in place of its respective entry on any line of the
sudo configuration:

User_Alias ADMINS=rob,jim,david
User_Alias WEBMASTERS=peter,nancy
Runas_Alias DAEMONS=bind,www,smmsp,ircd
Host_Alias WEBSERVERS=www.oreillynet.com,www.oreilly.com,www.perl.com
Cmnd_Alias PROCS=/bin/kill,/bin/killall,/usr/bin/skill,/usr/bin/top
Cmnd_Alias APACHE=/usr/local/apache/bin/apachectl
WEBMASTERS WEBSERVERS=(www) APACHE
ADMINS ALL=(DAEMONS) ALL

It is also possible to specify
system groups in place of the user
specification, to allow any user who belongs to that group to execute
commands. Just preface the group with a %, like
this:

%wwwadmin WEBSERVERS=(www) APACHE

Now any user who is part of the wwwadmin group can execute
apachectl as the www user on any of the web
server machines.

One very useful feature is
the
NOPASSWD: flag. When present, the user
won't have to enter a
password before executing the
command:

rob ALL=(ALL) NOPASSWD: PROCS

This will allow the user rob to execute kill,
killall, skill, and
top on any machine, as any user, without
entering a password.

Finally, sudo can be a handy alternative to
su for running commands at
startup out of the system
rc files:

(cd /usr/local/mysql; sudo -u mysql ./bin/safe_mysqld &)
sudo -u www /usr/local/apache/bin/apachectl start

For that to work at boot time, the default line root
ALL=(ALL) ALL
must be present.

Use sudo with the usual caveats that apply to
setuid binaries. Particularly if you allow
sudo to execute interactive commands (like
editors) or any sort of compiler or interpreter, you should assume
that it is possible that the sudo user will be
able to execute arbitrary commands as the effective user. Still,
under most circumstances this isn't a problem, and
it's certainly preferable to giving away undue
access to root privileges.

Rob Flickenger


/ 158