From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Thu, 24 Feb 2011 10:52:26 -0500 Subject: [refpolicy] Separate type for AF_UNIX socket created by syslogd_t In-Reply-To: <1298554512.31953.38.camel@moss-pluto> References: <1298554512.31953.38.camel@moss-pluto> Message-ID: <4D667EBA.3060205@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 02/24/11 08:35, Stephen Smalley wrote: > On Thu, 2011-02-24 at 10:44 +0000, HarryCiao wrote: >> 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 other application domain such as klogd_t running at lower >> security level failed to "sendto" it. One possible solution is to add >> syslogd_t to mlstrustedobject attribute since the unix_dgram_socket >> object inherits the creator's SID by default. >> >> However, the side effect is that syslogd_t is also the label for the >> entire syslogd's procfs entries. The attached two patches are aimed to >> resolve this problem while eliminating such side effect, by declaring >> a separate type, syslogd_s_t, for the unix_dgram_socket object >> created by syslogd_t which alone could be added to the >> mlstrustedobject attribute. >> >> Thanks to Stephen's suggestion security_transition_sid() would be >> called in socket_sockcreate_sid() to query the relevant >> type_transition rule say in logging.pp for any newly created socket. >> >> After applying th! ese two patches below errors don't exist any more: >> >> 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 >> >> BTW, do we have a way to actually display the label for the >> unix_dgram_socket that bond to /dev/log? >> [cut] > Unfortunately my original "simple" suggestion turns out to have side > effects. At present, the socket gets the same exact security context as > the creating process by default, including the role and MLS range, since > we just assign the SID directly. But when using security_transition_sid > -> security_compute_sid, the new security context uses object_r as the > role for all objects and mls_compute_sid degrades the full MLS range to > the low level for objects. This is based on the desired behavior for > files and didn't take into account sockets. Thus with your patch, > sockets will no longer be labeled identically to their creating process, > which will affect labeled networking and the network access controls. > > To preserve existing behavior when there are no type transition rules > configured for sockets, I think security_compute_sid and mls_compute_sid > need logic handling the socket classes differently than other objects > (files). And given that we are using dynamic class mappings now, those > socket class values would have to be looked up just like the process > class upon policy load. Maybe we can come up with some generalized > solution that will be more flexible going forward for configuring how > different parts of the context are assigned for different classes. We > have talked previously about using the role field even for files rather > than just making them all object_r. It certainly would be nice to have all objects get the role of their creator so we can bring role-based policy separations back using RBAC features and not rely on 1:1 user:role mapping + UBAC. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com