SELinux-Refpolicy Archive on lore.kernel.org
 help / color / Atom feed
From: bauen1 <j2468h@googlemail.com>
To: unlisted-recipients:; (no To-header on input)
Cc: selinux-refpolicy@vger.kernel.org
Subject: Re: Are we on the wrong track?
Date: Fri, 12 Jun 2020 16:03:39 +0200
Message-ID: <ca477891-8d50-2681-d17e-7a358146dde9@gmail.com> (raw)
In-Reply-To: <2469682.qIgoumM3a6@liv>

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)

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.

Those are just my 2 cents,

bauen1



  reply index

Thread overview: 18+ 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 [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=ca477891-8d50-2681-d17e-7a358146dde9@gmail.com \
    --to=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