SELinux-Refpolicy Archive on lore.kernel.org
 help / color / Atom feed
From: Dominick Grift <dac.override@gmail.com>
To: Chris PeBenito <pebenito@ieee.org>
Cc: Laurent Bigonville <bigon@debian.org>, selinux-refpolicy@vger.kernel.org
Subject: Re: [PATCH 05/10] Allow colord_t to read the color profile stored in ~/.local/share/icc/
Date: Sat, 12 Oct 2019 18:09:34 +0200
Message-ID: <20191012160934.GA3589@brutus.lan> (raw)
In-Reply-To: <f0b189cf-81d6-c567-2224-45ce70bcc796@ieee.org>

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

On Sat, Oct 12, 2019 at 11:51:43AM -0400, Chris PeBenito wrote:
> On 10/12/19 3:53 AM, Dominick Grift wrote:
> > On Fri, Oct 11, 2019 at 02:54:23PM +0200, Dominick Grift wrote:
> > > On Fri, Oct 11, 2019 at 02:24:11PM +0200, Laurent Bigonville wrote:
> > > > From: Laurent Bigonville <bigon@bigon.be>
> > > > 
> > > > colord reads the color profiles files that are stored in
> > > > ~/.local/share/icc/, The file descriptor to that file is passed over
> > > > D-Bus so it needs to be inherited
> > > 
> > > This patch is cutting corners a little. It only takes unconfined_t into account and not the confined users (an alternative would be to call "userdom_use_all_users_fds(colord_t)" instead. Which is arguable too broad as well but closest you can get to "common users" without surgery.
> > > Secondly xdg_read_data_files() is a little broad.
> > > Also if this patch implies that whatever maintains XDG_DATA_DIR/icc is able to maintain generic xdg data files, which is arguable broad as well.
> > > 
> > > The second and third argument are subject to how far you want to take things, and so I won't object if that is not addressed.
> > > The fd use issue, in my view, should be addressed for all login (common) users with colord access.
> > 
> > Actually, I take this review back. I am not sure how to best deal with this fd.
> 
> It seems that going to a colord_role() would be the way to go.  There
> already is a colord_dbus_chat($1_t) in userdomain.if, so you could put those
> dbus rules plus the rules to address the fds together.
> 
> I agree the xdg_read_data_files() is somewhat broad, but it seems like
> xdg_data_t files aren't sensitive.  Maybe that's just how it is on system?
> I don't feel strongly on this.

Yes it depends i guess. The thing is that like /usr theres really all kinds of things below  ~/.local, like bin, lib, doc etc (pip for example installs to ~/.local/{bin,lib}).
So I would surely at least consider that beforehand

ls -aZ ~/.local/
wheel.id:wheel.role:users.generic_home_data.home_data_file:s0 .            wheel.id:wheel.role:users.home_libraries.home_file:s0 lib
                   wheel.id:wheel.role:users.home_dir.file:s0 ..   wheel.id:wheel.role:users.generic_home_data.home_data_file:s0 share
         wheel.id:wheel.role:users.home_commands.home_file:s0 bin

There's also other gotchas, take for example your personal libvirt pool in ~/.local, this content may potentially also be need to be accessible by the qemu user.

I guess what i am saying is that not everything below /usr is always just "data"

I dont have enough experience with colord to give advice, looking at my policy there's also a colord --user instance, it seems also heavily integrated with gnome-settings-daemon.

I think this patch is probably alright as is for now (maybe its best to just ignore confined users in this stage) as for further partitioning ~/.local, i suppose we can alway's revisit these changes later as this only applies to ~/.local/share/icc anyway.

If this change is one of the few controversial changes that are needed to make gnome work on debian with unconfined, then i think it might be worth it to just accept this and make a note about it to address this properly when someone wants to work on the confined support for this aspect.
> 
> -- 
> Chris PeBenito

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

  reply index

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-11 12:24 [PATCH 01/10] Allow the systemd dbus-daemon to talk to systemd Laurent Bigonville
2019-10-11 12:24 ` [PATCH 02/10] Allow geoclue to log in syslog Laurent Bigonville
2019-10-11 12:24 ` [PATCH 03/10] Allow colord_t to exec colord_exec_t type Laurent Bigonville
2019-10-11 12:24 ` [PATCH 04/10] Allow realmd_t to read localization files Laurent Bigonville
2019-10-11 12:24 ` [PATCH 05/10] Allow colord_t to read the color profile stored in ~/.local/share/icc/ Laurent Bigonville
2019-10-11 12:54   ` Dominick Grift
2019-10-12  7:53     ` Dominick Grift
2019-10-12 15:51       ` Chris PeBenito
2019-10-12 16:09         ` Dominick Grift [this message]
2019-10-15 13:09           ` Laurent Bigonville
2019-10-11 12:24 ` [PATCH 06/10] Allow alsa_t to create alsa_runtime_t file as well Laurent Bigonville
2019-10-12 15:52   ` Chris PeBenito
2019-10-15 13:10     ` Laurent Bigonville
2019-10-11 12:24 ` [PATCH 07/10] Allow alsa_t to set scheduling priority and send signal to itself Laurent Bigonville
2019-10-11 12:24 ` [PATCH 08/10] Allow colord_t to read snmpd_var_lib_t files Laurent Bigonville
2019-10-11 12:24 ` [PATCH 09/10] Allow systemd_locale_t to talk to systemd notify socket Laurent Bigonville
2019-10-11 12:24 ` [PATCH 10/10] Allow vpnc to create and write its pid file in /run/NetworkManager Laurent Bigonville

Reply instructions:

You may reply publically 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=20191012160934.GA3589@brutus.lan \
    --to=dac.override@gmail.com \
    --cc=bigon@debian.org \
    --cc=pebenito@ieee.org \
    --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