linux-kernel - Re: [PATCH] security: selinux: allow per-file labeling for cgroupfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 10 Mar 2017 15:21:07 -0500
From:   Paul Moore <paul@...l-moore.com>
To:     Stephen Smalley <sds@...ho.nsa.gov>,
        Antonio Murdaca <amurdaca@...hat.com>
Cc:     cgroups@...r.kernel.org, linux-kernel@...r.kernel.org,
        selinux@...ho.nsa.gov, vgoyal@...hat.com
Subject: Re: [PATCH] security: selinux: allow per-file labeling for cgroupfs

On Fri, Mar 10, 2017 at 3:17 PM, Stephen Smalley <sds@...ho.nsa.gov> wrote:
> On Fri, 2017-03-10 at 15:01 -0500, Paul Moore wrote:
>> On Thu, Feb 9, 2017 at 10:58 AM, Antonio Murdaca <amurdaca@...hat.com
>> > wrote:
>> >
>> > This patch allows genfscon per-file labeling for cgroupfs. For
>> > instance,
>> > this allows to label the "release_agent" file within each
>> > cgroup mount and limit writes to it.
>> >
>> > Signed-off-by: Antonio Murdaca <runcom@...hat.com>
>> > ---
>> >  security/selinux/hooks.c | 2 ++
>> >  1 file changed, 2 insertions(+)
>>
>> Now that the merge window is behind us, let's get this merged, but
>> could you update it to use the selinux_policycap_cgroupseclabel
>> policy
>> capability?  See 2651225b5ebcdde ("selinux: wrap cgroup seclabel
>> support with its own policy capability") for more information.
>
> I don't think that is necessary.  This change unlike the other one
> should not yield any difference in behavior with existing policy; it
> just allows one to specify fine-grained labeling for cgroup nodes in
> future policy.  It doesn't affect any userspace interface.

Yes, I thought about that, and if the policy capability was already
present in a released kernel then I wouldn't worry about it much, but
since the policy capability still only lives in the v4.11-rcX kernels
I'd prefer to see this code wrapped with the policy capability ...
even if all it really does is give me that warm fuzzy feeling.

>> Also, how goes the testing?
>>
>> >
>> > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
>> > index 9a8f12f..5a3138e 100644
>> > --- a/security/selinux/hooks.c
>> > +++ b/security/selinux/hooks.c
>> > @@ -808,6 +808,8 @@ static int selinux_set_mnt_opts(struct
>> > super_block *sb,
>> >
>> >         if (!strcmp(sb->s_type->name, "debugfs") ||
>> >             !strcmp(sb->s_type->name, "sysfs") ||
>> > +           !strcmp(sb->s_type->name, "cgroup") ||
>> > +           !strcmp(sb->s_type->name, "cgroup2") ||
>> >             !strcmp(sb->s_type->name, "pstore"))
>> >                 sbsec->flags |= SE_SBGENFS;
>> >
>> > --
>> > 2.9.3
>> >
>> > _______________________________________________
>> > Selinux mailing list
>> > Selinux@...ho.nsa.gov
>> > To unsubscribe, send email to Selinux-leave@...ho.nsa.gov.
>> > To get help, send an email containing "help" to Selinux-request@tyc
>> > ho.nsa.gov.
>>



-- 
paul moore
www.paul-moore.com