SELinux-Refpolicy Archive on lore.kernel.org
 help / color / Atom feed
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: Thu, 16 Jul 2020 10:09:31 -0400
Message-ID: <f8f1e127-bab5-b67a-32c7-4f4d3abe2efc@ieee.org> (raw)
In-Reply-To: <ca477891-8d50-2681-d17e-7a358146dde9@gmail.com>

I realized that I missed this.

On 6/12/20 10:03 AM, bauen1 wrote:
> Hi,
> 
> I also agree with most things already said.
> 
> I would like to add that the way documentation is currently handled
> involves too much copy + paste of almost meaningless descriptions, but I
> haven't found a very good alternative either. (maybe adding a type
> attribute to the param xml and generating a summary based on that could
> work in the most common cases)

The original intent with the XML-based docs was for tools to use (see 
policy.xml).  As far as I know, the only tool that ever used it is long-dead 
(SLIDE).  If we can come up with with a better solution that doesn't rule-out 
the potential for tools, I'd be fine with that.  It may go better with a proper 
HLL and named interface parameters.

> On 6/12/20 3:02 PM, Russell Coker wrote:
>> Does staff_r even make sense when you could just use
>>>> different MCS categories for different users?
>>> Yes, as user_r cannot reach admin roles whereas staff_r can.
>> The user identity has a permitted list of roles, you can have users who are
>> permitted user_r and sysadm_r and users who are only permitted user_r.  The
>> original benefit of staff_r was to protect staff from attacks by user_r
>> accounts, but we can do that protection with the identity based constraints.
> 
> I would propose replacing user based constraints with role based
> constraints:
> The user part of the context (normally) doesn't change after login, this
> means that files edited by a staff_u user become inaccessible by anyone
> else, even if sudo is used to change to staff_u:sysadm_r:sysadm_t, but
> reducing the user based constraints for staff_u is undesirable.

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.

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

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.


-- 
Chris PeBenito

  reply index

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-12  0:03 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 [this message]
2020-07-19 19:29         ` bauen1
2020-07-21 14:22           ` Chris PeBenito
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=f8f1e127-bab5-b67a-32c7-4f4d3abe2efc@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

SELinux-Refpolicy Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/selinux-refpolicy/0 selinux-refpolicy/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 selinux-refpolicy selinux-refpolicy/ https://lore.kernel.org/selinux-refpolicy \
		selinux-refpolicy@vger.kernel.org
	public-inbox-index selinux-refpolicy

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.selinux-refpolicy


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git