Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Discover millions of ebooks, audiobooks, and so much more with a free trial

From $11.99/month after trial. Cancel anytime.

Sudo Mastery: IT Mastery, #13
Sudo Mastery: IT Mastery, #13
Sudo Mastery: IT Mastery, #13
Ebook306 pages3 hours

Sudo Mastery: IT Mastery, #13

Rating: 0 out of 5 stars

()

Read preview

About this ebook

Sudo: You're Doing It Wrong

Unix-like operating systems use a rudimentary access control system: the root account can do anything, while other users are peasants with only minimal access. This worked fine in UNIX's youth, but now that sysadmin responsibilities are spread among many people and applications, many people need a tiny slice of root's power.

Sudo lets you divide root's monolithic power between the people who need it with accountability and auditability.

Sudo Mastery will teach you to:

  • design a secure sudo policy
  • simplify policies with lists and aliases
  • manage shell environments
  • verify system integrity via intrusion detection
  • deploy a single sudo policy across your enterprise
  • manage sudo policies via LDAP
  • log and debug sudo
  • record and replay full sudo sessions
  • use authentication systems other than passwords

Master sudo with Sudo Mastery!

LanguageEnglish
Release dateAug 20, 2019
ISBN9781393557845
Sudo Mastery: IT Mastery, #13
Author

Michael W Lucas

Michael W Lucas lives in Detroit, Michigan. He is the author of several critically-acclaimed nonfiction books and assorted short stories. His interests include martial arts and Michigan history.

Read more from Michael W Lucas

Related to Sudo Mastery

Titles in the series (17)

View More

Related ebooks

System Administration For You

View More

Related articles

Reviews for Sudo Mastery

Rating: 0 out of 5 stars
0 ratings

0 ratings0 reviews

What did you think?

Tap to rate

