Developing a Secure Internet Service SE Linux in Production Russell Coker Linux Consultant

Secure application design ● Use multiple processes with minimum privileges, Postfix, Qmail, and sshd as examples ● Design to use all the features of Unix permissions, then adding SE Linux support will usually be easy ● Have multiple spool directories for communication between different processes. For each directory have a purpose - if Unix permissions don't allow enforcing the purpose (EG allowing create but not unlink) then SE Linux will.

SE Linux Benefits ● Design that makes it easier to understand the operation of a program and to debug it often make it easier to take advantage of SE Linux features ● Give every spool directory a purpose, if two programs A and B each need to create data files that the other will read then use two directories. SE Linux can permit each program full create access in it's own directory and the ability to unlink files that it has processed in the other. ● Cleanly separate log files from application data files and use O_APPEND when creating them, SE Linux can prevent applications from modifying logs that they have written

Secure Implementation 1/2 ● Avoid buffer overflows, languages such as Perl greatly mitigate this risk ● GCC has options to check stack, useful but not infallable ● If executing shell scripts or using system(3) make sure that shell meta- characters are appropriately stripped or escaped ● Use setsid(1) or setsid(2) to create a new session and prevent TIOCSTI attacks ● RPM package everything for management

Secure Implementation 2/2 ● Use -pie -fstack-protector-all -fmudflap and -D_FORTIFY_SOURCE=2 when compiling programs that use data from hostile sources. PIE does require execmod access at the moment so less SE Linux enforcement is possible when PIE is used. ● Use the owner module for iptables to limit what network access each process may perform. Use different UIDs for different parts of the system to enable control over which network services each part of the system may access. ● Run the OS instance in a Xen DomU for RHEL5

Integrity and Confidentiality ● System integrity is the ability of a machine to function correctly in the face of attacks, and if it degrades to fail in a secure manner ● Confidentiality is the protection of secret data on the server ● There can be no confidentiality without integrity ● Consider the issues separately, most people consider them together and the results are not positive ● Some of the confidentiality protection work is outside the scope of SE Linux, EG preventing probes of the system and brute-force attacks

Least Privilege ● When designing a database or LDAP directory based system do not have a process running on behalf of a user (CGI-BIN script, server process, or PHP script) use administrative privileges. Have it authenticate to the data source with the user privileges. ● If the process is compromised then usually the user can only do what they are permitted to do, maybe they can do what other users on the system can do, but they certainly can't perform administrative tasks ● SE Linux prevents attack against other CGI-BIN scripts via restricting IPC

Least Privilege

Support for Modified Policy ● I can't speak for Red Hat, but if you don't change the parts of the policy that affect the base system then you should still receive support for all components of RHEL ● If you change policy source files supplied by Red Hat then you will be offered less support, and also there are practical issues involved in performing sys-admin work. If you just add new policy files (creating new domains and types and allowing existing domains to perform extra operations) then you need to recompile the policy for every policy upgrade but apart from that no effort.

SE Linux Policy design ● The most important thing to do is to choose the domains for processes, the types for files, and which domain and type to assign to each process and file ● Wherever possible use ra_file_perms, { create ra_file_perms }, ra_dir_perms, create_append_log_file, and other macros that provide greater restrictions than Unix permissions allow ● Limiting which types of symlinks can be read protects against race condition attacks ● SE Linux should enforce the same constraints as Unix permissions (but mandatory) and also should be used to do more

Writing SE Linux Policy ● Documentation is available on the net ● Start by defining domains with daemon_domain() and daemon_base_domain() and define types for files ● Usually try running daemons, write policy to permit the appropriate actions they attempt and dontaudit inappropriate actions (or change daemons). Iterate until everything works.

SE Linux Improvements in RHEL5/FC5 ● Loadable policy modules will persist across upgrades, currently you must modify the policy source and then recompile the policy every time you upgrade it ● Binary policy modules allow clear separation between your policy and system policy ● MCS and MLS for confidentiality controls (RHEL4 uses the same mechanisms for protecting integrity and confidentiality) ● SE Linux support in iptables is being developed, maybe in RHEL5 you will be able to control network access based on domain

Inumbers Overview ● Inumbers project provides addresses of the form (where X is a mobile phone number in International format) and forwards mail ● Maildrop agent forwards mail after consulting LDAP or queues it for new account ● Daemon creates accounts and sends SMS with password ● CGI-BIN script allows changing password ● Not yet written CGI-BIN script for administration

Inumbers SE Linux ● Domain for the MTA process (for forwarding mail for registered users and queuing it for new accounts) ● Daemon domain execute the program to send SMS and for creating new LDAP records – no direct network communication ● Domain for sending SMS ● httpd_sys_script_t domain for CGI-BIN script ● New domain needed for admin CGI-BIN script (yet to be written)

Q/A ● ● ● ●