Book Image

Mastering Linux Security and Hardening - Second Edition

By : Donald A. Tevault
Book Image

Mastering Linux Security and Hardening - Second Edition

By: Donald A. Tevault

Overview of this book

From creating networks and servers to automating the entire working environment, Linux has been extremely popular with system administrators for the last couple of decades. However, security has always been a major concern. With limited resources available in the Linux security domain, this book will be an invaluable guide in helping you get your Linux systems properly secured. Complete with in-depth explanations of essential concepts, practical examples, and self-assessment questions, this book begins by helping you set up a practice lab environment and takes you through the core functionalities of securing Linux. You'll practice various Linux hardening techniques and advance to setting up a locked-down Linux server. As you progress, you will also learn how to create user accounts with appropriate privilege levels, protect sensitive data by setting permissions and encryption, and configure a firewall. The book will help you set up mandatory access control, system auditing, security profiles, and kernel hardening, and finally cover best practices and troubleshooting techniques to secure your Linux environment efficiently. By the end of this Linux security book, you will be able to confidently set up a Linux server that will be much harder for malicious actors to compromise.
Table of Contents (20 chapters)
1
Section 1: Setting up a Secure Linux System
8
Section 2: Mastering File and Directory Access Control (DAC)
11
Section 3: Advanced System Hardening Techniques

The security implications of the SUID and SGID permissions

As useful as it may be to have SUID or SGID permissions on your executable files, we should consider it as just a necessary evil. While having SUID or SGID set on certain operating system files is essential for the operation of your Linux system, it becomes a security risk when users set SUID or SGID on other files. The problem is that, if intruders find an executable file that belongs to the root user and has the SUID bit set, they can use that to exploit the system. Before they leave, they might leave behind their own root-owned file with an SUID set, which will allow them to easily gain entry to the system the next time they encounter it. If the intruder's SUID file isn't found, the intruder will still have access, even if the original problem has been fixed.

The numerical value for SUID is 4000, and for SGID...