Cyber Security Awareness Month - Day 10 - Standard Sudo - Part Two

Published: 2012-10-10. Last Updated: 2012-10-10 23:12:33 UTC
by Kevin Shortt (Version: 1)
0 comment(s)


It is Day 10 of Cyber Security Awareness Month.  I am continuing with Part Two of my entry from Day 3 on Standard Sudo - Part One.   We will cover some technical implementation options of sudo with pros and cons of the given examples.

Some Sudo Good Ideas

A.  Central Distribution 

   The distribution control of your sudoers file is key to controlling the risk of your UNIX servers.

       1. LDAP [1]

        Cons
            - Large environments may have challenges to update and true up software on all flavors of UNIX;
            - Sudoers LDAP support began with Sudo v1.6.8;
            - LDAP client software is required for Sudo to work with LDAP support;          
            - Potental for a significant work effort to port existing sudo command sets into LDAP sudo schema;    

         Pros
           - May make auditors happy;  
           - Ideal for small start up environments;
           - Opportunities for provisioning teams become easier;

       2. Central Server
 
          - Use/develop a sync mechanism like CVS, rsync, scp, nfs, etc.;

B.  Single File / 1:Many 

Use of ONE standardized sudo command file to be used on every server lightens the distribution burdens. (sync scripts are an easy fix...)   This does come with risks and each environment needs to measure the tolerance of this idea.  The biggest gap to consider is unused sudo commands will likely exist on a server. For intance, if rule to restart the Apache web server was maintained by the UNIX group "webteam" and it existed on every server, then the servers without Apache may not end up with the "webteam" group.  In many cases the process and procedure that already exists will easily dictate whether this is condition is acceptable.

     Cons
        - Requires deliberation of risk; a potential barrier;
       - Potential for unused sudo command sets to be present on any given server; 
       - 1 mistake, Many failures; An undetected critical mistake gets distributed every where.

     Pros
       - May make auditors happy;
       - No minimum version requirement; (if command sets are kept basic)
       - One file to manage; (a potentially large file, but a BIG pro..)
       - Easy distribution; (sync scripts easy to develop)

C.  File Based Command Sets / Few:Many

The #includedir directive was released between Sudo v1.7.1 and v1.7.2 in early 2009.[2]  This feature allows the configuration to be managed with multiple files. For instance, all web/app admin command sets can be placed into a file and distributed separately.  An update to one command set does not necessarily jeopardize remainder of command sets.  This method can easily be 'profiled'. For instance, the sync scripts can keep track of which file is pushed to which server with configuration/list files.  This way, only webservers get the 'web admin' command sets.

      Cons
       - Large environments will need to true up to 1.7.2 or higher; a potentiallly significant effort;
       - Potential for unused sudo command sets to be present on any given server
       - Adds complexity; (not much mind you...)

       Pros
       - May make auditors happy;
       - One file per command set (not per command, but set of commands);
       - Easily profiled;
       - Adds simplicity; (how can that be?! )
       - Easy distribution; (sync scripts easy to develop)
 

D.  Structured Formatting

The idea is to create a XML'ish format of the file using comment hashes (#). A copy of each sudoers file is stored centrally, and each section is managed locally at the central point, and distributed to the remote server as needed. The purpose of standard format (illustarated below) is to provide many opportunities to control, audit, and report on the sudoers environment.

The proposed file can be broken into two or more formatted sections and managed accordingly. My experiences have seen that three sections is best.  It provides flexibility and room for growth.  These sections can be carved and updated with scripting once they are rolled out.  The layout of a standard file can be such with explanation below:

      << standard_OS >>
        << tier1_support>>
            << password resets >>
            << account aging >>
        <</tier1_support>>
        << tier2_support>>
            << account creations >>
            << account mods >>
            << account deletes >>
        <</tier2_support>>
      <</standard_OS >>
      << profiles >>
        << profile_support_group_one>>
           << DBA support commands >>
        <</profile_support_group_one>>
        << profile_support_group_two>>
           << Web Admin support commands >>
        <</profile_support_group_two>>
      <</profiles >>
      << native >>
        << localized rules >>
      <</native >>
 

     Cons
       - Potentially significant effort to implement;
       - Potential for unused sudo command sets to be present on any given server;
       - Adds much complexity;
       - Development effort required to implement;

      Pros
       - May make auditors happy;
       - Creates efficiencies;
       - Provides the following opportunities;
             - Sudoers file integrity checking;
          - Reporting of compliance;
          - Standardized provisioning of new sudo adds;
          - Distribute provisioning responsbilities of sudo mods;
       - No minimum version requirement; (if command sets are kept basic)

 
