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=-7.5 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_PASS,USER_AGENT_MUTT 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 F387EC43218 for ; Fri, 26 Apr 2019 09:02:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A14072077B for ; Fri, 26 Apr 2019 09:02:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=perfinion-com.20150623.gappssmtp.com header.i=@perfinion-com.20150623.gappssmtp.com header.b="BvZ6WqL9" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725935AbfDZJCn (ORCPT ); Fri, 26 Apr 2019 05:02:43 -0400 Received: from mail-pf1-f174.google.com ([209.85.210.174]:38586 "EHLO mail-pf1-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725923AbfDZJCn (ORCPT ); Fri, 26 Apr 2019 05:02:43 -0400 Received: by mail-pf1-f174.google.com with SMTP id 10so1394530pfo.5 for ; Fri, 26 Apr 2019 02:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=perfinion-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=jZvthPUW0/3V3IO61d6eKgVpJnJ+XHlCcSXDXwLsbxQ=; b=BvZ6WqL9EUCMLWvloXF+D4EkyhZ7PEiT6Hqvf65+I7NpQrTj+QfVhkp1N40+l/++wB PPqgpJ4WaWDKIohFIC83GepCF650PAUpUcBKWqQBSyfvYCfS4Pq9cM8YawvC+Qskcutn 7vaz4GelaeZhkFRJOgFvynOSob31cQwlBMvHZs1Vq+N4i4mCOoy3Oz7TAdMEWXLoHtp3 kTaahbq3OGSRdfWTeJ9AR5X8FsKpPu8CuYgaGALoayxL47gBsdJxm9hWc9XmmpyZKMm2 Q/DaALmzCuZrgiHGL50isR/7ZxJ/c8lQLE6SB50M8G4tQTe6oalFXy0FJ26sDQC3YCEz v/eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=jZvthPUW0/3V3IO61d6eKgVpJnJ+XHlCcSXDXwLsbxQ=; b=huqJj1yEiWMZ+FjJEgDa8nhelbmiC/AYQcQfCG2uVQdr5OQUO1BII9Sl3r4npJpOxb +jp8gsIBHdT9Z0MpP91McjaGCBaleTLEttLUKL/kShoxwSDsFBbtexmz9keVK3GXdaPJ CjMbrjy4E65+CnDwlWT885WFSssnp0IoaYLMbAE1SvgpB+GdVKIRG9LxF9JuXaHWjw+p FZ+bNm2AcZ0+Ko7i5tsjozGAKTMJjcHKLoZl4AD+iwftbMSLGaoo29ioPp3IKG3EjJWY 7aqSy05m20+dDT/ijZkkQxULxDSEsiNxBhcCJ5CqAU6k/MdaFxzrq9pGXu36R6v2U/rZ bG7w== X-Gm-Message-State: APjAAAXBzPrNg0dyb08ZLiV1F4uZoJF0ax/a7ySV7Gq5ns4Ue6mtQ1sB 6xzBtidxhPOty/7+eqonS3+TRKgaeM4= X-Google-Smtp-Source: APXvYqy1ThbZ7ymNM3SwPB4+abCSrNgghDYA/NUpsUomUU6hAOop4W78TN8ZaJH8nqeNlcSxIdk4sg== X-Received: by 2002:aa7:9089:: with SMTP id i9mr45576201pfa.115.1556269361872; Fri, 26 Apr 2019 02:02:41 -0700 (PDT) Received: from localhost ([2404:e801:2003:875:c789:3654:bf11:9d87]) by smtp.gmail.com with ESMTPSA id w3sm44673923pfn.179.2019.04.26.02.02.40 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 26 Apr 2019 02:02:40 -0700 (PDT) Date: Fri, 26 Apr 2019 17:02:38 +0800 From: Jason Zaman To: Lukas Vrabec Cc: selinux-refpolicy@vger.kernel.org Subject: Re: New boolean for using bluetooth Message-ID: <20190426090238.GA33764@baraddur.perfinion.com> References: <87799eb7-b987-3e0a-f3e7-dcd6ddc2bc2d@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87799eb7-b987-3e0a-f3e7-dcd6ddc2bc2d@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: selinux-refpolicy-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org On Thu, Apr 25, 2019 at 06:58:27PM +0200, Lukas Vrabec wrote: > Hi All, > > I added new SELinux boolean[1][2] to Fedora SELinux policy called > deny_bluetooth. > > I would like to push it also to refpolicy, however, refpolicy is not > using bluetooth_socket at all, it's defined in policy but not used by > any SELinux domain. Can I create patch also with adding these rules from > Fedora policy? And also, for some reason my colleagues didn't follow > name conventions of global booleans with refpolicy (I didn't find any > deny_* boolean in refpolicy). So if it make sense to add these kind of > boolean also to refpolicy, should I defined it as allow_bluetooth ? I'd love for these to be upstreamed! but yes it should be named "allow_bluetooth" and should be default disabled. Refpolicy doenst have any deny_* booleans, and always defaults to disable. (When we pull down into gentoo some booleans are default enabled but upstream always goes the secure route.) -- Jason > [1]https://github.com/fedora-selinux/selinux-policy/commit/54c05f2645a660c545ec406558b42687df2552a7 > [2] > https://github.com/fedora-selinux/selinux-policy-contrib/commit/5a0561d7b67ae8403d4e1a44acfc8db40ee269a5 > > Thanks, > Lukas. > > -- > Lukas Vrabec > Senior Software Engineer, Security Technologies > Red Hat, Inc. >