From: Chris PeBenito <pebenito@ieee.org>
To: bauen1 <j2468h@googlemail.com>
Cc: selinux-refpolicy@vger.kernel.org
Subject: Re: Are we on the wrong track?
Date: Tue, 21 Jul 2020 10:22:46 -0400 [thread overview]
Message-ID: <63612ad4-967b-18b0-2667-1f6b74c19e5d@ieee.org> (raw)
In-Reply-To: <03249797-9067-34f1-c4ec-39f163fb9042@gmail.com>
On 7/19/20 3:29 PM, bauen1 wrote:
> On 7/16/20 4:09 PM, Chris PeBenito wrote:
>> This behavior depends on the type of the file. If you end up with a staff_u:object_r:etc_t context, the user separations don't apply since this is not a user file.
>
> I'll have to take another look at it then.
>
>> We used to have role based separations but it was encoded into the TE rules and generated an enormous amount of rule duplication. There are some remaining examples of this, e.g. in the su and sudo policies (staff_su_t, sysadm_su_t).
>
> There are cases where these will still be necessary, mainly when type transitions to the user type are required, but some could be eliminated.
Right, there will always be needs like this. Which ones could be eliminated? I
can't immediately think of an example.
>> When the default_* statements were implemented I started to reimplement the role-based separations using the role, but then I lost the work before I finished. I don't think it is too involved, since it may be as simple copying the UBAC infrastructure and tweaking it to work on roles.
>
> I've also worked on implementing RBAC and RBACSEP for refpolicy (A bit messy: https://github.com/bauen1/refpolicy/tree/rbac) . If this becomes a goal to implement, perhaps https://github.com/SELinuxProject/refpolicy/pull/203 could be merged first.
It's a goal, but it hasn't been a high enough priority for someone invest the
time in it.
--
Chris PeBenito
next prev parent reply other threads:[~2020-07-21 14:22 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-12 0:03 Are we on the wrong track? Russell Coker
2020-06-12 7:05 ` Topi Miettinen
2020-06-12 8:02 ` Dac Override
2020-06-12 9:54 ` Russell Coker
2020-06-12 10:15 ` Dominick Grift
2020-06-12 12:05 ` Russell Coker
2020-06-12 12:26 ` Dominick Grift
2020-06-12 12:53 ` Russell Coker
2020-06-12 13:20 ` Dominick Grift
2020-06-14 16:30 ` Topi Miettinen
2020-06-12 11:00 ` Denis Obrezkov
2020-06-12 11:53 ` Russell Coker
2020-06-12 11:57 ` Dominick Grift
2020-06-12 12:52 ` Chris PeBenito
2020-06-12 13:02 ` Russell Coker
2020-06-12 14:03 ` bauen1
2020-07-16 14:09 ` Chris PeBenito
2020-07-19 19:29 ` bauen1
2020-07-21 14:22 ` Chris PeBenito [this message]
2020-06-15 13:52 ` Chris PeBenito
2020-06-15 21:02 ` Russell Coker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=63612ad4-967b-18b0-2667-1f6b74c19e5d@ieee.org \
--to=pebenito@ieee.org \
--cc=j2468h@googlemail.com \
--cc=selinux-refpolicy@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).