Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v24 00/25] LSM: Module stacking for AppArmor
To:     Topi Miettinen <toiwoton@gmail.com>, casey.schaufler@intel.com,
        jmorris@namei.org, linux-security-module@vger.kernel.org,
        selinux@vger.kernel.org
Cc:     linux-audit@redhat.com, keescook@chromium.org,
        john.johansen@canonical.com, penguin-kernel@i-love.sakura.ne.jp,
        paul@paul-moore.com, sds@tycho.nsa.gov,
        linux-kernel@vger.kernel.org,
        Casey Schaufler <casey@schaufler-ca.com>
References: <20210126164108.1958-1-casey.ref@schaufler-ca.com>
 <20210126164108.1958-1-casey@schaufler-ca.com>
 <31ba0fe7-afdf-8f7d-e7a7-8f15d8c690a4@gmail.com>
 <c810406d-2197-9529-a8cb-2f289e9c248c@schaufler-ca.com>
 <c5c40a66-b36d-73ab-6c92-f4d1f5f4ad35@gmail.com>
From:   Casey Schaufler <casey@schaufler-ca.com>
Message-ID: <3ac446c9-1af7-04dd-561d-6ec1dbb146b9@schaufler-ca.com>
Date:   Tue, 2 Feb 2021 10:06:29 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <c5c40a66-b36d-73ab-6c92-f4d1f5f4ad35@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Content-Length: 7178
Precedence: bulk

On 2/2/2021 9:12 AM, Topi Miettinen wrote:
> On 2.2.2021 17.30, Casey Schaufler wrote:
>> On 2/2/2021 4:05 AM, Topi Miettinen wrote:
>>> On 26.1.2021 18.40, Casey Schaufler wrote:
>>>> This patchset provides the changes required for
>>>> the AppArmor security module to stack safely with any other.
>>>
>>> In my test, when kernel command line has apparmor before selinux in l=
sm=3D entry, the boot is not successful with enforcing=3D1:
>>> systemd[1]: Failed to compute init label, ignoring.
>>> systemd[1]: Failed to set SELinux security context system_u:object_r:=
cgroup_t:s0 for /sys/fs/cgroup: Invalid argument
>>> systemd[1]: Failed to set SELinux security context system_u:object_r:=
pstore_t:s0 for /sys/fs/pstore: Invalid argument
>>> systemd[1]: Failed to set SELinux security context system_u:object_r:=
sysfs_t:s0 for /sys/firmware/efi/efivars: Invalid argument
>>> ...
>>> Failed to drop capability bounding set of usermode helpers: Operation=
 not permitted
