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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED 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 20685C43381 for ; Mon, 4 Mar 2019 13:35:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D895020661 for ; Mon, 4 Mar 2019 13:34:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="vMAInIj5" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726616AbfCDNe7 (ORCPT ); Mon, 4 Mar 2019 08:34:59 -0500 Received: from mail-ed1-f68.google.com ([209.85.208.68]:45408 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726607AbfCDNe7 (ORCPT ); Mon, 4 Mar 2019 08:34:59 -0500 Received: by mail-ed1-f68.google.com with SMTP id f19so4239187eds.12 for ; Mon, 04 Mar 2019 05:34:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=3ka5O+CHKhsOMk/mvyco6o6GvEmKCafmiOD8ECMxuX8=; b=vMAInIj5GW+dGQOUWHkjI6iVdIYMQOtQdvCgXo3WO5UjqdTSkTA0uv9q0z9QJIjJBT JnS7fxncpp/FHlY0lshxw4ZGwNKbWuZyUTAvK8S7rkbMcYhIFsxGw91UC52YrrO9R8A1 ZG4h+SLxsFdFAGovvFO2DTfc+GXZMQwiaFWICtzpglccQikfgIQ5DdzNms07U31fc/9e lZz3GeFNZObW34RJ7TVJdQiHF4sQ6fw7ycq2YZnB2YgzYxC0NEKFetzpGTWHBU9HNL1e ENNv5esIw4sKDAbYyBkrNJo5QahUezQR1VcbGLTaLxi1Xxz+D+/DF0iSl2Jn70Z47f1U R7XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=3ka5O+CHKhsOMk/mvyco6o6GvEmKCafmiOD8ECMxuX8=; b=sVa7xi4EJDbiAxfDgLw4BqfFQcsF47zRD1iouVG2mgBqQem0U8J1IswCOUDM4kpYCj /ht98gBfcgf6XILmxbimavGQGWQS1o7WqNobrk/cJQleBsfkXAtg6iRx9H1I2dtJwd0x Ep0Bdqt40eCTsEiwwFEzKwuTddYlO5Md8IhGcBHr1tITR2u9Q4vqGrpICe2MBrvKok0s LHHiL7yF5sKu1tHfPf/gqayM6f6J453vUI8rNuUCTf6mJJcsHjDafoQf5JD7frPBomiv ELosADnAGdKE8ZIbmjEkFzqnNDtNnxDX7pESnYnLSuCgta2na1YSpYObF6Qm3u+x3v+/ Xl5w== X-Gm-Message-State: APjAAAWKdtBtlpD/oaEl48Jy7o1Xe2COUnWovr59OoVB1mhFnXmXISFT NqXO+kQM2nlJJBxx1GYg8nr2oZrb X-Google-Smtp-Source: APXvYqxE0QRGR77YWIKAeBBBb1z+PUDJZaS+DIuA71cmhWwtjr8mfqk31K6sp+RFSKhxxV+FE67/bA== X-Received: by 2002:a05:6402:12d4:: with SMTP id k20mr15854673edx.71.1551706497340; Mon, 04 Mar 2019 05:34:57 -0800 (PST) Received: from brutus (brutus.defensec.nl. [2001:985:d55d::438]) by smtp.gmail.com with ESMTPSA id j46sm2108495ede.6.2019.03.04.05.34.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 04 Mar 2019 05:34:56 -0800 (PST) From: Dominick Grift To: Russell Coker Cc: "selinux-refpolicy\@vger.kernel.org" Subject: Re: strange daemon startup issue References: <3166760.egoGarHQ6g@xev> Date: Mon, 04 Mar 2019 14:34:56 +0100 In-Reply-To: <3166760.egoGarHQ6g@xev> (Russell Coker's message of "Tue, 05 Mar 2019 00:29:45 +1100") Message-ID: <87a7iazrsv.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: selinux-refpolicy-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org Russell Coker writes: > When I boot kernel 4.9.144 (Debian/Stable kernel) with the Debian policy for > Unstable (which isn't very different to the latest Git refpolicy) /usr/sbin/ > ModemManager and /usr/sbin/mysqld run as init_t. > > When I boot the same policy with kernel 4.19.16 (Debian/Testing kernel) those > daemons run in modemmanager_t and mysqld_t as desired. > > What is the difference between those kernels which would explain this? Would > it be some interaction with systemd? I don't expect anyone to just hand me > the answer (although that would be really nice), any clues as to where I > should start investigating this would be great. > > The general aim with Debian SE Linux is that you can run the policy with the > kernel from the previous version of Debian. So this is something I really > want to fix. Could it be the nnp_nosuid_transition polcap? Not sure when that was exactly introduced but that change does affect domain transitions. -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift