From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A157C282D7 for ; Wed, 30 Jan 2019 13:25:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4B3A02184D for ; Wed, 30 Jan 2019 13:25:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=coker.com.au header.i=@coker.com.au header.b="JqRbvGj6" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726332AbfA3NZt (ORCPT ); Wed, 30 Jan 2019 08:25:49 -0500 Received: from smtp.sws.net.au ([46.4.88.250]:50564 "EHLO smtp.sws.net.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725851AbfA3NZt (ORCPT ); Wed, 30 Jan 2019 08:25:49 -0500 Received: from liv.localnet (localhost [127.0.0.1]) by smtp.sws.net.au (Postfix) with ESMTP id 87697ED93; Thu, 31 Jan 2019 00:25:46 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coker.com.au; s=2008; t=1548854747; bh=m94+0rg0vzCqve4Q3pcooADoIE8e3e2K/JAbOMtDJ80=; l=2919; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JqRbvGj6S9eaQWvK55HVJ8/6ta1b+55gZWmpGG3vwyEhOd6cNbyPY9dklmtJe4dst 5b/4I8JNQTcGvuAamltWM7/guA6eedaKy5tgglnKSsJmitb+ddeJ8GZBojlXJnfS81 yf9gtaVqEoQaDBErYEnn4fOF7Hu/rEgEqZY/gdzY= From: Russell Coker To: Chris PeBenito Cc: "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 List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org 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/