LIDS-TDE-feature.txt,v 1.2 2004/09/15 08:55:41 purna Exp ------------------------------------------------------ LIDS Trusted Domain Enforcement (TDE): An Introduction ------------------------------------------------------ Yusuf Wilajati Purna (ywpurna@users.sourceforge.net) Updated: September 15, 2004 BACKGROUND & INTRODUCTION ========================= Applications, which we believe trusted so that we give more privileges than others through LIDS ACLs, sometimes behave abnormally or unexpectedly in case unprotected inputs are given. Due to this anomaly, it is possible for attackers to hijack privileges of the applications, and then abuse the privileges to breach the system security. Although LIDS Trusted Path Execution (TPE) has been introduced in LIDS [1], the protection mechanism alone could not give much protection to the system from this threat. To cope with this threat, Trusted Domain Enforcement (TDE) feature is introduced into LIDS. TDE consists of two protection mechanisms: a simple TDE policy and application sandboxing. Application sandboxing can be considered to be the main part of TDE. But, both two mechanisms are provided for the purpose of guarding the system in case the applications, LIDS has been protecting, suddenly become untrusted by behaving abnormally due to malicious input manipulation, buffer overflows exploitation, etc. The goal of this paper is to give an introduction and overview of LIDS TDE. SIMPLE TDE POLICY ================= If TDE has been configured in the kernel, LIDS will enforce a TDE policy during its operation: "A privileged process that reads unprotected input, including character devices, files, etc, will be moved into the untrusted domain." A process moved into the untrusted domain still runs, but loses its privileges, including granted capabilities, set in LIDS ACLs. This will help reduce security risks to a certain extent in case the process is abused with malicious input. Granting CAP_PROTECTED to a process will force LIDS not to move the process into the untrusted domain even if the process reads unprotected input. In some cases, you need to grant CAP_PROTECTED to special processes that really need input from the standard input to make them run properly. The '/bin/su' binary is an example. But care must be taken when granting CAP_PROTECTED to a process. Granting this capability to a not-so-well written script/binary increases the risks of the privileges/capabilities being abused by malicious input. APPLICATION SANDBOXING ====================== Another technique is trying to limit the movement/behavior of the subject application. From the beginning, if it is possible we want to draw a boundary for the movement space of the application so that it is isolated into a separated room or jail. Thus, if the application all of sudden behaves abnormally, the effects are limited inside the room/boundary only, and the other parts of the system are not affected. This technique is generally called 'compartmentalization'. A more detailed explanation on compartmentalization can be found in [2]. Depending on how we set the jail, there are some types of compartmentalization. Even in the vanilla Linux or UNIX, the chroot() call can be considered to be one way to provide compartmentalization [3]. By modifying the way LIDS currently checks the ACLs for a subject, in fact, we can also provide compartmentalization using LIDS. By enforcing a policy that a subject can access an object if only if its access is explicitly specified we can draw a boundary for the movement space of the subject. Providing compartmentalization in this way is much known as 'application sandboxing' [4, 5]. APPROACH -------- In LIDS, we have known the following ACLs checking rules: "Default first, specifics follow", or "Deny from all, allow to specifics" Thus, as long as there is no DENY default rule for an object, a subject (application) can always access the object even if there is no explicit rule specifying that the subject can access the object. For example, if there is *no* default rule as follows: $ lidsconf -A -o /home/purna/my_secret -j DENY any subject (binary/executable) can always access /home/purna/my_secret. In contrast, ACLs checking rules for a sandboxed process works in the opposite way. The basic rule for a LIDS sandbox is "All must be specified!" If there is no ACL specifying that a subject can access an object the subject cannot access the object. Thus in order to make the subject run properly as expected we need to specify all rules required by the subject. It is these rules that in fact construct the boundary of the sandbox. LIDS SANDBOX ACLS ----------------- A new object type called "LIDS_SANDBOX" is introduced. This is used to mark an application that the application is sandboxed. For example, the following has LIDS sandbox the '/opt/mybash' application: # lidsconf -A -s /opt/mybash -o LIDS_SANDBOX -j ENABLE Once we have marked the application, we must specify all the required ACLs for the application so that the application can run properly. Usually we must specify what directories, files, or (shared) libraries required by the application. For example, the following shows some ACLs for the '/opt/mybash' application: # lidsconf -A -s /opt/mybash -o /opt/testdir -j READONLY # lidsconf -A -s /opt/mybash -o /lib/libtermcap.so.2.0.8 -j READONLY # lidsconf -A -s /opt/mybash -o /lib/libdl-2.3.2.so -j READONLY # lidsconf -A -s /opt/mybash -o /lib/libc-2.3.2.so -j READONLY # lidsconf -A -s /opt/mybash -o /lib/ld-2.3.2.so -j READONLY A more complete example is explained in the "Example" chapter below. LIDS SANDBOX CAPABILITIES ------------------------- What we have built up to now using ACLs is the boundary of a sandbox in the file system level. But in fact, in Linux kernel, a process can do more than file system related stuff, such as opening sockets, inserting kernel modules, killing other processes, etc. By possessing the CAP_SYS_MODULE capability, a process can insert a kernel module that even can cause changes in the kernel behavior, for example. Although not all, most of the privileges of a process to change the behavior of the kernel or to perform something on the kernel space can be controlled by what capabilities the process can possess. To limit privileges of the sanboxed process as few as possible whilst it can still run properly, we need to set also the boundary for these process capabilities. If we follow the basic rule of the LIDS sandbox, we need to specify all capabilities that the application really require at the minimum in order to run properly. Currently, there are two choices. If we have enabled CONFIG_CAP_LIDS_SANDBOX_EFT_SET during the kernel compilation configuration all capabilities except the following are granted to a sandboxed process: - CAP_SETPCAP - CAP_SYS_RAWIO - CAP_MKNOD - CAP_SYS_PTRACE - CAP_HIDDEN - CAP_PROTECTED But the whole effect of the capabilities, of course, depends on the capabilities enabled globally. That is to say, if CAP_SYS_TIME is disabled globally the process will not have a privilege to change time without CAP_SYS_TIME being granted to the process explicitly. For the capabilities in the exception above, no matter what capabilities are available globally, if the application requires the capabilities we need to grant the capabilities to process explicitly. If we haven't enabled CONFIG_CAP_LIDS_SANDBOX_EFT_SET, the condition is much tighter. We must follow the "All must be specified!" rule. Therefore, we must explicitly specify what capabilities at the minimum the program really need in order to run properly. LIDS SANDBOX NETWORK ACCESS RESTRICTION ---------------------------------------- Starting with LIDS 1.2.2rc3, network access restriction has been added to the LIDS sandbox feature. Without network access related capabilities and sockets being explicitly specified, a sandboxed process cannot bind sockets to ports, connect to ports, or create UDP sockets. Thus, in short, a sandboxed process cannot make any network connection without permission. CAP_NET_BIND_SERVICE with allowable socket port range denotes to which ports a sandboxed process is allowed to bind created sockets. For example, for a sandboxed /usr/local/apache/bin/httpd, the following indicates that the httpd can only bind a socket to port# 80: # lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd \ -o CAP_NET_BIND_SERVICE 80-80 -j GRANT Different from the rule for a non-sandboxed process, CAP_NET_BIND_SERVICE with allowable port range must be specified for a sandboxed process even if the process need only to bind a socket to port# greater than 1023. To indicate which ports a sandboxed process is allowed to connect, CAP_NET_BROADCAST with allowable socket port range is used. For example, for a sandboxed /usr/bin/ftp, the following indicates that the ftp client can only connect to port# 21: # lidsconf -A POSTBOOT -s /usr/bin/ftp -o CAP_NET_BROADCAST 21-21 -j GRANT CAP_NET_BROADCAST is also used to indicate that a sandboxed process can create UDP sockets. Without possessing CAP_NET_BROADCAST, a sandboxed process cannot create UDP sockets. INHERITANCE RULE ---------------- To make everything simple, currently, the boundary set for a sandboxed process will be inherited by a child process forked/execed by the sandboxed process. Thus, the child process will always have the same boundary as the sandboxed parent. The inheritance rule in a sandboxed process is infinite. A child process, a grandchild process, a great-grandchild process, etc are always jailed in the same sandbox. Thus the '-i' inheritance option does not mean anything for a sandboxed process. EXAMPLE ======= Although, a restricted shell can be easily created using bash ('bash -r', for example), let us try to create a restricted shell using the LIDS sandbox feature. We will set this restricted shell in LIDS POSTBOOT state. First, let's copy the original 'bash' to a directory. We can copy 'bash' to the /opt directory, for example, and then sandbox the copy: # cp /bin/bash /opt/mybash # lidsconf -A -o /opt/mybash -j READONLY # lidsconf -A POSTBOOT -s /opt/mybash -o LIDS_SANDBOX -j ENABLE For short, let us call the copy 'mybash'. We can then create the sandbox boundary of 'mybash'. We would like to limit 'mybash' so that 'mybash' can only move inside the /opt/testdir directory, for example, and not allow 'mybash' to write/create anything inside the directory: # lidsconf -A POSTBOOT -s /opt/mybash -o /opt/testdir -j READONLY We would like to use the /bin/ls binary inside 'mybash': # lidsconf -A POSTBOOT -s /opt/mybash -o /bin/ls -j READONLY Now, we can create ACLs for libraries required by 'mybash' to run properly: # lidsconf -A POSTBOOT -s /opt/mybash -o /lib/libtermcap.so.2.0.8 -j READONLY # lidsconf -A POSTBOOT -s /opt/mybash -o /lib/libdl-2.3.2.so -j READONLY # lidsconf -A POSTBOOT -s /opt/mybash -o /lib/libc-2.3.2.so -j READONLY # lidsconf -A POSTBOOT -s /opt/mybash -o /lib/ld-2.3.2.so -j READONLY # lidsconf -A POSTBOOT -s /opt/mybash -o /etc/ld.so.preload -j READONLY # lidsconf -A POSTBOOT -s /opt/mybash -o /etc/ld.so.cache -j READONLY Running 'mybash' first in ACL_DISCOVERY mode can help us find more detailed ACLs needed to be set for 'mybash'. Reload the configuration files, and play with 'mybash': # lidsadm -S -- +RELOAD_CONF # pwd / # /opt/mybash mybash-2.05b# ls ls: .: No such file or directory --> 'ls' failed to list the current directory (/index.html) contents, since the '/index.html' is outside the sandbox boundary. mybash-2.05b# pwd / mybash-2.05b# cd /opt mybash: cd: /opt: No such file or directory --> 'cd' failed to change the current directory to the /opt directory, since the /opt directory is outside the sandbox boundary mybash-2.05b# cd /opt/testdir mybash-2.05b# pwd /opt/testdir mybash-2.05b# ls hello.txt ls testdir2 --> 'ls' successfully listed the /opt/testdir directory contents. mybash-2.05b# cat hello.txt mybash: cat: command not found --> 'cat' is outside the sandbox boundary. mybash-2.05b# ls > hello.txt mybash: hello.txt: Operation not permitted --> 'ls' could not overwrite '//document/hello.txt', since 'mybash' is not allowed to write/create anything inside the sandbox. mybash-2.05b# exit # This example should shed light on the behavior of a process that is sandboxed. Appendix below shows bigger examples for sandboxing "Apache" and "Samba". IMPLEMENTATION AND AVAILABILITY =============================== LIDS TDE including the LIDS sandbox feature has been implemented in LIDS 1.2.2rc1. To control this feature, you need to use, at least, lidstools 0.5.5. Source code is freely available from http://www.lids.org. For LIDS 1.2.2rc3, you need to use at least lidstools 0.5.6. SUMMARY ======= The objective of LIDS Trusted Domain Enforcement (TDE) is keeping the system trusted as much as possible by - getting rid of privileges of trusted/protected applications that suddenly become untrusted, i.e., moving trusted applications into the untrusted domain, and - sandboxing applications from beginning. TDE introduces a new way of viewing an application in LIDS. It does not give more privileges to an application by using ACLs, but restricts the movement space and behavior of an application using ACLs. It is hoped that this will give a another option to protect a Linux system using LIDS. Finally, as usual, please enjoy, give it a try, and report any bugs. Any comments are welcome as well. :-) ACKNOWLEDGMENT =============== Thanks to Doug Porter, Huagang Xie, Yannick Le Briquer, and others for comments on this feature and reporting bugs. APPENDIX: SANDBOX Configuration Examples for "Apache" and "Samba" ================================================================= The following are sample configurations for sandboxing "Apache" and "Samba". Tune the sandboxes to fit your environment. Use ACL_DISCOVERY mode to help find required ACLs. - lids.sandboxed.apache.sh: #---------- #!/bin/sh #ACLs for sandboxing "Apache" #mark httpd LIDS_SANDBOX /sbin/lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd -o LIDS_SANDBOX -j ENABLE #set capability boundary /sbin/lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd -o CAP_SETGID -j GRANT /sbin/lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd -o CAP_SETUID -j GRANT /sbin/lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd -o CAP_KILL -j GRANT /sbin/lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd -o CAP_NET_BIND_SERVICE 80-80 -j GRANT #set ACL boundary /sbin/lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd -o /etc/group -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd -o /etc/host.conf -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd -o /etc/hosts -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd -o /etc/ld.so.cache -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd -o /etc/ld.so.preload -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd -o /etc/localtime -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd -o /etc/nsswitch.conf -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd -o /etc/passwd -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd -o /etc/resolv.conf -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd -o /lib/ld-2.3.2.so -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd -o /lib/libc-2.3.2.so -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd -o /lib/libcrypt-2.3.2.so -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd -o /lib/libm-2.3.2.so -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd -o /lib/libnss_files-2.3.2.so -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd -o /usr/lib/libexpat.so.0.4.0 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd -o /usr/lib/libgdbm.so.2.0.0 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd -o /usr/local/apache -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd -o /usr/local/apache/logs -j WRITE /sbin/lidsconf -A POSTBOOT -s /usr/local/apache/bin/httpd -o /dev/null -j WRITE #---------- - lids.sandboxed.samba.sh: #---------- #!/bin/sh #ACLs for sandboxing "Samba" (nmbd & smbd) #mark nmbd & smbd LIDS_SANDBOX /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o LIDS_SANDBOX -j ENABLE /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o LIDS_SANDBOX -j ENABLE #set capability boundary /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o CAP_NET_BIND_SERVICE 137-139,445-445 -j GRANT /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o CAP_NET_BROADCAST 137-139,445-445 -j GRANT /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o CAP_NET_BIND_SERVICE 137-139,445-445 -j GRANT /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o CAP_NET_BROADCAST 137-139,445-445 -j GRANT /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o CAP_SETUID -j GRANT /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o CAP_SETGID -j GRANT /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o CAP_SYS_RESOURCE -j GRANT #set ACL boundary /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o /etc/ld.so.cache -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o /etc/ld.so.preload -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o /etc/localtime -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o /lib/libc-2.3.2.so -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o /lib/libcrypt-2.3.2.so -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o /lib/libcrypto.so.0.9.7a -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o /lib/libdl-2.3.2.so -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o /lib/libnsl-2.3.2.so -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o /lib/libpam.so.0.75 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o /lib/libresolv-2.3.2.so -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o /lib/libssl.so.0.9.7a -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o /usr/kerberos/lib/libcom_err.so.3.0 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o /usr/kerberos/lib/libgssapi_krb5.so.2.2 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o /usr/kerberos/lib/libk5crypto.so.3.0 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o /usr/kerberos/lib/libkrb5.so.3.1 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o /usr/lib/libgdbm.so.2.0.0 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o /usr/lib/liblber.so.2.0.17 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o /usr/lib/libldap.so.2.0.17 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o /usr/lib/libpopt.so.0.0.0 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o /usr/lib/libsasl.so.7.1.11 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o /usr/lib/libz.so.1.1.4 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o /usr/local/samba/lib -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o /usr/local/samba/var -j WRITE /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/nmbd -o /dev/null -j WRITE /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /dev/urandom -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /etc/group -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /etc/host.conf -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /etc/hosts -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /etc/ld.so.cache -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /etc/ld.so.preload -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /etc/localtime -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /etc/nsswitch.conf -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /etc/passwd -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /etc/printcap -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /etc/resolv.conf -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /lib/libc-2.3.2.so -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /lib/libcrypt-2.3.2.so -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /lib/libcrypto.so.0.9.7a -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /lib/libdl-2.3.2.so -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /lib/libnsl-2.3.2.so -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /lib/libnss_files-2.3.2.so -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /lib/libpam.so.0.75 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /lib/libresolv-2.3.2.so -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /lib/libssl.so.0.9.7a -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /tmp -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /usr/kerberos/lib/libcom_err.so.3.0 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /usr/kerberos/lib/libgssapi_krb5.so.2.2 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /usr/kerberos/lib/libk5crypto.so.3.0 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /usr/kerberos/lib/libkrb5.so.3.1 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /usr/lib/gconv -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /usr/lib/libgdbm.so.2.0.0 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /usr/lib/liblber.so.2.0.17 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /usr/lib/libldap.so.2.0.17 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /usr/lib/libpopt.so.0.0.0 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /usr/lib/libsasl.so.7.1.11 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /usr/lib/libz.so.1.1.4 -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /usr/local/samba/lib -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /usr/share/locale/locale.alias -j READONLY /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /dev/null -j WRITE /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /home -j WRITE /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /usr/local/samba/private -j WRITE /sbin/lidsconf -A POSTBOOT -s /usr/local/samba/sbin/smbd -o /usr/local/samba/var -j WRITE #---------- REFERENCES ========== 1. Yusuf Wilajati Purna, "LIDS Trusted Path Execution (TPE)", March, 2004. http://www.lids.org/document/LIDS-TPE-feature.txt 2. Gary McGraw, John Viega, "Software security principles: Part 3", 2000. http://www-106.ibm.com/developerworks/security/library/s-priv.html 3. David A. Wheeler, "Secure Programming for Linux and Unix HOWTO: 7.4.6 Consider Using Chroot to Minimize Available Files", 2003. http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/ minimize-privileges.html#CONSIDER-CHROOT 4. Niels Provos, "Systrace - Interactive Policy Generation for System", 2002. http://niels.xtdnet.nl/systrace/ 5. David Wagner, Tal Garfinkel, "Janus", 1996. http://http.cs.berkeley.edu/~daw/janus/ EOF