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=-2.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no 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 6A033C433DF for ; Fri, 12 Jun 2020 10:59:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 450FC206DC for ; Fri, 12 Jun 2020 10:59:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="D8rARzxf" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726255AbgFLK7v (ORCPT ); Fri, 12 Jun 2020 06:59:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51756 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725911AbgFLK7u (ORCPT ); Fri, 12 Jun 2020 06:59:50 -0400 Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 537FBC03E96F for ; Fri, 12 Jun 2020 03:59:50 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id c35so6121136edf.5 for ; Fri, 12 Jun 2020 03:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=a/gLxj+FMOlkF15XIMwCGdzV2VsDVRy8WwjZriFqKLg=; b=D8rARzxfDqziwGDorckM0xWgft2C/Z756yTb433QSfI95xuWGqhQv8sAb57ZTUWPtX TWNYIUOHC9edCeSY9zqf/8Y6AG0Lf8ZBqN1FGHw/+tM8TXb8uyJpEoxdC+0VKHqssw6f sq6ElsVTzK4dUoJmqcr0ZRcqtV2TFiN5VbShHJ2gk4j2A4FV7V59aBD1QHDoFm1HN3Kq akTpISjJPnOdxyQOcemujdMcOif84+CNf5kn6jr1tt1C9dlCVncqS4DY57DEeU3iSHTL JoZa8tgivSjuq+E42y2+Lx0nr3zOx8o1Dusxe5D/mHWoO39JJpc/ish6C5MeUtJQF7I5 8iFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=a/gLxj+FMOlkF15XIMwCGdzV2VsDVRy8WwjZriFqKLg=; b=nvhxuuyVs/6S/TIIcFCiBCdekLMvjVcJUgH7yJX1z9NtxSGdp8pj27OsuT/T1hyU9j gEoFMqpedGP4VxG/Dmejw5++v+rBtGAeGOwUupQrRQPG5rwOla2Z6n9XA6i+ExLcqWne w2f2NTVj8TgrlCz9roHXV1h56pkwf5jzohXxDkejwC1fDKPzlxyQ7Byq3eouXOn5+z17 COaphimGSbpRko8VwXOnOP2MzKWCvxZHRaakcQLUphrvwkGCZblupeIXfwzf+cVFdTfY SrxvP8+ajhjTds7GyQpM6+h1CyaoG8bvaVm2kkmjJ0en9+cL7pRqEJuMlI5+GeKJ1sNT sR6g== X-Gm-Message-State: AOAM532xbziY4sopuHCqbS3+HDDW7ObbzgbXv2ZoTnsJbzvSKO8+p95x 0RsW2uOldrBdov2Xx3gfVg4ojiJL X-Google-Smtp-Source: ABdhPJzWAwbfOeNddgQuI+2BMeyXWGpwQxmfdxcECstdTBY8heLkZCtvxVqSQLW0l/BhK2Ywf0GYjQ== X-Received: by 2002:a50:ee18:: with SMTP id g24mr11268665eds.370.1591959587577; Fri, 12 Jun 2020 03:59:47 -0700 (PDT) Received: from [192.168.1.164] (i577BC9B3.versanet.de. [87.123.201.179]) by smtp.gmail.com with ESMTPSA id 63sm2991081edm.48.2020.06.12.03.59.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Jun 2020 03:59:47 -0700 (PDT) Subject: Re: Are we on the wrong track? To: Russell Coker , selinux-refpolicy@vger.kernel.org References: <3243717.6S2XvbbdUs@liv> From: Denis Obrezkov Message-ID: Date: Fri, 12 Jun 2020 13:00:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <3243717.6S2XvbbdUs@liv> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: selinux-refpolicy-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org Hi, Russell, I am a novice in SELinux, even though I am learning it for a year or so. And I can't really understand why SELinux is SO complex. Not only the policy, but the whole SELinux. For example, there are two different ways of writing a policy - CIL and the other one. And they have conflicting namesets (typeattribute = atttribute). At the same time, this behavior is just slightly documented. One can't create a policy only using information from docs. At the same time, some parts of SELinux are very unstable. Like, MCS. It was introduced and it is used only for VM management. And mcstransd is bad. It's really bad. I was trying to use it and it was totally unstable. So, even if someone wants to use MCS - it is almost impossible because tools are unstable and MCS is already almost exclusively used by VMs. On 12.06.20 02:03, Russell Coker wrote: > The reference policy is getting an increasing number of domains and types with > an O(N^2) level of complexity for writing policy and an O(N^2) size of the > binary policy. In 2012 the binary policy on my machines was 560k, now it's > over 2M. > > In recent policy we have 6 different domains for systemd-generators. What > benefit are we expecting to get from this? Are we anticipating that one > generator will attack another? How would having separate domains for > generators do any good when there's no restriction on the contents of the > files they generate and nothing to prevent one generator from creating a file > of the name that another generator is expected to create? Is it even > reasonable to expect that a program that can create a systemd unit file with > arbitrary content (IE being able to start any daemon with arbitrary > configuration and command-line parameters) would be unable to exploit that for > unrestricted root access? > > We have a new set of domains, user_wm_t, staff_wm_t, etc. What is that for? > Is someone using the X controls and in need of a privileged window manager > domain to manage the clipboard etc? Why is staff_wm_t needed when we no > longer have staff_gpg_t? Does staff_r even make sense when you could just use > different MCS categories for different users? > > We have one games_t domain for games which were packaged by the distribution. > Is this possible to give a useful benefit given that they some games the same > XDG config directories as more important things. If a game has the file > access needed to grab passwords from your MUA and network access to send them > out then is there a real benefit in having a separate domain for it? As an > aside I think that the ideal thing to do would be to have a SETGID program to > manage passwords for email etc that prevents the user from accessing them, it > could then proxy IMAP/SMTP connections so the MUA never knows the real > passwords. > > We have special *_cronjob_t domains which in systems that use them (IE not > Debian) seem to give the potential for nothing but confusion. The general > expectation is that anything which can run as a user login session can also > run as a cron job. What benefit is this expected to provide? > -- Regards, Denis Obrezkov