>>> Failed to drop capability bounding set of usermode helpers.
>>> systemd[1]: Freezing execution.
>>
>> Systemd has extensive support for SELinux. That's good.
>> It doesn't have an understanding of what needs to be done
>> if SELinux is active but not the default security module
>> for interfaces including SO_PEERSEC and /proc/*/attr/*.
>> That's going to take some work.
>
> Ok. What will be the replacement for SO_PEERSEC? Systemd calls getsocko=
pt(fd, SOL_SOCKET, SO_PEERSEC, s, &n).

Dealing with SO_PEERSEC has been discussed at length, and I
wouldn't say that anyone is really happy with the conclusions.
The patch set presented uses the interface_lsm to determine
which module's data is presented in SO_PEERSEC. The interface_lsm
is controlled by writing the desired security module name to
/proc/self/attr/interface_lsm. The addition of SO_PEERCONTEXT,
which would contain all active security module data, has been
proposed as a follow-on but is not included in this patch set.

>
> Is the /proc part something that should be fixed on systemd side, or ca=
n perhaps the SELinux libraries hide this from applications?

It's unfortunate that the early days of the LSM where dominated
by the mindset that security had to be a complete solution. I
was in that camp myself for a good long time, but came to
recognize that attempting to solve all security problems for
everyone using one mechanism was destined to excess. Because
user-space development has assumed a single LSM for so long it's
hard to imagine that there won't need to be changes in both the
libraries and the programs. Because SELinux has the longest
history and most complete distribution integration it will also
have the most trouble with sharing the LSM stack.=20

>
>>
>>>
>>> Probably SELinux libraries can't find or set the labels for the PID1 =
or any file systems. Before the init label message, systemd calls getcon_=
raw(), getfilecon_raw(), string_to_security_class() and security_compute_=
create_raw(), so one of these don't understand the LSM stacking.
>>
>> That is correct.
>>
>>>
>>> Also the policy needs updating to handle process2:setdisplay:
>>> SELinux:=C2=A0 Permission setdisplay in class process2 not defined in=
 policy.
>>> SELinux: the above unknown classes and permissions will be denied
>>>
>>> With enforcing=3D0, many services start, but for example systemd-jour=
nald doesn't. This is probably related to the earlier problem with labels=
 (maybe libraries try to use SELinux labels where kernel wants AppArmor p=
rofiles):
>>> systemd[1]: Failed to set SELinux security context system_u:object_r:=
init_runtime_t:s0 for /run/systemd/units/invocation:systemd-user-sessions=
=2Eservice: Invalid argument
>>
>> This is also an artifact of systemd seeing AppArmor information
>> instead of SELinux contexts.
>
> Will SELinux libraries choose automatically the correct way to set labe=
ls in the future?

I expect so eventually. The SELinux developers have not been
especially enthusiastic about the prospect of module stacking.
Once it is available I expect to see some accommodation, but
not necessarily to the level you might like. The patch set here
is strongly influenced by the assumption that putting the most
highly integrated module first (SELinux on Fedora, AppArmor on
Ubuntu, Smack on Tizen, ...) is going to get you most of what
you need. Whoever wants to add Smack to Ubuntu is going to have
some work to do.

Stacking AppArmor with SELinux is a real use case in the container
world, but that's not the real focus of this effort. I have seen
several cases where security features have not been implemented
because they couldn't be added to a system that also required
SELinux, AppArmor or Smack. I have seen many proposals for changes
to existing security modules that where outside their scope just
because there was no other way.

>
>>>
>>> Switching the order so that apparmor is after selinux, boot is succes=
sful. Loading AppArmor profiles needs a permission from SELinux:
>>>
>>> Feb 02 08:53:15 audit[963]: AVC avc:=C2=A0 denied=C2=A0 { mac_admin }=
 for=C2=A0 pid=3D963 comm=3D"apparmor_parser" capability=3D33 scontext=3D=
system_u:system_r:initrc_t:s0 tcontext=3Dsystem_u:system_r:initrc_t:s0 tc=
lass=3Dcapability2 permissive=3D0
>>> Feb 02 08:53:15 audit[963]: AVC apparmor=3D"STATUS" operation=3D"prof=
ile_replace" info=3D"not policy admin" error=3D-13 profile=3D"unconfined"=
 pid=3D963 comm=3D"apparmor_parser"
>>> Feb 02 08:53:15 audit: AUDIT1420 subj_selinux=3Dsystem_u:system_r:ini=
trc_t:s0 subj_apparmor=3D=3Dunconfined
>>> Feb 02 08:53:15 audit[963]: SYSCALL arch=3Dc000003e syscall=3D1 succe=
ss=3Dno exit=3D-13 a0=3D7 a1=3D7a8f2ff04f80 a2=3D1e09 a3=3D0 items=3D0 pp=
id=3D961 pid=3D963 auid=3D4294967295 uid=3D0 gid=3D0 euid=3D0 suid=3D0 fs=
uid=3D0 egid=3D0 sgid=3D0 fsgid=3D0 tty=3D(none) ses=3D4294967295 comm=3D=
"apparmor_parser" exe=3D"/usr/sbin/apparmor_parser" subj=3D? key=3D(null)=

>>> Feb 02 08:53:15 audit: PROCTITLE proctitle=3D2F7362696E2F61707061726D=
6F725F706172736572002D2D77726974652D6361636865002D2D7265706C616365002D2D0=
02F6574632F61707061726D6F722E64
>>> Feb 02 08:53:15 apparmor.systemd[963]: /sbin/apparmor_parser: Unable =
to replace "/lib/systemd/systemd-resolved".=C2=A0 Permission denied; atte=
mpted to load a profile while confined?
>>>
>>> This just seems to need TE rules for the apparmor_parser.
>>>
>>> Double equal sign in subj_apparmor=3D=3Dunconfined looks odd, should =
that be just one like subj_selinux?
>>
>> The audit code is reporting what AppArmor provides.
>> I agree that this looks odd.
>>
>>>
>>>
>>> Tools like ps, and KDE and Gnome System Monitors only show SELinux co=
ntext, but it would be nice if MAC contexts for all enabled LSMs were sho=
wn.
>>
>> I agree. How this should be done has been a topic of
>> lively debate for some time.
>>
>>>
>>> -Topi
>>
>> Thank you for this report. Which distribution are you using?
>> I have been testing with Fedora (SELinux + AppArmor) and Ubuntu
>> (AppArmor + Smack). I would be very interested to see how a
>> distribution that doesn't use systemd behaves.
>
> This is Debian with systemd, I'm using SELinux + TOMOYO + AppArmor.

Great to hear. Thanks again.