diff for duplicates of <SNT139-w65E511393D442CFCC6F92EABDC0@phx.gbl> diff --git a/a/1.txt b/N1/1.txt index 3132318..736c5c4 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -7,9 +7,9 @@ Best regards, Harry > Date: Thu, 24 Feb 2011 10:52:26 -0500 -> From: cpebenito@tresys.com -> To: sds@tycho.nsa.gov -> CC: harrytaurus2002@hotmail.com; paul.moore@hp.com; selinux@tycho.nsa.gov; refpolicy@oss1.tresys.com +> From: cpebenito at tresys.com +> To: sds at tycho.nsa.gov +> CC: harrytaurus2002 at hotmail.com; paul.moore at hp.com; selinux at tycho.nsa.gov; refpolicy at oss1.tresys.com > Subject: Re: Separate type for AF_UNIX socket created by syslogd_t > > On 02/24/11 08:35, Stephen Smalley wrote: @@ -75,3 +75,7 @@ Harry > Chris PeBenito > Tresys Technology, LLC > www.tresys.com | oss.tresys.com + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110226/5368a47b/attachment.html diff --git a/a/2.bin b/a/2.bin deleted file mode 100644 index 7a74e09..0000000 --- a/a/2.bin +++ /dev/null @@ -1,24 +0,0 @@ -<html> -<head> -<style><!-- -.hmmessage P -{ -margin:0px; -padding:0px -} -body.hmmessage -{ -font-size: 10pt; -font-family:΢ÈíÑÅºÚ -} ---></style> -</head> -<body class='hmmessage'> -Many thanks Stephen and Chris for all your replies!<br><br>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.<br><br>Best regards,<br>Harry<br><br>> Date: Thu, 24 Feb 2011 10:52:26 -0500<br>> From: cpebenito@tresys.com<br>> To: sds@tycho.nsa.gov<br>> CC: harrytaurus2002@hotmail.com; paul.moore@hp.com; selinux@tycho.nsa.gov; refpolicy@oss1.tresys.com<br>> Subject: Re: Separate type for AF_UNIX socket created by syslogd_t<br>> <br>> On 02/24/11 08:35, Stephen Smalley wrote:<br>> > On Thu, 2011-02-24 at 10:44 +0000, HarryCiao wrote:<br>> >> Since syslogd_t runs at mls_systemhigh, both the /dev/log file and the<br>> >> unix_dgram_socket object bond to it are of mls_systemhigh, rendering<b! - r>> >> that other application domain such as klogd_t running at lower<br>> >> security level failed to "sendto" it. One possible solution is to add<br>> >> syslogd_t to mlstrustedobject attribute since the unix_dgram_socket<br>> >> object inherits the creator's SID by default.<br>> >><br>> >> However, the side effect is that syslogd_t is also the label for the<br>> >> entire syslogd's procfs entries. The attached two patches are aimed to<br>> >> resolve this problem while eliminating such side effect, by declaring<br>> >> a separate type, syslogd_s_t, for the unix_dgram_socket object<br>> >> created by syslogd_t which alone could be added to the<br>> >> mlstrustedobject attribute.<br>> >><br>> >> Thanks to Stephen's suggestion security_transition_sid() would be<br>> >> called in socket_sockcreate_sid() to query the relevant<br>> >> type_tra! - nsition rule say in logging.pp for any newly created socket.<br>> & -gt;><br>> >> After applying th! ese two patches below errors don't exist any more:<br>> >><br>> >> type=1400 audit(1298535101.654:868): avc: denied { sendto } for<br>> >> pid=385 comm="klogd" path="/dev/log"<br>> >> scontext=system_u:object_r:klogd_t:s0<br>> >> tcontext=system_u:object_r:syslogd_t:s15:c0.c1023<br>> >> tclass=unix_dgram_socket<br>> >><br>> >> BTW, do we have a way to actually display the label for the<br>> >> unix_dgram_socket that bond to /dev/log?<br>> >><br>> [cut]<br>> > Unfortunately my original "simple" suggestion turns out to have side<br>> > effects. At present, the socket gets the same exact security context as<br>> > the creating process by default, including the role and MLS range, since<br>> > we just assign the SID directly. But when using security_transition_sid<br>> > -> security_compute_sid, the new secur! - ity context uses object_r as the<br>> > role for all objects and mls_compute_sid degrades the full MLS range to<br>> > the low level for objects. This is based on the desired behavior for<br>> > files and didn't take into account sockets. Thus with your patch,<br>> > sockets will no longer be labeled identically to their creating process,<br>> > which will affect labeled networking and the network access controls.<br>> > <br>> > To preserve existing behavior when there are no type transition rules<br>> > configured for sockets, I think security_compute_sid and mls_compute_sid<br>> > need logic handling the socket classes differently than other objects<br>> > (files). And given that we are using dynamic class mappings now, those<br>> > socket class values would have to be looked up just like the process<br>> > class upon policy load. Maybe we can come up with some generalized<br>> > solution tha! - t will be more flexible going forward for configuring how<br>> > - different parts of the context are assigned for different classes. We<br>> > have talked previously about using the role field even for files rather<br>> > than just making them all object_r.<br>> <br>> It certainly would be nice to have all objects get the role of their<br>> creator so we can bring role-based policy separations back using RBAC<br>> features and not rely on 1:1 user:role mapping + UBAC.<br>> <br>> <br>> -- <br>> Chris PeBenito<br>> Tresys Technology, LLC<br>> www.tresys.com | oss.tresys.com<br> </body> -</html> diff --git a/a/2.hdr b/a/2.hdr deleted file mode 100644 index be44a7c..0000000 --- a/a/2.hdr +++ /dev/null @@ -1,2 +0,0 @@ -Content-Type: text/html; charset="gb2312" -Content-Transfer-Encoding: 8bit diff --git a/a/content_digest b/N1/content_digest index a969eca..11609c7 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,14 +1,11 @@ "ref\0SNT139-w42F5BDB103916DC8160624ABDA0@phx.gbl\0" "ref\01298554512.31953.38.camel@moss-pluto\0" "ref\04D667EBA.3060205@tresys.com\0" - "From\0HarryCiao <harrytaurus2002@hotmail.com>\0" - "Subject\0RE: Separate type for AF_UNIX socket created by syslogd_t\0" + "From\0harrytaurus2002@hotmail.com (HarryCiao)\0" + "Subject\0[refpolicy] Separate type for AF_UNIX socket created by syslogd_t\0" "Date\0Sat, 26 Feb 2011 03:29:22 +0000\0" - "To\0Christopher J. PeBenito <cpebenito@tresys.com>" - " Stephen Smalley <sds@tycho.nsa.gov>\0" - "Cc\0selinux-mailing-list <selinux@tycho.nsa.gov>" - " <refpolicy@oss1.tresys.com>\0" - "\01:1\0" + "To\0refpolicy@oss.tresys.com\0" + "\00:1\0" "b\0" "\n" "Many thanks Stephen and Chris for all your replies!\n" @@ -19,9 +16,9 @@ "Harry\n" "\n" "> Date: Thu, 24 Feb 2011 10:52:26 -0500\n" - "> From: cpebenito@tresys.com\n" - "> To: sds@tycho.nsa.gov\n" - "> CC: harrytaurus2002@hotmail.com; paul.moore@hp.com; selinux@tycho.nsa.gov; refpolicy@oss1.tresys.com\n" + "> From: cpebenito at tresys.com\n" + "> To: sds at tycho.nsa.gov\n" + "> CC: harrytaurus2002 at hotmail.com; paul.moore at hp.com; selinux at tycho.nsa.gov; refpolicy at oss1.tresys.com\n" "> Subject: Re: Separate type for AF_UNIX socket created by syslogd_t\n" "> \n" "> On 02/24/11 08:35, Stephen Smalley wrote:\n" @@ -86,32 +83,10 @@ "> -- \n" "> Chris PeBenito\n" "> Tresys Technology, LLC\n" - > www.tresys.com | oss.tresys.com - "\01:2\0" - "b\0" - "<html>\n" - "<head>\n" - "<style><!--\n" - ".hmmessage P\n" - "{\n" - "margin:0px;\n" - "padding:0px\n" - "}\n" - "body.hmmessage\n" - "{\n" - "font-size: 10pt;\n" - "font-family:\316\242\310\355\321\305\272\332\n" - "}\n" - "--></style>\n" - "</head>\n" - "<body class='hmmessage'>\n" - "Many thanks Stephen and Chris for all your replies!<br><br>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.<br><br>Best regards,<br>Harry<br><br>> Date: Thu, 24 Feb 2011 10:52:26 -0500<br>> From: cpebenito@tresys.com<br>> To: sds@tycho.nsa.gov<br>> CC: harrytaurus2002@hotmail.com; paul.moore@hp.com; selinux@tycho.nsa.gov; refpolicy@oss1.tresys.com<br>> Subject: Re: Separate type for AF_UNIX socket created by syslogd_t<br>> <br>> On 02/24/11 08:35, Stephen Smalley wrote:<br>> > On Thu, 2011-02-24 at 10:44 +0000, HarryCiao wrote:<br>> >> Since syslogd_t runs at mls_systemhigh, both the /dev/log file and the<br>> >> unix_dgram_socket object bond to it are of mls_systemhigh, rendering<b!\n" - " r>> >> that other application domain such as klogd_t running at lower<br>> >> security level failed to \"sendto\" it. One possible solution is to add<br>> >> syslogd_t to mlstrustedobject attribute since the unix_dgram_socket<br>> >> object inherits the creator's SID by default.<br>> >><br>> >> However, the side effect is that syslogd_t is also the label for the<br>> >> entire syslogd's procfs entries. The attached two patches are aimed to<br>> >> resolve this problem while eliminating such side effect, by declaring<br>> >> a separate type, syslogd_s_t, for the unix_dgram_socket object<br>> >> created by syslogd_t which alone could be added to the<br>> >> mlstrustedobject attribute.<br>> >><br>> >> Thanks to Stephen's suggestion security_transition_sid() would be<br>> >> called in socket_sockcreate_sid() to query the relevant<br>> >> type_tra!\n" - " nsition rule say in logging.pp for any newly created socket.<br>> &\n" - "gt;><br>> >> After applying th! ese two patches below errors don't exist any more:<br>> >><br>> >> type=1400 audit(1298535101.654:868): avc: denied { sendto } for<br>> >> pid=385 comm=\"klogd\" path=\"/dev/log\"<br>> >> scontext=system_u:object_r:klogd_t:s0<br>> >> tcontext=system_u:object_r:syslogd_t:s15:c0.c1023<br>> >> tclass=unix_dgram_socket<br>> >><br>> >> BTW, do we have a way to actually display the label for the<br>> >> unix_dgram_socket that bond to /dev/log?<br>> >><br>> [cut]<br>> > Unfortunately my original \"simple\" suggestion turns out to have side<br>> > effects. At present, the socket gets the same exact security context as<br>> > the creating process by default, including the role and MLS range, since<br>> > we just assign the SID directly. But when using security_transition_sid<br>> > -> security_compute_sid, the new secur!\n" - " ity context uses object_r as the<br>> > role for all objects and mls_compute_sid degrades the full MLS range to<br>> > the low level for objects. This is based on the desired behavior for<br>> > files and didn't take into account sockets. Thus with your patch,<br>> > sockets will no longer be labeled identically to their creating process,<br>> > which will affect labeled networking and the network access controls.<br>> > <br>> > To preserve existing behavior when there are no type transition rules<br>> > configured for sockets, I think security_compute_sid and mls_compute_sid<br>> > need logic handling the socket classes differently than other objects<br>> > (files). And given that we are using dynamic class mappings now, those<br>> > socket class values would have to be looked up just like the process<br>> > class upon policy load. Maybe we can come up with some generalized<br>> > solution tha!\n" - " t will be more flexible going forward for configuring how<br>> >\n" - " different parts of the context are assigned for different classes. We<br>> > have talked previously about using the role field even for files rather<br>> > than just making them all object_r.<br>> <br>> It certainly would be nice to have all objects get the role of their<br>> creator so we can bring role-based policy separations back using RBAC<br>> features and not rely on 1:1 user:role mapping + UBAC.<br>> <br>> <br>> -- <br>> Chris PeBenito<br>> Tresys Technology, LLC<br>> www.tresys.com | oss.tresys.com<br> \t\t \t \t\t </body>\n" - </html> + "> www.tresys.com | oss.tresys.com\n" + " \t\t \t \t\t \n" + "-------------- next part --------------\n" + "An HTML attachment was scrubbed...\n" + URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110226/5368a47b/attachment.html -eace919a52f1e10eacb9bda6846ea9038a2d549a2a249cf18fa12f07b6960031 +73a6b20b506bba446c8dfeac140447e59a61ea3ef084192598d874f42bc42762
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.