Review must be at least 10 words

    Book preview

    Sudo Mastery - Michael W Lucas

    Sudo Mastery

    2nd Edition

    by Michael W Lucas

    Table of Contents

    Title Page

    Acknowledgements

    Chapter 0: Introduction

    What Is Sudo?

    What’s Wrong with Sudo?

    What Does Sudo Protect You From?

    Sudo Terms and Support

    Prerequisites

    Who Should Read This Book?

    Learning Sudo

    Avoiding Sudo

    What Groups Am I In?

    Programs versus Groups

    Eliminating Root

    Book Overview

    Chapter 1: Sudo Essentials

    sudo 101

    Sudo Features

    Running Commands as Another User

    Running Commands as Another Group

    Changing Usernames but Keeping Your Groups

    Viewing Your Sudo Privileges

    Reading Sudoers

    Multiple Entries

    Permitting Commands as Other Users

    Special Characters

    Reading the Policy

    Chapter 2: Managing Sudoers

    Creating Sudoers

    Visudo Editors

    Testing and Verifying Sudoers

    User Access Testing

    Testing for Automation and Distribution

    Including Files in Sudoers

    Including Individual Files

    Including Directories

    Chapter 3: Lists and Aliases

    Wildcards

    Matching Individual Numbers and Characters

    Matching Directories

    Matching Everything

    Wildcard Dangers

    Blocking Everything

    Aliases

    User Lists and Aliases

    Operating System Groups

    User ID

    Group ID

    Netgroup

    Non-Unix Group

    Non-Unix Group ID

    User Aliases

    Hosts, Host Lists and Aliases

    IP Addresses

    Netgroups

    Host Aliases

    RunAs Lists and Aliases

    RunAs Lists

    RunAs Aliases

    Command Lists and Aliases

    Command Aliases

    Command Tags

    Excess Rules

    The Command Alias ALL Is Dangerous

    Allowing All Legitimate Commands

    Negation in Lists

    Aliases in sudo(8)

    Chapter 4: Options and Defaults

    Defaults

    Option Types

    Boolean Options

    Integer Options

    Integers Usable in a Boolean Context

    String Options

    Setting Options for Specific Contexts

    Per-User Defaults

    Per-Host Defaults

    Per-Command Defaults

    Per RunAs Defaults

    Conflicting Defaults

    Options and Lists

    Chapter 5: Shell Escapes, Editing, and Policies

    Forbidding Commands from Executing Commands

    Editing Files

    Configuring Sudoedit

    Using Sudoedit

    Symlinks and Directory Ownership

    Policies and Commands

    Chapter 7: Configuring Sudo

    Sudo’s Default Configuration

    sudo.conf

    Sudo Core Dumps

    Plugins

    Plugin Path

    Installing Plugins

    Configuring the Sudoers Policy

    Chapter 8: Environments

    Sudo-Specific Environment Variables

    Dangerous Environment Variables

    Execution Environment

    Environment Variable Filtering

    Preserving Environment Variables

    Sanitizing Environment Variables

    Sudo’s Standard Shell Environment

    Keep Nothing

    Setting the Environment for One Rule

    Retaining the User Environment

    Discarding Environment Variables

    Environment Option Priority

    Allowing User Overrides

    Target User Environment

    Environment Customization

    Adding Environment Variables

    Managing PATH

    Managing HOME

    Managing Pagers

    Running Shells with Sudo

    Terminals and Graphic Interfaces

    No Terminal

    Requiring a Terminal

    Backgrounding Commands

    Timeouts

    Timeouts as Soft Policy Enforcement

    User Timeouts

    Chapter 9: Intrusion Detection

    Digest Algorithm

    Generating Digests

    Digests in Sudoers

    Multiple Operating Systems

    Automating Checksum-Aware Sudoers

    Creating Command Aliases with Checksums

    Creating a Master Alias

    Custom Aliases

    Putting It All Together

    Chapter 10: Policy Distribution

    Global Policy Hints

    Hostnames and Sudoers

    DNS and Sudoers

    IP Addresses

    One Network, One Sudoers

    Transforming and Filtering Sudoers

    A Sample Policy

    cvtsudoers Output Format

    Filtering by Host, User, or Group

    Expanding Aliases

    The cvtsudoers Config File

    Chapter 11: Security Policies in LDAP

    Prerequisites

    The Sudo Schema

    Adding Sudo to Traditional OpenLDAP

    OpenLDAP with Online Configuration

    Adding Sudo to Active Directory

    The Policy Container

    LDAP Sudo Policies versus Sudoers

    Transforming Sudoers to LDIF

    Sudo Rules in LDIF

    Sudo Rules and Roles

    sudoUser

    sudoHost

    sudoCommand

    sudoOption

    sudoRunAsUser

    sudoRunAsGroup

    sudoOrder

    Activating LDAP in sudo(8)

    Finding the LDAP Policy

    Tell sudo To Use LDAP

    Disabling Sudoers

    Migrations and Learning SudoRoles

    LDAP Caching

    Chapter 12: Logging, Mail, and Debugging

    Syslog

    Customizing Sudo Syslog

    Syslog Security

    Email

    Sending Mail

    Setting Email Conditions

    Mail Tags

    Debugging Sudo and Sudoers

    Subsystems and Levels

    Configuring Debug Logging

    Debug Usefulness

    Complete Session Logging

    I/O Log Directory

    Enabling I/O Logging

    Listing I/O Logs

    Viewing Individual Sessions

    Altering Playback

    Real Time Monitoring

    Searching I/O Logs

    I/O Log Rotation

    Chapter 13: Authentication

    Password Management and Failure

    Password Attempts and Timeouts

    Alternate Passwords

    Failure Responses

    Customizing the Password Prompt

    Custom Prompts via Policy

    User Prompt Customization

    Effective and Expiration Dates

    Selectively Disabling Authentication

    Authentication Caching and Timeouts

    Configuring Timeouts

    Erasing Timeouts

    Multi-Session Authentication

    Authentication, Updates, and Queries

    Lecturing Users

    PAM and Sudo

    Prerequisites

    Configuring PAM

    authorized_keys Location

    Afterword

    Patronizers

    Sponsors

    Print Sponsors

    Ebook Sponsors

    About the Author

    Copyright Information

    Acknowledgements

    The first edition isn’t pining, it’s passed on! The edition is no more! It has ceased usefulness! It’s gone to meet the recycler! It’s remaindered! Bereft of readers, it rests in peace! THIS… is an ex-book!

    There are many reasons to do a second edition of Sudo Mastery: the replacement of sudo2ldif with cvtsudoers, new options, changes in the technology environment, and my own deeper understanding of sudo. Honesty compels me to confess that sudo’s addition of Monty Python insults, giving me an opportunity to start each chapter with a mangled Python quote, probably weighed more heavily in this decision than it should have. The person who helped me come up with the quotes, there are some who call him… Tim.

    Before publication, this book was reviewed for technical accuracy by Ron Collinson, Trix Farrar, Thomas Harrison, Dwayne Hart, Ed Neville, Daniele Palumbo, Carsten Strotmann, and Grant Taylor. While I appreciate my technical reviewers, all errors in this book are mine. Reviewers who want blame for errors should go make their own.

    Thanks also to Todd Miller, who has the Sisyphean task of maintaining sudo across dozens of platforms.

    XKCD fans should note that the author does not particularly enjoy sandwiches. Miod Vallat, currently comfortably ensconced in France, would really like a sandwich with nice fresh bread, really good mustard, and low-carb ground glass and rusty nails. It’s unlikely that I’ll get to France any time this decade, so if you could help him out I’d appreciate it.

    I apologize for the fault in the book design. Those responsible have been sacked. The chapters have been numbered in an entirely different style at great expense and at the last minute.

    For Liz.

    Chapter 0: Introduction

    He's not root, he's a very naughty boy.

    Resolved: controlling a user’s access to a computer’s privileged programs and files is a right pain. The few systems that could more or less cope with mapping real-world privileges onto digital schemes didn’t survive. The best access control systems in popular operating systems merely inflict less torment than the others.

    The most widespread operating system these days is Unix, which controls programs and file access through users and groups. Each individual user has a unique username, and usernames are arranged into uniquely named groups. Specific users and groups get permission to access specific files and programs. This scheme was developed decades ago, when a large university might have a couple of UNIX servers. Hundreds of users logged onto each server for mail, Usenet, and other computation-heavy applications. Students went in one group, grad students in another, then professors, staff, and so on. Individual classes and departments might have their own groups.

    Among all those accounts, root is special. The root account has ultimate control of the system. To protect the host, Unix restricts some programs so that only root can run them. Only root can reconfigure the network, mount filesystems, and restart programs that attach to privileged network ports. Only root can add new users. This made sense when a whole university campus might have only one or two computers—reconfiguring the network or adding storage is a serious task in that environment. Management of multimillion-dollar systems that thousands of people rely on should remain in trusted, skilled hands.

    Today, instead of a single UNIX™ we have untold Unixes, several BSDs, innumerable Linuxes, and similar-but-not-quite-Unixy variants. For ease of reference I’ll call the whole family Unix, even though that’s not strictly accurate. Anyone reading this introduction probably has a few Unixes in their home and one on their belt. Teams of people might share sysadmin tasks, or one person might completely control each system, or anything in between. Our security requirements are completely different from twentieth-century universities.

    Large organizations with many servers often divide sysadmin responsibilities between skilled individuals. One person might be responsible for the care and feeding of the operating system, while a second person handles the server’s primary application. The server supports the application, and the application is the reason the server exists. Both people must perform tasks that require root-level privileges.

    The problem is, root access is all-or-nothing. Unix doesn’t differentiate between access to change the kernel and "access to install and upgrade applications in /opt." An application administrator with root access can change the kernel and adjust filesystems.

    Many small teams rely on gentleman’s agreements to only touch the parts of the system each person is responsible for. Such agreements decay exponentially with the number of people involved. Two people can just about keep things straight. Once you have a sysadmin team and a DBA team, such agreements start off with finger-pointing and devolve into bloodbaths. Sometimes the resulting debacles are not the fault of anyone in the organization; I’ve seen more than one disaster trace back to a vendor-provided script that committed unspeakable acts upon a helpless server.

    Organizations need finer-grained access control than root provides.

    The all-or-nothing model breaks down even more when everyone has a Unix system. Setting aside the innumerable phones and tablets specifically engineered for user-friendliness, many of us run Unix on a desktop or laptop. Every time you access a USB drive or use a coffee shop wireless network, something on the system needs root-level privileges. Becoming root isn’t terribly onerous on your own system—log in as yourself, use su(1) to switch users, enter the root password, run your privileged commands, and exit the root account. Performing this ritual every time you put in a USB drive, bounce the network, restart or reconfigure software, or install new packages gets annoying. Add-on tools like automounters and network managers help, but configuring them requires—wait for it—root privileges.

    The computer industry is full of really smart people who have expanded the classic Unix access control model. One method is through setuid and setgid programs. While programs normally work with the privileges of the user who runs them, setuid and setgid set their effective user and group ID to some other user. Many setuid programs run as root. Changing your password requires editing secure files in /etc, so passwd(1) is setuid root. Intruders really like setuid and setgid programs, and gleefully exploit any flaws in them to achieve illicit root access. Most programmers don’t have the level of skill needed to truly lock down setuid and setgid programs, and on some platforms such security is nearly impossible. Additionally, most operating systems don’t let you make shell scripts setuid.

    We also have several varieties of access control list (ACL) that more broadly expand the user-group-others ownership model. ACLs allow you to set highly customized file and command ownership. This person owns the file, but these people and these groups—except for these folks, unless they’re specifically given permission earlier—can modify it, and these other people and groups—with their own exclusions—can execute it, while read access is restricted to these people and groups… And of course, all these different ACL implementations are ever so slightly incompatible. NFSv4 ACLs were designed to be interoperable with Microsoft’s NTFS ACLs. The specification is over 107,000 words long—and they still didn’t manage complete compatibility. At this point the sysadmin starts contemplating a career cleaning up real sewage instead of the metaphorical kind. Very few people can implement ACLs on a single platform, and deep expertise in one ACL system isn’t completely applicable to other platforms. ACLs have a place in systems administration, and they’re invaluable if you really need them. But most of us try really, really hard not to need them.

    Sadly, access control lists are about as good as it gets.

    That’s why the world has settled on sudo.

    What Is Sudo?

    Sudo is a program that allows conditional escalation of user privilege. The system owner creates a list of commands that each user can run. When the user wants to run a command that requires root, he asks sudo(8) to run the command for him. Sudo consults its permissions list. If the list grants the user permission to run that command, sudo runs the command as root. If the user does not have permission to run the command, sudo informs him. Running sudo does not require the root password, but rather the user’s own authentication credentials. (SUSE Linux uses a special configuration to require the root password for sudo, but they’re the exception.)

    Sudo lets the sysadmin delegate root privileges to specific people for very specific tasks. She can tell sudo to require authentication for some users or commands and not for others, or only on certain machines, all with one configuration file.

    Many enterprise software suites, like PostgreSQL, require running commands under a specific dedicated account. Users must switch to this account before managing certain core functions. You can configure sudo to permit users access to this account, or to only permit them to run certain specific commands as this user. Maybe your junior DBA needs access to dump the database, while the lead DBA needs a full-on shell prompt as the database account. Sudo lets you do that.

    Finally, sudo logs everything everybody asks it to do. It can even record the contents of individual sudo sessions, showing you exactly who broke what.

    What’s Wrong with Sudo?

    If sudo is so great, why doesn’t everybody use it?

    Sudo adds another layer of system administration. That layer demands time, energy, and attention. It requires learning yet another danged program when you already have too much to do. If you’re responsible for running an organization with several groups of administrators, investing in learning and deploying sudo will dramatically reduce your workload and inter-group problems.

    Some

    Enjoying the preview?
    Page 1 of 1