|
- why the kernel needed patching Since syslogd_t runs at mls_systemhigh, both the /dev/log file and the unix_dgram_socket object bond to it are of mls_systemhigh, rendering that many application domains that have logging_send_syslog_msg() called and running at mls_systemlow such as klogd_t failed to "sendto" it with the following error message: type=1400 audit(1298535101.654:868): avc: denied { sendto } for pid=385 comm="klogd" path="/dev/log" scontext=system_u:object_r:klogd_t:s0 tcontext=system_u:object_r:syslogd_t:s15:c0.c1023 tclass=unix_dgram_socket One possible solution is to add syslogd_t to the mlstrustedobject attribute since the unix_dgram_socket object inherits the creator's SID by default. However, the side effect of this approach is that syslogd_t is also the label for the entire syslogd's procfs entries. - the overall design approach in the patch Had a socket had separate type than the creator's type then the socket type alone could be added to the mlstrustedobject attribute. For this purpose, security_transition_sid could be called to compute the socket SID on socket creation(in the wrapper function of socket_sockcreate_sid()). In order not to break labeled networking and network access control, socket should retain its creator's role and MLS attribute, both security_compute_sid and mls_compute_sid functions should handle a socket class in the same way as they do for the "process" class. In order to reduce future maintenance effort the genheaders program will help to auto-generate a f! unction to decide if a class is of any socket class, b y comparing the class kernel value among those SECCLASS_XXX macros for socket class. Last but not least, if security_compute_sid is called from userspace (by compute_create program) then the class policy value should be mapped to the relevant kernel value before above check. - implementation details (Please refer to the patches themselves:-)) - testing results If socket type "syslogd_s_t" is defined and following type_transition rule is specified in logging.te: type_transition syslogd_t syslogd_t : unix_dgram_socket syslogd_s_t; Then with the help of dump_stack() and printk() we can see that the unix_dgram_socket object created by syslogd would have a different type but retains! syslogd's user, role and attribute: Pid: 395, comm: syslogd Not tainted 2.6.34.8-WR4.2.0.0_standard #13 Call Trace: [<c1247042>] socket_sockcreate_sid+0x52/0xc0 [<c1247143>] selinux_socket_post_create+0x93/0x180 [<c1240010>] security_socket_post_create+0x20/0x30 [<c143bdb2>] __sock_create+0x252/0x3d0 [<c1072234>] ? audit_syscall_exit+0x2d4/0x300 [<c143bf97>] sock_create+0x37/0x50 [<c143c1d6>] sys_socket+0x56/0xe0 [<c143d38f>] sys_socketcall+0x8f/0x2f0 [<c15254a1>] system_call_done+0x! 0/0x4 tsec->sid: ab, context: sys tem_u:system_r:syslogd_t:s15:c0.c1023 socksid: af, context: system_u:system_r:syslogd_s_t:s15:c0.c1023 On the command line we can see the socket security context got by the compute_create program retains the same role and MLS attribute as its creator rather than object_r and mls_systemlow as regular files: [root/sysadm_r/s0@~]# compute_create system_u:system_r:syslogd_t:s15:c0.c1023 system_u:system_r:syslogd_t:s15:c0.c1023 unix_stream_socket system_u:system_r:syslogd_t:s15:c0.c1023 [root/sysadm_r/s0@~]# [root/sysadm_r/s0@~]# compute_create system_u:system_r:syslogd_t:s15:c0.c1023 system_u:system_r:syslogd_t:s15:c0.c1023 unix_dgram_socket system_u:system_r:syslogd_s_t:s15:c0.c1023 &nbs! p; [root/sysadm_r/s0@~]# |
