Protective partitioning

There are a number of common attacks/exploits in Linux (and UNIX) that can be reduced in risk and significance with a proper directory and partition structure.

One of the most common denial of service attacks is to fill up the disk space with junk data, this can also happen unintentionally with software that experiences a problem. This doesn't do you any good however if someone can force a legitimate application to generates massive amount of log files and feel the /var subsystem

The next big attack that takes advantage of disk setup would be /tmp races, and core dumps, programs that create links or files improperly without checking to make sure they exist first, especially programs that run as root. An attacker can then link /tmp/foo to /etc/passwd and potentially add a user account, wipe the password database out, and so on.

Mounting options can be used to mount a partition read only, not allow execution of programs, not to allow devices and other useful things. See Protective partitioning

You may encounter difficulties when using these options however, for example if you mount /usr as read only you will have not to forget to remount it before running updates. Also you need to move /usr/local to /opt as some programs in /usr/local write to this partition. It's not big deal just additional discipline, but still adds to the complexity of the system. More or less harmless options that do increase security are "nosuid" (no setuid or setgid files), "noexec" (no executables) and "nodev" (no device files).

So with this in mind we have can propose several guidelines:

• Put filesystems that users can write to on separate partitions
• Restrict content of filesystems with critical system partitions using "nosuid" (no setuid or setgid files), "noexec" (no executables) and "nodev" (no device files). 
• Consider mounting some partitions with system binaries (/usr/bin is the primary candidate).

Instead of jumping thou the hoops with read-only protection (which is actually very tricky for directories like /etc you can just check key files and overwrite changed files from a tarball or CD-based read-only "baseline". All changes need to be coped to this CD/tarball as well.

Example of RHEL5 protective partitioning

The idea is to minimize privileges via mount options. Among typical measure we can mention( Hardening Red Hat Enterprise Linux 5):

• Noexec on everything possible
• Nodev everywhere except / and chroot partitions
• Nosuid everywhere except /
• Consider making /var/tmp link to /tmp, or maybe mount –bind option

A example of "privilege minimized" /etc/fstab from RHEL recommendations:

LABEL=/ / ext3 defaults 1 1

LABEL=/tmp /tmp ext3 defaults,nosuid,noexec,nodev 1 2

LABEL=/var/log/audit /var/log/audit ext3 defaults,nosuid,noexec,nodev 1 2

LABEL=/home /home ext3 defaults,nosuid,nodev 1 2

LABEL=/var /var ext3 defaults,nosuid 1 2

LABEL=/boot /boot ext3 defaults,nosuid,noexec,nodev 1 2

/tmp /var/tmp ext3 defaults,bind,nosuid,noexec,nodev 1 2

tmpfs /dev/shm tmpfs defaults 0 0

devpts /dev/pts devpts gid=5,mode=620 0 0

sysfs /sys sysfs defaults 0 0

proc /proc proc defaults 0 0

LABEL=SWAP-sda6 swap swap defaults 0 0

Besides having separate partitions for the obvious, such as SWAP and /tmp, defensive partitioning presuppose usage of ro and nosuid mounting flag and using enough separate partitions to accommodate distinct classes of application and human users. Intruders might try to create excessive generation of logging data or fill your file system with large files through FTP or mail spool or install SUID programs. Any intelligent partition scheme depends on the how the machine is used. The basic rules are:

• From a security point of view, it makes sense to try to move static data to its own partition, and then mount that partition read-only. Or even put the data on read-only media. See below for more details.
• Any other partition which contains files that are writable by a regular user and thus can be used for DoS, e.g. /var (especially /var/log) should also be on a separate partition.
• Any directory tree on which a user has write permissions to, such as e.g. /home and /tmp, should be on a separate partition. This reduces the risk of a user DoS by filling up your "/" mount point and rendering the system unusable.
• Major directories used by applications that are the main applications on the server (for example mail server or http server, typically /srv/www) should be a separate partitions. For example in the case of mail server it is important to have a separate partition for the mail spool.

Here are specific recommendations based on a typical Unix partitioning scheme:

• The root partition / can be small because it generally contains just the kernel-the necessary files, libraries, and configuration for booting in /bin, /sbin, /etc, and /lib. Access to the attached devices is provided through the /dev and /devices directories. Most Linux distributions store kernels and symbol data in the /boot directory, whereas kernel libraries are stored under /lib.
• The /usr partition is normally where user-accessible applications are stored. Normally, /usr with the notable exception of /usr/local does not contain data or configuration files that change; therefore, as an added security measure you can create a symbolitic link from /usr/local to /opt and mount it as read-only.
• The /var partition stores system logs and data services such as mail, Web, databases, printing, running services, package management, and so on. It should be large enough for you to detect problems if logs are growing really fast due to DoS or some bug.
• The /usr/local directory structure, and the /opt directory, often contains locally installed optional software, configuration files, and data.
• /home partition should be separated into two (for example /home and /appshome) if it contains applications accounts. In should be mounted with the nosuid option. In case of critical application that requires suid programs in its home directory for such programs should be linked from a separate partition or a separate partition can be used.
• /opt directory should be a separate partition and it should be used for all non-distribution software
• /usr/local is normally not affected by operating system upgrades and generally should be be linked to /opt. For example /usr/local can be a symbolic link to /opt.

Also, for partitions in which you cannot be sure of the needed space, installing Logical Volume Manager (lvm-common and the needed binaries for your kernel, this might be either lvm10, lvm6, or lvm5). Using lvm you can create volume groups that expand multiple physical volumes.

NEWS CONTENTS

• 191005 : http://wiki.centos.org/HowTos/OS_Protection ( http://wiki.centos.org/HowTos/OS_Protection, )
• 191005 : Securing Linux, Part 3 Hardening the system ( Securing Linux, Part 3 Hardening the system, )
• 191005 : Some notes on the various flags ( )

Old News ;-)

