In Part three of this blog series we will have a look how the SCS01 instance start up will be completed by inspecting at sapstart, the message server and the enqueue server. Will the profiling of the "real" SAP processes be different from the other processes or do we have enough AppArmor knowledge to create policies for these binaries almost on the fly? I'd like to recall the 'ps -axf' output of a running SCS01 instance:
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
4590 ? Ss 0:00 /usr/sap/SID/SCS01/exe/sapstart pf=/usr/sap/SID/SYS/profile/START_SCS01_ls3266v0
4600 ? Ss 0:00 \_ ms.sapSID_SCS01 pf=/usr/sap/SID/SYS/profile/SID_SCS01_ls3266v0
4601 ? Ssl 0:00 \_ en.sapSID_SCS01 pf=/usr/sap/SID/SYS/profile/SID_SCS01_ls3266v0
We now focus on the last three processes: sapstart, ms.sapSID_SCS01 (message server) and the en.sapSID_SCS01 (enqueue server).
sapstart
Same procedure as always, stop all SAP processes, start YaST2 and call "Add Profile Wizard", enter /usr/sap/SID/SCS01/exe/sapstart and click 'create'. This time, we will start both instances, SCS01 and JC00. We need the JC00 instance to use the message and enqueue server to somehow have a realistic environment. It takes a while until the system is up. You should at least connect to your JC00 instance and perform some administrative tasks, such as connect to the SAP Management Console running on web server port 50013 and display the developer traces for the msg_server and enserver processes. Now shutdown all SAP instances (e.g. by calling 'stopsap && /etc/init.d/sapinit stop && stopj2eedb && x_server stop && saposcol -k && cleanipc 01 remove && cleanipc 00 remove') and take a look at what the profile wizard suggests to do.
The standard ones look pretty okay, /bin/bash should of course inherit the permissions of sapstart because bash is a system binary and we don't profile the bash when it is used by sapstart. The next question of YaST2 is what to do with/sapmnt/SID /exe /sapcpe. Before we decide too fast what to do next, we have to consider our strategy regarding the granularity of our upcoming security profile. As we should not create security profiles for system binaries we can create security profiles for every other SAP executable which is called during start up. What we have to take care of is, to profile these binaries very intensely to make sure that the policy covers all file accesses. The sapcpe executable is only one of them. Let me recall the 'ps -axf' output. You'll see that both message- and enqueue-server are started by sapstart. Let all of them inherit the privileges of startsap makes life easier, only one policy to manage. But this will give startsap access rights to all files which are accessed by sapcpe, the message server and the enqueue server. This is not an option at all. If one executable is compromised, the files and data of the instance itself are in danger! We better create several policies, one for every SAP executable started by sapstart.
This means, for sapcpe we chose 'Profile' as option. We are now asked if we want to sanitize the environment, especially clearing variables like LD_LIBRARY_PATH. As SAP normally sets and uses this variable we will not sanitize the environment by a click on 'No'. From now on, you have to pay extra attention because we are now profiling two binaries at one time. Always have a look in the first line of the dialog window giving you the executable which is currently profiled. Let's continue with the work and let the system tools 'rm', 'ld', etc. inherit the profile from sapstart. Some dialog windows later YaST2 asks what to do with /usr/sap/SID/SCS01/exe_msg_server, the message server binary. Of course we will choose 'Profile' to have a message server profile later. And now the executable changes. The next dialog window creates a policy for msg_server, not sapstart! A few questions later, directly after sapmscsa get an own profile, the YaST2 dialog switches back to the sapstart profile. Switching the different profiles does require your full attention when creating profiles with AppArmor.
Several, already known questions later (including the abstractions, libraries, etc. for all the new executables) we have five new security policies under /etc/apparmor.d, namely usr.sap.SID.SCS01.exe.sapstart, usr.sap.SID.SCS01.exe.sapmscsa, usr.sap.SID.SCS01.exe.msg_server, usr.sap.SID.SCS01.exe.enserver and sapmnt.SID.exe.sapcpe. My profiles have the following content:
usr.sap.SID.SCS01.exe.sapstart:
# vim:syntax=apparmor
# Last Modified: Mon Nov 19 10:49:38 2007
#include
/usr/sap/SID/SCS01/exe/sapstart {
#include
#include
#include
/bin/bash ixr,
/bin/ln ixr,
/bin/rm ixr,
/home/SIDadm/dev_sapstart w,
/sapmnt/SID/exe/sapcpe px,
/sapmnt/SID/profile/* r,
/usr/sap/SID/SCS01/exe/enserver px,
/usr/sap/SID/SCS01/exe/libicudata.so.* mr,
/usr/sap/SID/SCS01/exe/libicui18n.so.* mr,
/usr/sap/SID/SCS01/exe/libicuuc.so.* mr,
/usr/sap/SID/SCS01/exe/libsapu*.so mr,
/usr/sap/SID/SCS01/exe/msg_server px,
/usr/sap/SID/SCS01/exe/sapstart mr,
/usr/sap/SID/SCS01/work/INSTSTAT w,
/usr/sap/SID/SCS01/work/en.sapSID_SCS01 w,
/usr/sap/SID/SCS01/work/kill.sap w,
/usr/sap/SID/SCS01/work/ms.sapSID_SCS01 w,
/usr/sap/SID/SCS01/work/sapstart.* w,
/usr/sap/SID/SCS01/work/sapstart0.* w,
/usr/sap/SID/SCS01/work/sapstart1.* w,
/usr/sap/SID/SCS01/work/shutdown.sap rw,
/usr/sap/SID/SCS01/work/std* w,
}
usr.sap.SID.SCS01.exe.sapmscsa:
# vim:syntax=apparmor
# Last Modified: Mon Nov 19 10:49:38 2007
#include
/usr/sap/SID/SCS01/exe/sapmscsa {
#include
#include
/sapmnt/SID/profile/* r,
/usr/sap/SID/SCS01/exe/libicudata.so.* mr,
/usr/sap/SID/SCS01/exe/libicui18n.so.* mr,
/usr/sap/SID/SCS01/exe/libicuuc.so.* mr,
/usr/sap/SID/SCS01/exe/libsapu*.so mr,
/usr/sap/SID/SCS01/exe/sapmscsa mr,
/usr/sap/SID/SCS01/log/SLOG01 rw,
/usr/sap/SID/SCS01/work/std* w,
}
usr.sap.SID.SCS01.exe.msg_server:
# vim:syntax=apparmor
# Last Modified: Mon Nov 19 10:49:38 2007
#include
/usr/sap/SID/SCS01/exe/msg_server {
#include
#include
#include
#include
#include
/bin/bash ixr,
/sapmnt/SID/global/ms_acl_info r,
/sapmnt/SID/profile/* r,
/usr/sap/SID/SCS01/exe/libicudata.so.* mr,
/usr/sap/SID/SCS01/exe/libicui18n.so.* mr,
/usr/sap/SID/SCS01/exe/libicuuc.so.* mr,
/usr/sap/SID/SCS01/exe/libsapu16_mt.so mr,
/usr/sap/SID/SCS01/exe/msg_server mr,
/usr/sap/SID/SCS01/exe/sapmscsa px,
/usr/sap/SID/SCS01/log/SLOG01 rw,
/usr/sap/SID/SCS01/work/dev_ms* rw,
/usr/sap/SID/SCS01/work/ms_j2ee_services.bin w,
}
usr.sap.SID.SCS01.exe.enserver:
# vim:syntax=apparmor
# Last Modified: Mon Nov 19 10:49:38 2007
#include
/usr/sap/SID/SCS01/exe/enserver {
#include
#include
#include
/sapmnt/SID/profile/* r,
/usr/sap/SID/SCS01/data/ENQSTAT w,
/usr/sap/SID/SCS01/exe/enserver mr,
/usr/sap/SID/SCS01/exe/libicudata.so.* mr,
/usr/sap/SID/SCS01/exe/libicui18n.so.* mr,
/usr/sap/SID/SCS01/exe/libicuuc.so.* mr,
/usr/sap/SID/SCS01/exe/libsapu16_mt.so mr,
/usr/sap/SID/SCS01/log/ENQBCK rw,
/usr/sap/SID/SCS01/log/SLOG01 rw,
/usr/sap/SID/SCS01/work/ENQLOG99 w,
/usr/sap/SID/SCS01/work/dev_enq* rw,
/usr/sap/SID/SCS01/work/enquelog rw,
}
sapmnt.SID.exe.sapcpe:
# vim:syntax=apparmor
# Last Modified: Mon Nov 19 10:49:38 2007
#include
/sapmnt/SID/exe/sapcpe {
#include
/sapmnt/SID/exe/sapcpe mr,
/sapmnt/SID/exe/sapcpeft r,
/sapmnt/SID/exe/scs.lst r,
/sapmnt/SID/exe/servicehttp r,
/sapmnt/SID/exe/servicehttp/sapmc r,
/sapmnt/SID/profile/* r,
/usr/sap/SID/SCS01/exe/libicudata.so.* mr,
/usr/sap/SID/SCS01/exe/libicui18n.so.* mr,
/usr/sap/SID/SCS01/exe/libicuuc.so.* mr,
/usr/sap/SID/SCS01/exe/libsapu*.so mr,
/usr/sap/SID/SCS01/exe/servicehttp r,
/usr/sap/SID/SCS01/exe/servicehttp/sapmc r,
/usr/sap/SID/SCS01/work/sapcpe.log w,
}
Always keep in mind, these are fresh security profiles. You still have to monitor the /var/log/audit/audit.log continuously to ensure that the policy isn't too restrictive. We now have a policy for our SCS01 instance. The next blog will focus on the JC00 instance, especially the jlaunch and the IGS executables. There will be tons of file accesses under the /usr/sap/SID/JC00/j2ee folder. Let's see, if there is a way to handle the java part smoothly.
No comments:
Post a Comment