SLES10 AppArmor - How to create Security Profiles for SAP - Part 2

[hannes_kuehnemund]

SLES10 AppArmor - How to create Security Profiles for SAP - Part 2

 
The first blog of this blog series explained in deep detail, how an AppArmor policy is generated. As we are now familiar in how to create a policy for an executable we increase the speed and explain the next binaries which are needed to start the whole SCS instance of our SID system. My plan to have only three blogs changed to have four blogs now. The amount of things left to show you needs more space then expected. So let's start with having a look at the processes which are running when the SCS01 instance is up. The 'ps -axf' output looks like:
 

4366 ? Ss     0:00 /usr/sap/SID/SYS/exe/run/saposcol
4426 ? S      0:00 /sapdb/programs/pgm/niserver
4432 ? S      0:00 /sapdb/programs/pgm/vserver
4433 ? S      0:00  \_ xserver.prt logger
4448 ? Ssl    0:00 /sapdb/SID/db/pgm/kernel SID
4471 ? Sl     0:00  \_ /sapdb/SID/db/pgm/kernel SID

*4586 ? Ssl    0:00 /usr/sap/SID/SCS01/exe/sapstartsrv pf=/usr/sap/SID/SYS/profile/START_SCS01_ls3266v0 -D <br />4590 ? Ss     0:00 /usr/sap/SID/SCS01/exe/sapstart pf=/usr/sap/SID/SYS/profile/START_SCS01_ls3266v0 <br />4600 ? Ss     0:00  \_ ms.sapSID_SCS01 pf=/usr/sap/SID/SYS/profile/SID_SCS01_ls3266v0 <br />4601 ? Ssl    0:00  \_ en.sapSID_SCS01 pf=/usr/sap/SID/SYS/profile/SID_SCS01_ls3266v0 </pre><br /> <br />Currently, only the sapstartsrv executable is under control of AppArmor. The remaining processes are saposcol, MaxDB niserver and vserver, the MaxDB kernel, sapstart, the message server ms.sapSID_SCS01 and the enqueue server en.sapSID_SCS01. We'll now confine them step by step, starting with saposcol. <br /> <br />saposcol <br /> <br />The saposcol - SAP OS collector - is needed to collect system runtime information. This information is available within the CCMS. You maybe know some of the statistics already if you are familiar with ABAP transaction ST06. Go get the system runtime information the saposcol executable has to read several entries from the /proc files system. So let's see what a saposcol AppArmor policy will look like. Stop the SCS instance via 'stopsap && x_server stop && saposcol -k && /etc/init.d/sapinit stop && cleanipc 01 remove'. Start the "Add Profile Wizard", enter /usr/sap/SID/SYS/exe/run/saposcol as binary to profile, click create and start the SCS instance afterwards with 'startsap SCS'. Let the system run for 5-10 Minutes to let saposcol collect all needed information and stop the system in the same way mentioned above. When scanning the system log for saposcol we should have a closer look what YaST2 suggests. <br /> <br />The first action which YaST2 asks is what to do with /bin/bash. The two available options are 'Inherit' and 'Unconfined'. Inherit will give /bin/bash in the saposcol context the same permissions and unconfined will run bash without any protection. In this case, we'll use Inherit to restrict the access of the bash executed by saposcol. The next action looks similar, but this time the shell (called by saposcol) wants to execute /sbin/sysctl. The possible options for us are 'Inherit', 'Profile' and 'Unconfined'. When choosing the 'Profile' option a new profile for /sbin/sysctl will be created. As /sbin/sysctl is a system wide used binary, the usage of it by saposcol may not reflect its general use pattern. Therefore we let /sbin/sysctl inherit the permissions of saposcol. We'll do the same for all system binaries coming afterwards. The other permissions are in the same grid as the ones for sapstartsrv, which means that you are already familiar what they mean and how to set the permissions. <br /> <br />The new saposcol policy now looks like: <br /> <br /><pre># vim:syntax=apparmor <br /># Last Modified: Fri Nov 16 14:45:57 2007 <br />#include <tunables/global> <br /> <br />/sapmnt/SID/exe/saposcol flags=(complain) { <br />  #include <abstractions/base> <br />  #include <abstractions/bash> <br />  #include <abstractions/consoles> <br />  #include <abstractions/nameservice> <br /> <br />  capability setuid, <br /> <br />  /bin/bash ixr, <br />  /proc r, <br />  /proc//cmdline r,
  /proc//stat r, <br />  /proc//status r,
  /proc/diskstats r,
  /proc/interrupts r,
  /proc/loadavg r,
  /proc/net/dev r,
  /proc/swaps r,
  /proc/sys r,
  /proc/sys/** r,
  /sapmnt/SID/exe/saposcol mr,
  /sbin/sysctl ixr,
  /usr/bin/expand ixr,
  /usr/sap/tmp/coll.put rw,
  /usr/sap/tmp/dev_coll* rw,
  /usr/sap/tmp/procmon r,
  /usr/sap/tmp/procmon/J2EE_SID_00_procmon.ini r,
}
Please note, that our initial executable path /usr/sap/SID/SYS/exe/run/saposcol changed to /sapmnt/SID/exe/saposcol. This is intended, because AppArmor does resolve symbolic links. Having a saposcol profile at hand we continue the profiling with the database.
 
*MaxDB - niserver, vserver and kernel <br /> <br />When looking at the 'ps' output, we see three different processes. In fact, two of them, niserver and vserver are started by one single executable, /sapdb/programs/bin/x_server, which is called by the startdb script. The x_server from MaxDB is the service you connect to, to start the database remotely. Make sure the SAP system and all SAP related processes are not running, start the "Add Profile Wizard", enter /sapdb/programs/bin/x_server as executable and start up the database using 'startdb'. The ones, who may ask, from where I got the path for the x_server binary, just have a look at the startdb script. There you'll find the answer. You now may want to use the database manager to perform some administrative tasks, but this is not needed at all. Later, when running the system with all profiles in enforce mode you will definitely have to check audit log continuously to track down if the created profiles aren't too restrictive. Stop the database and continue with creating a policy using the next YaST2 dialog.  <br /> <br />First of all, the x_server wants to start the sdbstarter. We'll use the 'Inherit' function here to have one x_server profile. The sdbstarter again wants to call x_server, which we also allow through 'Inherit'. The x_server then starts the vserver, which is also fine with 'Inherit'. The vserver afterwards starts the niserver, again we choose 'Inherit'. Also the nisslserver inherits the rights from x_server. The questions regarding tty's and write access to /tmp can be answered by using the abstractions offered. When you are asked about the pipes and FIFO folders, you should allow read/write access in general for both directories.  <br /> <br />The policy for MaxDB - x_server looks like: <br /> <br /><pre># vim:syntax=apparmor <br /># Last Modified: Fri Nov 16 16:08:46 2007 <br />#include <tunables/global> <br /> <br />/sapdb/programs/bin/x_server flags=(complain) { <br />  #include <abstractions/base> <br />  #include <abstractions/nameservice> <br />  #include <abstractions/user-tmp> <br /> <br />  capability dac_override, <br />  capability setgid, <br />  capability setuid, <br /> <br />  /etc/opt/sdb r, <br />  /sapdb/data/fifo/ rw,
  /sapdb/data/ipc/us:SID/* rw,
  /sapdb/data/pid/SID r, <br />  /sapdb/data/wrk/niserver* rw,
  /sapdb/data/wrk/xserver* rw,
  /sapdb/programs/bin/starter/sdbstarter ixr,
  /sapdb/programs/bin/x_server ixr,
  /sapdb/programs/lib/libso mr,   /proc//maps r, <br />  /sapdb/SID/db/lib/libso* mr,
  /sapdb/SID/db/pgm/kernel mr,
  /sapdb/SID/sapdata/* rw,
  /sapdb/SID/saplog/* rw,
  /sapdb/data/config/SID* rw,
  /sapdb/data/dbspeed/SID w,
  /sapdb/data/fifo/* rw,
  /sapdb/data/ipc/** rw,
  /sapdb/data/pid/SID w, <br />  /sapdb/data/pipe/SID rw, <br />  /sapdb/data/wrk/SID/ lrw,
}
This should be enough for this blog, the sapstart, the message server ms.sapSID_SCS01 and the enqueue server en.sapSID_SCS01 will follow in the next blog.