http://wiki.centos.org/HowTos/OS_Protection

By separating file systems into various partitions, you can fine tune permissions and functionality. Doing so will provide you greater granularity for permissions, as well as adding a layer of security for any potential bad guys to work through.

Steve Grubb suggests, and quite rightly so, that areas where users have write privileges be kept on their own partition. This allows you to prevent hard link privilege escalation attempts, prevent creative device additions, and other unsavory behavior.

Modifying fstab

Once you have your partitions broken out and sized accordingly, you can begin to restrict the various mount points as much as possible. You should add nodev, noexec, and nosuid wherever possible. An example of a decently restricted /etc/fstab file is below:

/dev/VG_OS/lv_root          /        ext3      defaults     1 1
/dev/VG_OS/lv_tmp           /tmp     ext3      defaults,nosuid,noexec,nodev  1 2
/dev/VG_OS/lv_vartmp        /var/tmp ext3      defaults,nosuid,noexec,nodev 1 2
/dev/data_vol/lv_home       /home    ext3      defaults,nosuid,nodev  1 2
/dev/VG_OS/lv_var           /var     ext3      defaults,nosuid     1 2
/dev/data_vol/lv_web        /var/www ext3      defaults,nosuid,nodev  1 2
/dev/sda1                   /boot    ext3      defaults,nosuid,noexec,nodev  1 2
tmpfs                       /dev/shm tmpfs     defaults 0 0
devpts                      /dev/pts devpts    gid=5,mode=620 0 0
sysfs                       /sys     sysfs     defaults    0 0
proc                        /proc    proc      defaults    0 0
/dev/_VG_OS/lv_swap         swap     swap      defaults    0 0

Obviously you'll need to modify this example to suit your own system. LVM, volume names, labels etc are all subject to change. Please don't copy this example verbatim and expect it to work for you.

The webserver mount can also be set noexec, however this will impact cgi based applications, as well as server side includes which rely on the execute bit hack. If you're not using cgi applications, I would recommend at least testing noexec and using it if there are no negative side-effects.

Securing Linux, Part 3 Hardening the system

Securing local filesystems

Securing the local filesystem deals with ownership of files and directories and access rights to them. To secure the filesystem, the protection bits of files and directories must set to grant minimum access only.

Take special care with respect to inappropriate permissions regarding world-writable files and system directories and so-called setuid or setgid commands. These commands are executed with higher user privileges than the user running the command actually has. This might be necessary to access files that only root has access to (such as /bin/passwd needs to access /etc/passwd). For each of these commands, make sure that it really needs the setuid/setgid bits set. If this is not the case, disable it.

When all files on a partition definitely do not need the setuid/setgid bits, the nosuid option in /etc/fstab disables it for each file on the corresponding filesystem (/dev/hdc1 in the following example):

  #device mountpoint filesystemtype options dump fsckorder /dev/hda1 / ext2 defaults 1 1 ... /dev/hdc1 /mnt/cdrom iso9660 nosuid,user 1 2  

Furthermore, for very sensitive data, it might make sense to encrypt that data and protect it with a passphrase. GnuPG provides a suitable package to accomplish this.

Some notes on the various flags

Note: Questionable recommendations. should be taken with the grain of salt.

Recommended Links

• Hardening Red Hat Enterprise Linux 5
• Guide to the Secure Configuration of Red Hat Enterprise Linux 5
• Hardening Tips for the Red Hat Enterprise Linux 5 - Scribd

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019