|
Many thanks Stephen and Chris for all your replies! In the first stage I will try to preserve the existing behaviors for socket by taking all kinds of socket classes in to account in security/mls_compute_sid() and re-send patches for SELinux kernel drivers. Yep so far these two functions could only take care of the special needs for the process class. Best regards, Harry > Date: Thu, 24 Feb 2011 10:52:26 -0500 > From: cpebenito@xxxxxxxxxx > To: sds@xxxxxxxxxxxxx > CC: harrytaurus2002@xxxxxxxxxxx; paul.moore@xxxxxx; selinux@xxxxxxxxxxxxx; refpolicy@xxxxxxxxxxxxxxx > Subject: Re: Separate type for AF_UNIX socket created by syslogd_t > > 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 > >> 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_tra! nsition rule say in logging.pp for any newly created socket. > & gt;> > >> 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 secur! ity 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 tha! t 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 |
