LIDS Trusted Domain Enforcement (TDE): An Introduction

包子

发信人: 包子 (我是FQ), 信区: Security
标  题: LIDS Trusted Domain Enforcement (TDE): An Introduction
发信站: 郑大绿城 BBS (Fri Oct  8 01:15:54 2004), 本站(bbs.zzu.edu.cn)


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 (/) contents,
    since the '/' 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 '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/developer ... 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

--
每天灌一灌，快乐似神仙 ：）
※ 来源:．郑大绿城 BBS http://bbs.zzu.edu.cn [FROM: 218.17.77.65]