%% Security conscious Linux %% Copyright 2004 Wichert Akkerman %% %% Presented at Software Live 2003 in Porto Alegre, Brazil %% %% Just like old times the modern day world is full of dangers and evil. %% In order to survive on the wild wild internet one has to be aware %% of the kinds of dangers that are out there and how to protect oneself %% from them. This talk will focus on the decisions involved in making %% a secure system and look at the tools and policies available, with a %% special focus on the Debian GNU/Linux system. %% Define the fonts we will use %% %% %% Default settings for special lines %% %%include "/etc/mgp/default.mgp" %default 1 leftfill, fore "black", back "white", bimage "background.bmp" %default 2 size 7, vgap 10, prefix " ", font "standard" %default 3 size 2, bar "gray70", vgap 10 %default 4 size 5, vgap 30, font "standard", fore "black" %% %% Default settings for indented lines %% %tab 1 size 5, vgap 70, prefix " ", icon box "green" 50 %tab 2 size 4, vgap 50, prefix " ", icon arc "red" 50 %tab 3 size 3, vgap 40, prefix " ", icon delta3 "blue" 40 %% %%%%%%%%%%%%%%%%%% %page %nodefault, font "standard", fore "black", back "white", bimage "background.bmp" %center Security conscious Linux %size 6 Wichert Akkerman %size 5 wichert@deephackmode.org %%%%%%%%%%%%%%%%%% %page About this talk not many a's, possibly too many s's inspired by the 'security debian manual' most of this is obvious %%%%%%%%%%%%%%%%%% %page Security myths disabling kernel modules makes a system more secure system A is the most secure system B is the least secure %%%%%%%%%%%%%%%%%% %page The real world no system is completely secure most attacks by far are automated and use known vulnerabilities root-kits are common and user-friendly problems can remain undiscovered for months %%%%%%%%%%%%%%%%%% %page Creating a secure system The most important part of a secure system is that it has been designed to be secure from the start. Realize against what you want to secure. Security is not an add-on feature! %%%%%%%%%%%%%%%%%% %page Creating a secure system secure before putting into service divide a system into small simple parts be aware of trust chains %%%%%%%%%%%%%%%%%% %page Creating a secure system centralisation is good centralisation is evil be aware of snowballing effects physical security is full access too much security means more insecurity security is always a trade-off %%%%%%%%%%%%%%%%%% %page Divide.. and don't be conquered Dividing a service into small simple parts has advantages: easier to test and debug each part can run with different privileges cracks can be contained %%%%%%%%%%%%%%%%%% %page Reducing privileges: resource limits Resource limits allow you to put a limit on the amount of resources a process can use: CPU time filesize memory size number of processes locked memory %%%%%%%%%%%%%%%%%% %page Reducing privileges: uids Running processes under different uids means they can not affect each other directly: no signals can be send they can not ptrace each other they can not touch each others files %%%%%%%%%%%%%%%%%% %page Reducing privileges: capabilities POSISX 1003.1e capabilities are a method of partitioning the power of root into separate capabilities. Linux uses 28: %size 3 CAP_CHOWN CAP_DAC_OVERRIDE CAP_DAC_READ_SEARCH CAP_FOWNER CAP_FSETID CAP_KILL CAP_SETGID CAP_SETUID CAP_SETPCAP CAP_LINUX_IMMUTABLE CAP_NET_BIND_SERVICE CAP_NET_BROADCAST CAP_NET_ADMIN CAP_NET_RAW CAP_IPC_LOCK CAP_IPC_OWNER CAP_SYS_MODULE CAP_SYS_RAWIO CAP_SYS_CHROOT CAP_SYS_PTRACE CAP_SYS_PACCT CAP_SYS_ADMIN CAP_SYS_BOOT CAP_SYS_NICE CAP_SYS_RESOURCE CAP_SYS_TIME CAP_SYS_TTY_CONFIG CAP_MKNOD CAP_LEASE %size 5 Each process has three sets of capabilities (effective, permitted and inheritable) %%%%%%%%%%%%%%%%%% %page Reducing privileges, VFS tricks chroots are a way to restrict a process to a specific part of the filesystem hierarchy namespaces are a way to give each process a separate filesystem hierarchy %%%%%%%%%%%%%%%%%% %page Debian archive It is important to be able to verify packages source and determine if it has been modified. Debian is working on two systems to do this: Archive signatures Package signatures %%%%%%%%%%%%%%%%%% %page Debian archive signatures The Debian archive has a chain of MD5 sums that tie a package to a release: a Release file has the MD5 of a Packages file the Packages file has MD5 sums of all packages %vgap 30 By signing the Release file a package can be traced to an archive maintainer. This system relies on always having access to the Package and Release files. %%%%%%%%%%%%%%%%%% %page Debian package signatures Package signatures combine signatures embedded inside a package with a system policy. Policies can be defined to check for acceptable packages. A policy has selection criteria which specify to which packages it applies to and and accecptance criteria. %%%%%%%%%%%%%%%%%% %page maintaining a secure system testing changes is just as important as initial testing %% the monday effect keep track of security fora bugtraq vuln-dev full-disclosure vendor lists do not irc/IM from production machines or networks %%%%%%%%%%%%%%%%%% %page am I secure? try standard tools ... but be aware of their faults ask people to break your system %%%%%%%%%%%%%%%%%% %page detecting cracks changes in outgoing bandwidth changes in DNS usage files/permissions changes do not trust your own system to provide you with correct data IDS honey-pots deal with information overflow %%%%%%%%%%%%%%%%%% %page what to do when cracked pull the plug make a dump of the cracked system for later analysis use search tools and security fora to find more information check all your other machines reinstall if time, postmortem report findings %%%%%%%%%%%%%%%%%% %page final notes thanks to: Utah 4Linux Gennari & Peatree Javier Fernandez-Sanguino Pena Debian-BR %vgap 30 Q&A at the booth of Utah, 4Linux and Gennari & Peatree. There will be a key-signing opportunity at the Debian booth after this talk.