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
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
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
http://www.tresys.com | oss.tresys.com
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
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
> http://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
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
On Fri, 4 Mar 2011, HarryCiao <[email protected]> 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/
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
http://www.tresys.com | oss.tresys.com
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