From:   Russell Coker <russell@coker.com.au>
To:     Chris PeBenito <pebenito@ieee.org>
Cc:     "selinux-refpolicy@vger.kernel.org" 
        <selinux-refpolicy@vger.kernel.org>
Subject: Re: [PATCH] chromium
Date:   Wed, 30 Jan 2019 23:52:55 +1100
Message-ID: <1789160.NphhQl3YFJ@liv>
In-Reply-To: <743dd8f5-9288-8216-4551-b7a74fda3e6d@ieee.org>
References: <20190128084648.GA5441@xev> <743dd8f5-9288-8216-4551-b7a74fda3e6d@ieee.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Sender: selinux-refpolicy-owner@vger.kernel.org
Precedence: bulk

On Wednesday, 30 January 2019 10:53:54 AM AEDT Chris PeBenito wrote:
> > I don't know what this is for but doesn't seem harmful to allow it:
> > type=PROCTITLE msg=audit(28/01/19 19:31:42.361:3218) : proctitle=/bin/bash
> > /usr/bin/google-chrome type=SYSCALL msg=audit(28/01/19 19:31:42.361:3218)
> > : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c
> > a1=0x563328f7b590 a2=O_WRONLY|O_CREAT|O_TRUNC a3=0x1b6 items=0 ppid=5158
> > pid=5166 auid=test uid=test gid=test euid=test suid=test fsuid=test
> > egid=test sgid=test fsgid=test tty=pts7 ses=232 comm=google-chrome
> > exe=/bin/bash subj=user_u:user_r:chromium_t:s0 key=(null) type=AVC
> > msg=audit(28/01/19 19:31:42.361:3218) : avc:  granted  { associate } for 
> > pid=5166 comm=google-chrome name=63
> > scontext=user_u:object_r:chromium_t:s0
> > tcontext=system_u:object_r:proc_t:s0 tclass=filesystem type=AVC
> > msg=audit(28/01/19 19:31:42.361:3218) : avc:  granted  { create } for 
> > pid=5166 comm=google-chrome name=63 scontext=user_u:user_r:chromium_t:s0
> > tcontext=user_u:object_r:chromium_t:s0 tclass=file type=AVC
> > msg=audit(28/01/19 19:31:42.361:3218) : avc:  granted  { add_name } for 
> > pid=5166 comm=google-chrome name=63 scontext=user_u:user_r:chromium_t:s0
> > tcontext=user_u:user_r:chromium_t:s0 tclass=dir
> > 
> > Index: refpolicy-2.20180701/policy/modules/apps/chromium.te
> > ===================================================================
> > --- refpolicy-2.20180701.orig/policy/modules/apps/chromium.te
> > +++ refpolicy-2.20180701/policy/modules/apps/chromium.te
> > @@ -78,6 +78,8 @@ xdg_cache_content(chromium_xdg_cache_t)
> > 
> > # execmem for load in plugins
> > allow chromium_t self:process { execmem getsched getcap setcap setrlimit
> > setsched sigkill signal }; +allow chromium_t self:dir { write add_name };
> > +allow chromium_t self:file create;
> 
> I dropped this and the related proc_t associate.  I would like to have a
> better understanding what is happening.  The domain type on
> file/dir/lnk_file is supposed to be exclusively for the the /proc/pid
> entries.  The domain shouldn't be creating files with this type.  The
> fact that it is creating it in proc is even weirder.

It seems easily repeatable by starting Chrome.  I don't know why openat() is 
triggering that.  I'll leave this in the Debian tree and come back to it 
later.
 
> > -xdg_create_cache_dirs(chromium_t)
> > -xdg_create_config_dirs(chromium_t)
> > -xdg_create_data_dirs(chromium_t)
> > +xdg_manage_cache(chromium_t)
> > +xdg_manage_config(chromium_t)
> > +xdg_manage_data(chromium_t)
> 
> It seems like it might be best to have chromium-specific
> cache/data/config if it is modifying them.

I guess.  I'll leave that in the Debian tree, I don't have time to do more 
about this at the moment.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/