STANDARD SECTION
A master command set is created that will be needed on EVERY server in your estate. This command set is stored in the "standard" section of every sudoers file. In some environments, the risks are to be considered, and separate standard sections will need to be created for each Operating System in your environement.  The contents of this section will be a technical work of art. The value is solely created by the needs of each environment.
 
   Example:
   #### STANDARD_SOLARIS #### START ####
   #   Standard rules for Tier 1 Support
   #    User need only be added to tier1 unix group to access
   #
   User_Alias STD_SOL_TIER1_USERS = %tier1
   Cmnd_Alias STD_SOL_TIER1_COMMANDS =                \
                /bin/passwd, !/bin/passwd *root*,    \
                /bin/usermod, !/user/usermod *root*, \
                /bin/groupmod
 
   STD_SOL_TIER1_USERS ALL=NOPASSWD: STD_SOL_TIER1_COMMANDS
   #### STANDARD_SOLARIS #### END ####
 
PROFILES SECTION
 
A standard command set is created for each production support team like the Database Administrators, Web Admins, or System Admin's even. The idea however is NOT allow these command sets ON EVERY server.  They would only be needed on a group of servers, as not every server has a database or a web server.
 
   Example:
   #### PROFILES #### START ####
   ##### DBA_PROFILE ##### START #####
   #   Standard rules for the DBA's
   #    User need only be added to dba unix group to access
   #
 
   User_Alias DBA_PROFILE_USER = %dba
   Runas_Alias DBA_IDS = oracle
 
   Cmnd_Alias DBA_CAT_PARENT = /bin/cat *../*
   Cmnd_Alias DBA_PROFILE_COMMANDS =                \
               /bin/cat /u01/path/to/tracefiles/[a-zA-Z0-9]*/tracefiles/*trc \
               /bin/cat /u01/path/to/tracefiles/[a-zA-Z0-9]*/tracefiles/*log \
               /bin/cat /path/to/whatever/file/you/want
 
   DBA_PROFILE_USER ALL=(DBA_IDS) NOPASSWD:DBA_PROFILE_COMMANDS
 
   ##### DBA_PROFILE ##### END #####
   ##### WEBADMIN_PROFILE ##### START #####
   #   Standard rules for the Web Guys
   #    User need only be added to webadmin unix group to access
   #
 
   User_Alias WEB_PROFILE_USER = %webadmin
   Runas_Alias WEB_IDS = nobody
 
   Cmnd_Alias WEB_PROFILE_COMMANDS_AS_ROOT =                \
               /usr/bin/apachectl
 
   Cmnd_Alias WEB_PROFILE_COMMANDS=                \
               /opt/WebSphere/bin/startServer.sh
 
   WEB_PROFILE_USER ALL=(WEB_IDS) NOPASSWD:WEB_PROFILE_COMMANDS
   WEB_PROFILE_USER ALL=(root) NOPASSWD:WEB_PROFILE_COMMANDS_AS_ROOT
 
   ##### WEBADMIN_PROFILE ##### END #####
   #### PROFILES #### END ####
 
NATIVE SECTION
 
The Native section is bit of flexibility worked in to insure you have the ability to support the business. This section is used exclusively for needed sudo commands on that particular server.  It the standard formatting makes this section possible for any scripting to leave this section alone.
 
   Example:
   ##### NATIVE ##### START #####
   # Section reserved for any commands only needed on this server.
   #
   ##### NATIVE ##### END ##### 
  

Summary

In summary, (if you're still with me) the sudo environment in your organization may not be very complicated, thus much of this may seem overkill.  However, there is much listed above to take away to any sized organization.  Sudo solves MANY problems, while creating some high risk ones.  How it is configured, much like everything on your UNIX servers, really matters to the security of your environment.  When sudo is setup and managed in a standard framework, it keeps the risks under control, the efficiencies high, and the auditors happier.  The underlying main message is that no one solution fits all, yet Standard Methods of implementation lower your risks. 

Please keep in mind, I only know what I know. There is always much to learn. Please share any ideas, gaps, or even questions you have about the diary above.  We all benefit from the sharing.

[1] http://www.sudo.ws/sudo/sudoers.ldap.man.html
[2] http://www.gratisoft.us/sudo/maintenance.html#1.7.2

 

-Kevin 

-- 
ISC Handler on Duty

 

 

Keywords: Cyber Security Awareness Month 2012 sudo
0 comment(s)

Comments

Login here to join the discussion.


Top of page
Diary Archives