Let systrace’s automated mode do your work for you.
In a true paranoid’s ideal world, system administrators would read the source code for each application on their system and be able to build system-call access policies by hand, relying only on their intimate understanding of every feature of the application. Most system administrators don’t have that sort of time, though, and would have better things to do with that time if they did.
Luckily, systrace includes a policy-generation tool that will generate a policy listing for every system call that an application makes. You can use this policy as a starting point to narrow down the access you will allow the application. We’ll use this method to generate a policy for inetd .
Use the -A flag to systrace, and include the full path to the program you want to run:
# systrace -A /usr/sbin/inetd
To pass flags to inetd, add them at the end of the command line.
Then use the program for which you’re developing a policy. This system has ident, daytime, and time services open, so run programs that require those services. Fire up an IRC client to trigger ident requests, and telnet to ports 13 and 37 to get time services. Once you have put inetd through its paces, shut it down. inetd has no control program, so you need to kill it by using the process ID.
Checking the process list will show two processes:
# ps -ax | grep inet
24421 ?? Ixs 0:00.00 /usr/sbin/inetd
12929 ?? Is 0:00.01 systrace -A /usr/sbin/inetdDo not kill the systrace process (PID 12929 in this example); that process has all the records of the system calls that inetd has made. Just kill the inetd process (PID 24421), and the systrace process will exit normally.
Now check your home directory for a .systrace directory, which will contain systrace’s first stab at an inetd policy. Remember, policies are placed in files named after the full path to the program, replacing slashes with underscores.
Here’s the output of ls:
# ls .systrace
usr_libexec_identd usr_sbin_inetdsystrace created two policies, not one. In addition to the expected policy for /usr/sbin/inetd, there’s one for /usr/libexec/identd. This is because inetd implements time services internally, but it needs to call a separate program to service other requests. When inetd spawned identd, systrace captured the identd system calls as well.
By reading the policy, you can improve your understanding of what the program actually does. Look up each system call the program uses, and see if you can restrict access further. You’ll probably want to look for ways to further restrict the policies that are automatically generated. However, these policies make for a good starting point.
Applying a policy to a program is much like creating the systrace policy itself. Just run the program as an argument to systrace, using the -a option:
# systrace -a /usr/sbin/inetd
If the program tries to perform system calls not listed in the policy, they will fail. This may cause the program to behave unpredictably. systrace will log failed entries in /var/log/messages.
To edit a policy, just add the desired statement to the end of the rule list, and it will be picked up. You could do this by hand, of course, but that’s the hard way. systrace includes a tool to let you edit policies in real time, as the system call is made. This is excellent for use in a network operations center environment, where the person responsible for watching the network monitor can also be assigned to watch for system calls and bring them to the attention of the appropriate personnel. You can specify which program you wish to monitor by using systrace’s -p flag. This is called attaching to the program.
For example, earlier we saw two processes containing inetd. One was the actual inetd process, and the other was the systrace process managing inetd. Attach to the systrace process, not the actual program (to use the previous example, this would be PID 12929), and give the full path to the managed program as an argument:
# systrace -p 12929 /usr/sbin/inetd
At first nothing will happen. When the program attempts to make an unauthorized system call, however, a GUI will pop up. You will have the option to allow the system call, deny the system call, always permit the call, or always deny it. The program will hang until you make a decision, however, so decide quickly.
Note that these changes will only take effect so long as the current process is running. If you restart the program, you must also restart the attached systrace monitor, and any changes you previously set in the monitor will be gone. You must add those rules to the policy if you want them to be permanent.
The original article that this hack is based on is available online at http://www.onlamp.com/pub/a/bsd/2003/02/27/Big_Scary_Daemons.html.
Michael Lucas