Separate type for AF_UNIX socket created by syslogd_t

Separate type for AF_UNIX socket created by syslogd_t

[HarryCiao]

[-- Attachment #1.1: Type: text/plain, Size: 1422 bytes --]


Hi,

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 these 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?

Any comments is are greatly appreciated!

Thanks a lot!

Best regards,
Harry
 		 	   		  

[-- Attachment #1.2: Type: text/html, Size: 1688 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Specify-a-separate-socket-type-for-syslogd_t.patch --]
[-- Type: text/x-patch, Size: 3419 bytes --]

From e94c680571bda94a724d33384d5345d41d9e9b6a Mon Sep 17 00:00:00 2001
From: Harry Ciao <qingtao.cao@windriver.com>
Date: Thu, 24 Feb 2011 16:23:42 +0800
Subject: [PATCH 1/1] Specify a separate socket type for syslogd_t.

Use a type_transition rule to specify a separate type for unix_dgram_socket
object created by syslogd_t, so that the socket type alone could be added
to the mlstrustedobject attrbute to avoid below 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

This helps to avoid adding syslogd_t to this attribute which also is the
label for all syslogd's procfs contents.

BTW, in SELinux kernel driver the security_transition_sid() should be
called to query above type_transition rule for the newly created socket SID.

Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
---
 policy/modules/system/logging.if |    4 ++--
 policy/modules/system/logging.te |   11 +++++++++--
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/policy/modules/system/logging.if b/policy/modules/system/logging.if
index c7cfb62..92582b0 100644
--- a/policy/modules/system/logging.if
+++ b/policy/modules/system/logging.if
@@ -525,14 +525,14 @@ interface(`logging_log_filetrans',`
 #
 interface(`logging_send_syslog_msg',`
 	gen_require(`
-		type syslogd_t, devlog_t;
+		type syslogd_t, syslogd_s_t, devlog_t;
 	')
 
 	allow $1 devlog_t:lnk_file read_lnk_file_perms;
 	allow $1 devlog_t:sock_file write_sock_file_perms;
 
 	# the type of socket depends on the syslog daemon
-	allow $1 syslogd_t:unix_dgram_socket sendto;
+	allow $1 syslogd_s_t:unix_dgram_socket sendto;
 	allow $1 syslogd_t:unix_stream_socket connectto;
 	allow $1 self:unix_dgram_socket create_socket_perms;
 	allow $1 self:unix_stream_socket create_socket_perms;
diff --git a/policy/modules/system/logging.te b/policy/modules/system/logging.te
index 9b5a9ed..2be6748 100644
--- a/policy/modules/system/logging.te
+++ b/policy/modules/system/logging.te
@@ -61,6 +61,10 @@ type syslogd_t;
 type syslogd_exec_t;
 init_daemon_domain(syslogd_t, syslogd_exec_t)
 
+# AF_UNIX socket created by syslogd
+type syslogd_s_t;
+mls_trusted_object(syslogd_s_t)
+
 type syslogd_initrc_exec_t;
 init_script_file(syslogd_initrc_exec_t)
 
@@ -344,15 +348,18 @@ dontaudit syslogd_t self:capability sys_tty_config;
 # setrlimit for syslog-ng
 allow syslogd_t self:process { signal_perms setpgid setrlimit };
 # receive messages to be logged
-allow syslogd_t self:unix_dgram_socket create_socket_perms;
+allow syslogd_t syslogd_s_t:unix_dgram_socket create_socket_perms;
 allow syslogd_t self:unix_stream_socket create_stream_socket_perms;
-allow syslogd_t self:unix_dgram_socket sendto;
+allow syslogd_t syslogd_s_t:unix_dgram_socket sendto;
 allow syslogd_t self:fifo_file rw_fifo_file_perms;
 allow syslogd_t self:udp_socket create_socket_perms;
 allow syslogd_t self:tcp_socket create_stream_socket_perms;
 
 allow syslogd_t syslog_conf_t:file read_file_perms;
 
+# AF_UNIX dgram socket created by syslogd_t labeled as syslogd_s_t
+type_transition syslogd_t syslogd_t:unix_dgram_socket syslogd_s_t;
+
 # Create and bind to /dev/log or /var/run/log.
 allow syslogd_t devlog_t:sock_file manage_sock_file_perms;
 files_pid_filetrans(syslogd_t, devlog_t, sock_file)
-- 
1.7.0.4


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0001-Compute-socket-SID.patch --]
[-- Type: text/x-patch, Size: 2269 bytes --]

From f1f85f9335fd716208e2c66cdb614fd04f963c6f Mon Sep 17 00:00:00 2001
From: Harry Ciao <qingtao.cao@windriver.com>
Date: Thu, 24 Feb 2011 13:10:13 +0800
Subject: [PATCH 1/1] Compute socket SID.

Compute SID for the newly created socket, which may be different than
its creator. In relevant policy package a type_transition rule could
be used to specify a discrete type for the socket.

Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
---
 security/selinux/hooks.c |   22 +++++++++++++++-------
 1 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index c8d6992..a5f8d5f 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -3644,9 +3644,17 @@ static int selinux_skb_peerlbl_sid(struct sk_buff *skb, u16 family, u32 *sid)
 
 /* socket security operations */
 
-static u32 socket_sockcreate_sid(const struct task_security_struct *tsec)
+static u32 socket_sockcreate_sid(const struct task_security_struct *tsec,
+				 u16 secclass)
 {
-	return tsec->sockcreate_sid ? : tsec->sid;
+	int rc;
+	u32 socksid;
+
+	rc = security_transition_sid(tsec->sid, tsec->sid, secclass, &socksid);
+	if (rc)
+		return tsec->sockcreate_sid ? : tsec->sid;
+	else
+		return tsec->sockcreate_sid ? : socksid;
 }
 
 static int sock_has_perm(struct task_struct *task, struct sock *sk, u32 perms)
@@ -3674,8 +3682,8 @@ static int selinux_socket_create(int family, int type,
 	if (kern)
 		return 0;
 
-	newsid = socket_sockcreate_sid(tsec);
 	secclass = socket_type_to_security_class(family, type, protocol);
+	newsid = socket_sockcreate_sid(tsec, secclass);
 	return avc_has_perm(tsec->sid, newsid, secclass, SOCKET__CREATE, NULL);
 }
 
@@ -3687,13 +3695,13 @@ static int selinux_socket_post_create(struct socket *sock, int family,
 	struct sk_security_struct *sksec;
 	int err = 0;
 
+	isec->sclass = socket_type_to_security_class(family, type, protocol);
+	isec->initialized = 1;
+
 	if (kern)
 		isec->sid = SECINITSID_KERNEL;
 	else
-		isec->sid = socket_sockcreate_sid(tsec);
-
-	isec->sclass = socket_type_to_security_class(family, type, protocol);
-	isec->initialized = 1;
+		isec->sid = socket_sockcreate_sid(tsec, isec->sclass);
 
 	if (sock->sk) {
 		sksec = sock->sk->sk_security;
-- 
1.7.0.4

[refpolicy] Separate type for AF_UNIX socket created by syslogd_t

[HarryCiao]

Hi,

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 these 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?

Any comments is are greatly appreciated!

Thanks a lot!

Best regards,
Harry
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110224/fac899ee/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Specify-a-separate-socket-type-for-syslogd_t.patch
Type: text/x-patch
Size: 3419 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110224/fac899ee/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Compute-socket-SID.patch
Type: text/x-patch
Size: 2269 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110224/fac899ee/attachment-0003.bin 

Re: Separate type for AF_UNIX socket created by syslogd_t

[Stephen Smalley]

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?
> 
> Any comments is are greatly appreciated!

Hi,

You should separately post the kernel patch as its own message,
preferably inline so that it can be easily reviewed and commented upon.
Make sure you have read and are following
Documentation/SubmittingPatches and that the posting explicitly cc's the
SELinux maintainers listed in MAINTAINERS.  I wouldn't bother reposting
the policy patch again until/unless the kernel patch is agreed upon, as
it won't make sense to review it until that time.

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.

On the implementation:
- security_transition_sid() error case likely needs to be propagated to
the hook and up to the caller of the hook rather than just defaulting to
the old behavior upon error.
- Don't move the setting of isec->initialized before isec->sid has been
set.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] Separate type for AF_UNIX socket created by syslogd_t

[Stephen Smalley]

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?
> 
> Any comments is are greatly appreciated!

Hi,

You should separately post the kernel patch as its own message,
preferably inline so that it can be easily reviewed and commented upon.
Make sure you have read and are following
Documentation/SubmittingPatches and that the posting explicitly cc's the
SELinux maintainers listed in MAINTAINERS.  I wouldn't bother reposting
the policy patch again until/unless the kernel patch is agreed upon, as
it won't make sense to review it until that time.

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.

On the implementation:
- security_transition_sid() error case likely needs to be propagated to
the hook and up to the caller of the hook rather than just defaulting to
the old behavior upon error.
- Don't move the setting of isec->initialized before isec->sid has been
set.

-- 
Stephen Smalley
National Security Agency

Re: Separate type for AF_UNIX socket created by syslogd_t

[Christopher J. PeBenito]

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

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] Separate type for AF_UNIX socket created by syslogd_t

[Christopher J. PeBenito]

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

Re: Separate type for AF_UNIX socket created by syslogd_t

[Stephen Smalley]

On Thu, 2011-02-24 at 10:44 +0000, HarryCiao wrote:
> BTW, do we have a way to actually display the label for the
> unix_dgram_socket that bond to /dev/log?

I think the answer is no at present.
netstat -Z claims to report the socket context but is actually just
reading /proc/pid/attr/current of the owning process.

The owning application can get the context of the socket (inode) via
fgetxattr(), but I don't think a third party can presently obtain the
context information.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] Separate type for AF_UNIX socket created by syslogd_t

[Stephen Smalley]

On Thu, 2011-02-24 at 10:44 +0000, HarryCiao wrote:
> BTW, do we have a way to actually display the label for the
> unix_dgram_socket that bond to /dev/log?

I think the answer is no at present.
netstat -Z claims to report the socket context but is actually just
reading /proc/pid/attr/current of the owning process.

The owning application can get the context of the socket (inode) via
fgetxattr(), but I don't think a third party can presently obtain the
context information.

-- 
Stephen Smalley
National Security Agency

RE: Separate type for AF_UNIX socket created by syslogd_t

[HarryCiao]

[-- Attachment #1: Type: text/plain, Size: 3989 bytes --]


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@tresys.com
> To: sds@tycho.nsa.gov
> CC: harrytaurus2002@hotmail.com; paul.moore@hp.com; selinux@tycho.nsa.gov; refpolicy@oss1.tresys.com
> 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
> >> 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
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 4864 bytes --]

[refpolicy] Separate type for AF_UNIX socket created by syslogd_t

[HarryCiao]

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 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:
> > 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
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110226/5368a47b/attachment.html 

Further questions about configuring contexts differently for variant classes

[HarryCiao]

[-- Attachment #1: Type: text/plain, Size: 1552 bytes --]


Hi Stephen and Chris,

I would like to dig deeper on this topic and I have started thinking below questions as a starting point, it definitively would help me to get warmed up quickly if you could help pointing me at the background story :-)

[cut]
> > ... 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.
> 

1. Would it work simply to make the newly created objects have the role of "scontext->role" than "object_r" in security_compute_sid?
2. If files' role is not "object_r" anymore, what changes in refpolicy and SELinux kernel space would have to be done accordingly?
3. Where can I find our previously talks on such topic?

> 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.

4. It seems that we used to have RBAC, then why we have to have dropped it?
5. Does the "1:1 user:role mapping" mean the mapping from linux user to selinux user, and the mapping from selinux user to the roles that he/she could assume?
6. Any discussion email thread about how UBAC works and why we would want "1:1 user:role mapping + UBAC"?

I know I've asked a lot of silly questions, thanks a lot for your time and patience!

Best regards,
Harry
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 1945 bytes --]

[refpolicy] Further questions about configuring contexts differently for variant classes

[HarryCiao]

Hi Stephen and Chris,

I would like to dig deeper on this topic and I have started thinking below questions as a starting point, it definitively would help me to get warmed up quickly if you could help pointing me at the background story :-)

[cut]
> > ... 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.
> 

1. Would it work simply to make the newly created objects have the role of "scontext->role" than "object_r" in security_compute_sid?
2. If files' role is not "object_r" anymore, what changes in refpolicy and SELinux kernel space would have to be done accordingly?
3. Where can I find our previously talks on such topic?

> 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.

4. It seems that we used to have RBAC, then why we have to have dropped it?
5. Does the "1:1 user:role mapping" mean the mapping from linux user to selinux user, and the mapping from selinux user to the roles that he/she could assume?
6. Any discussion email thread about how UBAC works and why we would want "1:1 user:role mapping + UBAC"?

I know I've asked a lot of silly questions, thanks a lot for your time and patience!

Best regards,
Harry
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110304/78a5c31f/attachment.html 

[refpolicy] Further questions about configuring contexts differently for variant classes

[Russell Coker]

On Fri, 4 Mar 2011, HarryCiao <harrytaurus2002@hotmail.com> wrote:
> > 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.
> 
> 4. It seems that we used to have RBAC, then why we have to have dropped it?
> 5. Does the "1:1 user:role mapping" mean the mapping from linux user to
> selinux user, and the mapping from selinux user to the roles that he/she
> could assume? 6. Any discussion email thread about how UBAC works and why
> we would want "1:1 user:role mapping + UBAC"?

The RBAC we used to have was based on the role for a process context being 
used to determine the set of domains used by processes that it may launch, and 
the domains used by those processes determined the types of files.

So user_r process role gets user_t as the main domain which can write to 
user_home_t.  staff_r process role gets staff_t as the domain and can write to 
staff_home_t.  There were also domains like user_mozilla_t and staff_mozilla_t 
which do what you probably expect.  But all files created by all of those 
processes had the role object_r.

During the time that I've been working on SE Linux (since mid 2001) there has 
never been a role used for real files (as opposed to labels on /proc entries 
etc) other than object_r.

The idea of giving objects the role of their creator relies on kernel code 
which AFAIK has never been written in the history of SE Linux (unless it 
happened to be in the very early versions).

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: Further questions about configuring contexts differently for variant classes

[Christopher J. PeBenito]

On 03/04/11 05:38, HarryCiao wrote:
> Hi Stephen and Chris,
> 
> I would like to dig deeper on this topic and I have started thinking
> below questions as a starting point, it definitively would help me to
> get warmed up quickly if you could help pointing me at the background
> story :-)
> 
> [cut]
>> > ... 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.
>>
> 
> 1. Would it work simply to make the newly created objects have the role
> of "scontext->role" than "object_r" in security_compute_sid?
> 2. If files' role is not "object_r" anymore, what changes in refpolicy
> and SELinux kernel space would have to be done accordingly?

We would have to make sure that the file types are associated with each
of the applicable roles.  Probably a little file_context adjustment
w.r.t. genhomedircon.  In the end, not much.

> 3 . Where can I find our previously talks on such topic?

Previous discussions were on the SELinux list

http://marc.info/?l=selinux&m=120948509805194&w=2
http://marc.info/?l=selinux&m=121010532820562&w=2
http://marc.info/?l=selinux&m=121198575124942&w=2
http://marc.info/?l=selinux&m=121313312830959&w=2
http://marc.info/?l=selinux&m=121423386122213&w=2
http://marc.info/?l=selinux&m=121372927211476&w=2
http://marc.info/?l=selinux&m=121622490905223&w=2

Those are all the threads I could find, though there may have been more.

>> 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.
> 
> 4. It seems that we used to have RBAC, then why we have to have dropped it?
> 5. Does the "1:1 user:role mapping" mean the mapping from linux user to
> selinux user, and the mapping from selinux user to the roles that he/she
> could assume?
> 6. Any discussion email thread about how UBAC works and why we would
> want "1:1 user:role mapping + UBAC"?

If you look at Russell's response, he mentions derived type domains that
have the role encoded in it, eg staff_mozilla_t and user_mozilla_t.
Each of those types was only allowed for the corresponding role, eg
staff_mozilla_t only worked with staff_r.  When we stopped encoding the
role in the types, we wanted to use the role itself to separate
mozilla_t, i.e:

staff_r:staff_mozilla_t -> staff_r:mozilla_t
user_r:user_mozilla_t -> user_r:mozilla_t

and then we would use constraints so that access to and from mozilla_t
would require role equality (i.e the role of the source context has to
equal the role of the target context).  This would remove a significant
amount of policy since each of these derived domains had the same policy
except the role was different.

But this didn't work in the end because when files are created they
always get object_r; they couldn't be configured via a role_transition
to do anything different.  So we had to use the user field.  Its not the
same thing as role separation if a user has more than one role, eg.

staff_u:staff_r:mozilla_t could talk to staff_u:sysadm_r:mozilla_t

but we decided it was ok since general users don't have a problem with,
and the higher assurance people that use selinux usually don't have more
than one role associated with a particular seuser.  What I mean by the
1:1 user:role mapping is that each seuser only has one role.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] Further questions about configuring contexts differently for variant classes

[Christopher J. PeBenito]

On 03/04/11 05:38, HarryCiao wrote:
> Hi Stephen and Chris,
> 
> I would like to dig deeper on this topic and I have started thinking
> below questions as a starting point, it definitively would help me to
> get warmed up quickly if you could help pointing me at the background
> story :-)
> 
> [cut]
>> > ... 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.
>>
> 
> 1. Would it work simply to make the newly created objects have the role
> of "scontext->role" than "object_r" in security_compute_sid?
> 2. If files' role is not "object_r" anymore, what changes in refpolicy
> and SELinux kernel space would have to be done accordingly?

We would have to make sure that the file types are associated with each
of the applicable roles.  Probably a little file_context adjustment
w.r.t. genhomedircon.  In the end, not much.

> 3 . Where can I find our previously talks on such topic?

Previous discussions were on the SELinux list

http://marc.info/?l=selinux&m=120948509805194&w=2
http://marc.info/?l=selinux&m=121010532820562&w=2
http://marc.info/?l=selinux&m=121198575124942&w=2
http://marc.info/?l=selinux&m=121313312830959&w=2
http://marc.info/?l=selinux&m=121423386122213&w=2
http://marc.info/?l=selinux&m=121372927211476&w=2
http://marc.info/?l=selinux&m=121622490905223&w=2

Those are all the threads I could find, though there may have been more.

>> 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.
> 
> 4. It seems that we used to have RBAC, then why we have to have dropped it?
> 5. Does the "1:1 user:role mapping" mean the mapping from linux user to
> selinux user, and the mapping from selinux user to the roles that he/she
> could assume?
> 6. Any discussion email thread about how UBAC works and why we would
> want "1:1 user:role mapping + UBAC"?

If you look at Russell's response, he mentions derived type domains that
have the role encoded in it, eg staff_mozilla_t and user_mozilla_t.
Each of those types was only allowed for the corresponding role, eg
staff_mozilla_t only worked with staff_r.  When we stopped encoding the
role in the types, we wanted to use the role itself to separate
mozilla_t, i.e:

staff_r:staff_mozilla_t -> staff_r:mozilla_t
user_r:user_mozilla_t -> user_r:mozilla_t

and then we would use constraints so that access to and from mozilla_t
would require role equality (i.e the role of the source context has to
equal the role of the target context).  This would remove a significant
amount of policy since each of these derived domains had the same policy
except the role was different.

But this didn't work in the end because when files are created they
always get object_r; they couldn't be configured via a role_transition
to do anything different.  So we had to use the user field.  Its not the
same thing as role separation if a user has more than one role, eg.

staff_u:staff_r:mozilla_t could talk to staff_u:sysadm_r:mozilla_t

but we decided it was ok since general users don't have a problem with,
and the higher assurance people that use selinux usually don't have more
than one role associated with a particular seuser.  What I mean by the
1:1 user:role mapping is that each seuser only has one role.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

Re: Further questions about configuring contexts differently for variant classes

[Stephen Smalley]

On Fri, 2011-03-04 at 10:38 +0000, HarryCiao wrote:
> Hi Stephen and Chris,
> 
> I would like to dig deeper on this topic and I have started thinking
> below questions as a starting point, it definitively would help me to
> get warmed up quickly if you could help pointing me at the background
> story :-)
> 
> [cut]
> > > ... 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.
> > 
> 
> 1. Would it work simply to make the newly created objects have the
> role of "scontext->role" than "object_r" in security_compute_sid?

No, that would break existing policies.  We need a way to allow existing
systems to still use object_r while allowing future policies to leverage
new support for using the role field in object security contexts.  I
sketched one possible approach in the earlier thread that Chris
referenced, i.e. inherit from tcontext->role (parent directory) and add
role transition support on object classes.  Then on existing systems
where directories are labeled object_r, everything will still work as
before, but with new policies, we can set up role transitions on the
file classes to use the subject role where that is desired.

> 2. If files' role is not "object_r" anymore, what changes in refpolicy
> and SELinux kernel space would have to be done accordingly?

In the kernel, we check for OBJECT_R_VAL and exempt security contexts
with that role from the validation checks on user-role, role-type, and
user-range.  So using subject roles on objects will enable that checking
and require that the policy explicitly authorize those pairings.

> ! 3. Where can I find our previously talks on such topic?

Looks like Chris did a good job of hunting down the prior discussions.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] Further questions about configuring contexts differently for variant classes

[Stephen Smalley]

On Fri, 2011-03-04 at 10:38 +0000, HarryCiao wrote:
> Hi Stephen and Chris,
> 
> I would like to dig deeper on this topic and I have started thinking
> below questions as a starting point, it definitively would help me to
> get warmed up quickly if you could help pointing me at the background
> story :-)
> 
> [cut]
> > > ... 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.
> > 
> 
> 1. Would it work simply to make the newly created objects have the
> role of "scontext->role" than "object_r" in security_compute_sid?

No, that would break existing policies.  We need a way to allow existing
systems to still use object_r while allowing future policies to leverage
new support for using the role field in object security contexts.  I
sketched one possible approach in the earlier thread that Chris
referenced, i.e. inherit from tcontext->role (parent directory) and add
role transition support on object classes.  Then on existing systems
where directories are labeled object_r, everything will still work as
before, but with new policies, we can set up role transitions on the
file classes to use the subject role where that is desired.

> 2. If files' role is not "object_r" anymore, what changes in refpolicy
> and SELinux kernel space would have to be done accordingly?

In the kernel, we check for OBJECT_R_VAL and exempt security contexts
with that role from the validation checks on user-role, role-type, and
user-range.  So using subject roles on objects will enable that checking
and require that the policy explicitly authorize those pairings.

> ! 3. Where can I find our previously talks on such topic?

Looks like Chris did a good job of hunting down the prior discussions.

-- 
Stephen Smalley
National Security Agency