* Re: [Regression?] 1ea0ce4069 ("selinux: allow changing labels for cgroupfs") stops Android from booting
2017-02-27 21:23 ` Stephen Smalley
@ 2017-02-27 21:31 ` Stephen Smalley
2017-02-28 0:18 ` Paul Moore
2017-03-09 17:28 ` Greg KH
2 siblings, 0 replies; 16+ messages in thread
From: Stephen Smalley @ 2017-02-27 21:31 UTC (permalink / raw)
To: Nick Kralevich
Cc: Paul Moore, John Stultz, Jeffrey Vander Stoep, Antonio Murdaca,
lkml, Android Kernel Team
On Mon, 2017-02-27 at 16:23 -0500, Stephen Smalley wrote:
> On Mon, 2017-02-27 at 12:48 -0800, Nick Kralevich wrote:
> >
> > On Mon, Feb 27, 2017 at 11:53 AM, Stephen Smalley <sds@tycho.nsa.go
> > v>
> > wrote:
> > >
> > >
> > > >
> > > >
> > > > I can reproduce it on angler (with a back-port of just that
> > > > patch),
> > > > although I am unclear on the cause. The patch is only supposed
> > > > to
> > > > enable explicit setting of security labels by userspace on
> > > > cgroup
> > > > files, so it isn't supposed to cause any breakage under
> > > > existing
> > > > policy. Prior to the patch, the kernel would always just
> > > > return
> > > > -1
> > > > with errno EOPNOTSUPP upon attempts to set security labels on
> > > > cgroup
> > > > files; with the patch, the kernel may instead return -1 with
> > > > errno
> > > > EACCES if not allowed. So I suppose if userspace was
> > > > explicitly
> > > > testing for EOPNOTSUPP and not failing hard in that case, it
> > > > might
> > > > cause breakage. Not sure why existing userspace would be
> > > > trying
> > > > to
> > > > relabel cgroup files, unless it is just a recursive restorecon
> > > > that
> > > > happens to traverse into a cgroup mount (and in that case, not
> > > > sure
> > > > why
> > > > it would be fatal). Other possible interaction would be use of
> > > > setfscreatecon() prior to creating a file in cgroup.
> > >
> > > Oh, I see - it is the latter.
> > >
> > > For example, init.rc does mkdir /dev/cpuctl/bg_non_interactive,
> > > which
> > > internally looks up the context for that directory from
> > > file_contexts
> > > and does a setfscreatecon() followed by a mkdir(). Previously,
> > > that
> > > was ignored because cgroup did not support anything other than
> > > the
> > > policy-defined label. But now it will try to use that label,
> > > which
> > > in
> > > turn will trigger a denial in enforcing mode and the create will
> > > fail.
> > >
> > > So this is an incompatible change and needs to be reverted.
> > > We'll need to wrap it up with a policy capability or something to
> > > allow
> > > it to be enabled only if the policy correctly supports it. Even
> > > better, we should instead just allow the policy to specify which
> > > filesystems should support this behavior (already on the issues
> > > list).
> > >
> >
> > If Android is the only system affected by this bug, I would prefer
> > to
> > just fix Android to allow for this patch, rather than having
> > additional kernel complexity.
>
> Well, it does break userspace (even if it happens to only affect
> Android, which isn't clear, e.g. possibly a distribution would
> likewise
> suffer breakage under a tighter policy), and we already have a long-
> standing open issue to replace the current set of whitelisted
> filesystem types with something configuration-driven. So I'm ok with
> reverting it and requiring it to be done in a more general way. The
> latter is something we want regardless.
Also, I'm not sure it can be fixed cleanly just by policy, or at least
not just via kernel policy. You wouldn't want to allow creation of
cgroup files in the contexts presently specified via file_contexts; you
would need to modify file_contexts to correctly specify the cgroup file
contexts. And that in turn raises another existing issue:
distinguishing the label for the mountpoint directory versus the
mounted directory.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Regression?] 1ea0ce4069 ("selinux: allow changing labels for cgroupfs") stops Android from booting
2017-02-27 21:23 ` Stephen Smalley
2017-02-27 21:31 ` Stephen Smalley
@ 2017-02-28 0:18 ` Paul Moore
2017-02-28 15:29 ` Stephen Smalley
2017-03-09 17:28 ` Greg KH
2 siblings, 1 reply; 16+ messages in thread
From: Paul Moore @ 2017-02-28 0:18 UTC (permalink / raw)
To: Stephen Smalley
Cc: Nick Kralevich, John Stultz, Jeffrey Vander Stoep,
Antonio Murdaca, lkml, Android Kernel Team
On Mon, Feb 27, 2017 at 4:23 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Mon, 2017-02-27 at 12:48 -0800, Nick Kralevich wrote:
>> On Mon, Feb 27, 2017 at 11:53 AM, Stephen Smalley <sds@tycho.nsa.gov>
>> wrote:
>> >
>> > >
>> > > I can reproduce it on angler (with a back-port of just that
>> > > patch),
>> > > although I am unclear on the cause. The patch is only supposed
>> > > to
>> > > enable explicit setting of security labels by userspace on cgroup
>> > > files, so it isn't supposed to cause any breakage under existing
>> > > policy. Prior to the patch, the kernel would always just return
>> > > -1
>> > > with errno EOPNOTSUPP upon attempts to set security labels on
>> > > cgroup
>> > > files; with the patch, the kernel may instead return -1 with
>> > > errno
>> > > EACCES if not allowed. So I suppose if userspace was explicitly
>> > > testing for EOPNOTSUPP and not failing hard in that case, it
>> > > might
>> > > cause breakage. Not sure why existing userspace would be trying
>> > > to
>> > > relabel cgroup files, unless it is just a recursive restorecon
>> > > that
>> > > happens to traverse into a cgroup mount (and in that case, not
>> > > sure
>> > > why
>> > > it would be fatal). Other possible interaction would be use of
>> > > setfscreatecon() prior to creating a file in cgroup.
>> >
>> > Oh, I see - it is the latter.
>> >
>> > For example, init.rc does mkdir /dev/cpuctl/bg_non_interactive,
>> > which
>> > internally looks up the context for that directory from
>> > file_contexts
>> > and does a setfscreatecon() followed by a mkdir(). Previously,
>> > that
>> > was ignored because cgroup did not support anything other than the
>> > policy-defined label. But now it will try to use that label, which
>> > in
>> > turn will trigger a denial in enforcing mode and the create will
>> > fail.
>> >
>> > So this is an incompatible change and needs to be reverted.
>> > We'll need to wrap it up with a policy capability or something to
>> > allow
>> > it to be enabled only if the policy correctly supports it. Even
>> > better, we should instead just allow the policy to specify which
>> > filesystems should support this behavior (already on the issues
>> > list).
>> >
>>
>> If Android is the only system affected by this bug, I would prefer to
>> just fix Android to allow for this patch, rather than having
>> additional kernel complexity.
>
> Well, it does break userspace (even if it happens to only affect
> Android, which isn't clear, e.g. possibly a distribution would likewise
> suffer breakage under a tighter policy), and we already have a long-
> standing open issue to replace the current set of whitelisted
> filesystem types with something configuration-driven. So I'm ok with
> reverting it and requiring it to be done in a more general way. The
> latter is something we want regardless.
This went up to Linus during the current merge window via the
stable-4.11 branch and I know the container guys really want this so
I'd prefer to fix this up in 4.11 with a policy capability if possible
(and I believe it should be). I agree with Stephen that we need a
better long term solution, but I think a policy capability should work
in the short term.
Who wants to send me a patch? ;)
--
paul moore
www.paul-moore.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Regression?] 1ea0ce4069 ("selinux: allow changing labels for cgroupfs") stops Android from booting
2017-02-28 0:18 ` Paul Moore
@ 2017-02-28 15:29 ` Stephen Smalley
2017-02-28 17:23 ` Paul Moore
0 siblings, 1 reply; 16+ messages in thread
From: Stephen Smalley @ 2017-02-28 15:29 UTC (permalink / raw)
To: Paul Moore
Cc: Nick Kralevich, John Stultz, Jeffrey Vander Stoep,
Antonio Murdaca, lkml, Android Kernel Team
On Mon, 2017-02-27 at 19:18 -0500, Paul Moore wrote:
> On Mon, Feb 27, 2017 at 4:23 PM, Stephen Smalley <sds@tycho.nsa.gov>
> wrote:
> >
> > On Mon, 2017-02-27 at 12:48 -0800, Nick Kralevich wrote:
> > >
> > > On Mon, Feb 27, 2017 at 11:53 AM, Stephen Smalley <sds@tycho.nsa.
> > > gov>
> > > wrote:
> > > >
> > > >
> > > > >
> > > > >
> > > > > I can reproduce it on angler (with a back-port of just that
> > > > > patch),
> > > > > although I am unclear on the cause. The patch is only
> > > > > supposed
> > > > > to
> > > > > enable explicit setting of security labels by userspace on
> > > > > cgroup
> > > > > files, so it isn't supposed to cause any breakage under
> > > > > existing
> > > > > policy. Prior to the patch, the kernel would always just
> > > > > return
> > > > > -1
> > > > > with errno EOPNOTSUPP upon attempts to set security labels on
> > > > > cgroup
> > > > > files; with the patch, the kernel may instead return -1 with
> > > > > errno
> > > > > EACCES if not allowed. So I suppose if userspace was
> > > > > explicitly
> > > > > testing for EOPNOTSUPP and not failing hard in that case, it
> > > > > might
> > > > > cause breakage. Not sure why existing userspace would be
> > > > > trying
> > > > > to
> > > > > relabel cgroup files, unless it is just a recursive
> > > > > restorecon
> > > > > that
> > > > > happens to traverse into a cgroup mount (and in that case,
> > > > > not
> > > > > sure
> > > > > why
> > > > > it would be fatal). Other possible interaction would be use
> > > > > of
> > > > > setfscreatecon() prior to creating a file in cgroup.
> > > >
> > > > Oh, I see - it is the latter.
> > > >
> > > > For example, init.rc does mkdir /dev/cpuctl/bg_non_interactive,
> > > > which
> > > > internally looks up the context for that directory from
> > > > file_contexts
> > > > and does a setfscreatecon() followed by a mkdir(). Previously,
> > > > that
> > > > was ignored because cgroup did not support anything other than
> > > > the
> > > > policy-defined label. But now it will try to use that label,
> > > > which
> > > > in
> > > > turn will trigger a denial in enforcing mode and the create
> > > > will
> > > > fail.
> > > >
> > > > So this is an incompatible change and needs to be reverted.
> > > > We'll need to wrap it up with a policy capability or something
> > > > to
> > > > allow
> > > > it to be enabled only if the policy correctly supports
> > > > it. Even
> > > > better, we should instead just allow the policy to specify
> > > > which
> > > > filesystems should support this behavior (already on the issues
> > > > list).
> > > >
> > >
> > > If Android is the only system affected by this bug, I would
> > > prefer to
> > > just fix Android to allow for this patch, rather than having
> > > additional kernel complexity.
> >
> > Well, it does break userspace (even if it happens to only affect
> > Android, which isn't clear, e.g. possibly a distribution would
> > likewise
> > suffer breakage under a tighter policy), and we already have a
> > long-
> > standing open issue to replace the current set of whitelisted
> > filesystem types with something configuration-driven. So I'm ok
> > with
> > reverting it and requiring it to be done in a more general
> > way. The
> > latter is something we want regardless.
>
> This went up to Linus during the current merge window via the
> stable-4.11 branch and I know the container guys really want this so
> I'd prefer to fix this up in 4.11 with a policy capability if
> possible
> (and I believe it should be). I agree with Stephen that we need a
> better long term solution, but I think a policy capability should
> work
> in the short term.
>
> Who wants to send me a patch? ;)
So, there are a couple of caveats with doing that:
1) It still requires the container folks to update their kernel,
libsepol, and policy in order to make use of the new policy capability.
2) The determination of whether a given mount should be assigned this
flag is made at mount time, so you can't simply reload policy with a
policy that defines this capability and have it automatically applied
to existing cgroup mounts. You'd have to unmount and re-mount them
(more likely reboot).
Not saying you can't do that, just understand what is required.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Regression?] 1ea0ce4069 ("selinux: allow changing labels for cgroupfs") stops Android from booting
2017-02-28 15:29 ` Stephen Smalley
@ 2017-02-28 17:23 ` Paul Moore
0 siblings, 0 replies; 16+ messages in thread
From: Paul Moore @ 2017-02-28 17:23 UTC (permalink / raw)
To: Stephen Smalley
Cc: Nick Kralevich, John Stultz, Jeffrey Vander Stoep,
Antonio Murdaca, lkml, Android Kernel Team
On Tue, Feb 28, 2017 at 10:29 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Mon, 2017-02-27 at 19:18 -0500, Paul Moore wrote:
>> On Mon, Feb 27, 2017 at 4:23 PM, Stephen Smalley <sds@tycho.nsa.gov>
>> wrote:
>> >
>> > On Mon, 2017-02-27 at 12:48 -0800, Nick Kralevich wrote:
>> > >
>> > > On Mon, Feb 27, 2017 at 11:53 AM, Stephen Smalley <sds@tycho.nsa.
>> > > gov>
>> > > wrote:
>> > > >
>> > > >
>> > > > >
>> > > > >
>> > > > > I can reproduce it on angler (with a back-port of just that
>> > > > > patch),
>> > > > > although I am unclear on the cause. The patch is only
>> > > > > supposed
>> > > > > to
>> > > > > enable explicit setting of security labels by userspace on
>> > > > > cgroup
>> > > > > files, so it isn't supposed to cause any breakage under
>> > > > > existing
>> > > > > policy. Prior to the patch, the kernel would always just
>> > > > > return
>> > > > > -1
>> > > > > with errno EOPNOTSUPP upon attempts to set security labels on
>> > > > > cgroup
>> > > > > files; with the patch, the kernel may instead return -1 with
>> > > > > errno
>> > > > > EACCES if not allowed. So I suppose if userspace was
>> > > > > explicitly
>> > > > > testing for EOPNOTSUPP and not failing hard in that case, it
>> > > > > might
>> > > > > cause breakage. Not sure why existing userspace would be
>> > > > > trying
>> > > > > to
>> > > > > relabel cgroup files, unless it is just a recursive
>> > > > > restorecon
>> > > > > that
>> > > > > happens to traverse into a cgroup mount (and in that case,
>> > > > > not
>> > > > > sure
>> > > > > why
>> > > > > it would be fatal). Other possible interaction would be use
>> > > > > of
>> > > > > setfscreatecon() prior to creating a file in cgroup.
>> > > >
>> > > > Oh, I see - it is the latter.
>> > > >
>> > > > For example, init.rc does mkdir /dev/cpuctl/bg_non_interactive,
>> > > > which
>> > > > internally looks up the context for that directory from
>> > > > file_contexts
>> > > > and does a setfscreatecon() followed by a mkdir(). Previously,
>> > > > that
>> > > > was ignored because cgroup did not support anything other than
>> > > > the
>> > > > policy-defined label. But now it will try to use that label,
>> > > > which
>> > > > in
>> > > > turn will trigger a denial in enforcing mode and the create
>> > > > will
>> > > > fail.
>> > > >
>> > > > So this is an incompatible change and needs to be reverted.
>> > > > We'll need to wrap it up with a policy capability or something
>> > > > to
>> > > > allow
>> > > > it to be enabled only if the policy correctly supports
>> > > > it. Even
>> > > > better, we should instead just allow the policy to specify
>> > > > which
>> > > > filesystems should support this behavior (already on the issues
>> > > > list).
>> > > >
>> > >
>> > > If Android is the only system affected by this bug, I would
>> > > prefer to
>> > > just fix Android to allow for this patch, rather than having
>> > > additional kernel complexity.
>> >
>> > Well, it does break userspace (even if it happens to only affect
>> > Android, which isn't clear, e.g. possibly a distribution would
>> > likewise
>> > suffer breakage under a tighter policy), and we already have a
>> > long-
>> > standing open issue to replace the current set of whitelisted
>> > filesystem types with something configuration-driven. So I'm ok
>> > with
>> > reverting it and requiring it to be done in a more general
>> > way. The
>> > latter is something we want regardless.
>>
>> This went up to Linus during the current merge window via the
>> stable-4.11 branch and I know the container guys really want this so
>> I'd prefer to fix this up in 4.11 with a policy capability if
>> possible
>> (and I believe it should be). I agree with Stephen that we need a
>> better long term solution, but I think a policy capability should
>> work
>> in the short term.
>>
>> Who wants to send me a patch? ;)
>
> So, there are a couple of caveats with doing that:
>
> 1) It still requires the container folks to update their kernel,
> libsepol, and policy in order to make use of the new policy capability.
A kernel upgrade is going to be necessary regardless at this original
change just landed in Linus' tree this merge window. As far the
userspace and policy updates, I think that is a reasonable
expectation. I just want to protect from the new-kernel/old-userspace
case that appears to affect Android systems at a minimum.
> 2) The determination of whether a given mount should be assigned this
> flag is made at mount time, so you can't simply reload policy with a
> policy that defines this capability and have it automatically applied
> to existing cgroup mounts. You'd have to unmount and re-mount them
> (more likely reboot).
Yes, but once again, I don't think that is an unreasonable requirement
for new functionality.
> Not saying you can't do that, just understand what is required.
--
paul moore
www.paul-moore.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Regression?] 1ea0ce4069 ("selinux: allow changing labels for cgroupfs") stops Android from booting
2017-02-27 21:23 ` Stephen Smalley
2017-02-27 21:31 ` Stephen Smalley
2017-02-28 0:18 ` Paul Moore
@ 2017-03-09 17:28 ` Greg KH
2017-03-09 17:57 ` Stephen Smalley
2 siblings, 1 reply; 16+ messages in thread
From: Greg KH @ 2017-03-09 17:28 UTC (permalink / raw)
To: Stephen Smalley
Cc: Nick Kralevich, Paul Moore, John Stultz, Jeffrey Vander Stoep,
Antonio Murdaca, lkml, Android Kernel Team
On Mon, Feb 27, 2017 at 04:23:28PM -0500, Stephen Smalley wrote:
> On Mon, 2017-02-27 at 12:48 -0800, Nick Kralevich wrote:
> > On Mon, Feb 27, 2017 at 11:53 AM, Stephen Smalley <sds@tycho.nsa.gov>
> > wrote:
> > >
> > > >
> > > > I can reproduce it on angler (with a back-port of just that
> > > > patch),
> > > > although I am unclear on the cause. The patch is only supposed
> > > > to
> > > > enable explicit setting of security labels by userspace on cgroup
> > > > files, so it isn't supposed to cause any breakage under existing
> > > > policy. Prior to the patch, the kernel would always just return
> > > > -1
> > > > with errno EOPNOTSUPP upon attempts to set security labels on
> > > > cgroup
> > > > files; with the patch, the kernel may instead return -1 with
> > > > errno
> > > > EACCES if not allowed. So I suppose if userspace was explicitly
> > > > testing for EOPNOTSUPP and not failing hard in that case, it
> > > > might
> > > > cause breakage. Not sure why existing userspace would be trying
> > > > to
> > > > relabel cgroup files, unless it is just a recursive restorecon
> > > > that
> > > > happens to traverse into a cgroup mount (and in that case, not
> > > > sure
> > > > why
> > > > it would be fatal). Other possible interaction would be use of
> > > > setfscreatecon() prior to creating a file in cgroup.
> > >
> > > Oh, I see - it is the latter.
> > >
> > > For example, init.rc does mkdir /dev/cpuctl/bg_non_interactive,
> > > which
> > > internally looks up the context for that directory from
> > > file_contexts
> > > and does a setfscreatecon() followed by a mkdir(). Previously,
> > > that
> > > was ignored because cgroup did not support anything other than the
> > > policy-defined label. But now it will try to use that label, which
> > > in
> > > turn will trigger a denial in enforcing mode and the create will
> > > fail.
> > >
> > > So this is an incompatible change and needs to be reverted.
> > > We'll need to wrap it up with a policy capability or something to
> > > allow
> > > it to be enabled only if the policy correctly supports it. Even
> > > better, we should instead just allow the policy to specify which
> > > filesystems should support this behavior (already on the issues
> > > list).
> > >
> >
> > If Android is the only system affected by this bug, I would prefer to
> > just fix Android to allow for this patch, rather than having
> > additional kernel complexity.
>
> Well, it does break userspace (even if it happens to only affect
> Android, which isn't clear, e.g. possibly a distribution would likewise
> suffer breakage under a tighter policy), and we already have a long-
> standing open issue to replace the current set of whitelisted
> filesystem types with something configuration-driven. So I'm ok with
> reverting it and requiring it to be done in a more general way. The
> latter is something we want regardless.
>
Please revert this, it's not ok to break working userspace code. I've
gotten a few off-line queries as to why this ended up being merged when
it was known to break Android.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Regression?] 1ea0ce4069 ("selinux: allow changing labels for cgroupfs") stops Android from booting
2017-03-09 17:28 ` Greg KH
@ 2017-03-09 17:57 ` Stephen Smalley
2017-03-09 18:36 ` Greg KH
0 siblings, 1 reply; 16+ messages in thread
From: Stephen Smalley @ 2017-03-09 17:57 UTC (permalink / raw)
To: Greg KH
Cc: Nick Kralevich, Paul Moore, John Stultz, Jeffrey Vander Stoep,
Antonio Murdaca, lkml, Android Kernel Team
On Thu, 2017-03-09 at 18:28 +0100, Greg KH wrote:
> On Mon, Feb 27, 2017 at 04:23:28PM -0500, Stephen Smalley wrote:
> >
> > On Mon, 2017-02-27 at 12:48 -0800, Nick Kralevich wrote:
> > >
> > > On Mon, Feb 27, 2017 at 11:53 AM, Stephen Smalley <sds@tycho.nsa.
> > > gov>
> > > wrote:
> > > >
> > > >
> > > > >
> > > > >
> > > > > I can reproduce it on angler (with a back-port of just that
> > > > > patch),
> > > > > although I am unclear on the cause. The patch is only
> > > > > supposed
> > > > > to
> > > > > enable explicit setting of security labels by userspace on
> > > > > cgroup
> > > > > files, so it isn't supposed to cause any breakage under
> > > > > existing
> > > > > policy. Prior to the patch, the kernel would always just
> > > > > return
> > > > > -1
> > > > > with errno EOPNOTSUPP upon attempts to set security labels on
> > > > > cgroup
> > > > > files; with the patch, the kernel may instead return -1 with
> > > > > errno
> > > > > EACCES if not allowed. So I suppose if userspace was
> > > > > explicitly
> > > > > testing for EOPNOTSUPP and not failing hard in that case, it
> > > > > might
> > > > > cause breakage. Not sure why existing userspace would be
> > > > > trying
> > > > > to
> > > > > relabel cgroup files, unless it is just a recursive
> > > > > restorecon
> > > > > that
> > > > > happens to traverse into a cgroup mount (and in that case,
> > > > > not
> > > > > sure
> > > > > why
> > > > > it would be fatal). Other possible interaction would be use
> > > > > of
> > > > > setfscreatecon() prior to creating a file in cgroup.
> > > >
> > > > Oh, I see - it is the latter.
> > > >
> > > > For example, init.rc does mkdir /dev/cpuctl/bg_non_interactive,
> > > > which
> > > > internally looks up the context for that directory from
> > > > file_contexts
> > > > and does a setfscreatecon() followed by a mkdir(). Previously,
> > > > that
> > > > was ignored because cgroup did not support anything other than
> > > > the
> > > > policy-defined label. But now it will try to use that label,
> > > > which
> > > > in
> > > > turn will trigger a denial in enforcing mode and the create
> > > > will
> > > > fail.
> > > >
> > > > So this is an incompatible change and needs to be reverted.
> > > > We'll need to wrap it up with a policy capability or something
> > > > to
> > > > allow
> > > > it to be enabled only if the policy correctly supports
> > > > it. Even
> > > > better, we should instead just allow the policy to specify
> > > > which
> > > > filesystems should support this behavior (already on the issues
> > > > list).
> > > >
> > >
> > > If Android is the only system affected by this bug, I would
> > > prefer to
> > > just fix Android to allow for this patch, rather than having
> > > additional kernel complexity.
> >
> > Well, it does break userspace (even if it happens to only affect
> > Android, which isn't clear, e.g. possibly a distribution would
> > likewise
> > suffer breakage under a tighter policy), and we already have a
> > long-
> > standing open issue to replace the current set of whitelisted
> > filesystem types with something configuration-driven. So I'm ok
> > with
> > reverting it and requiring it to be done in a more general way.
> > The
> > latter is something we want regardless.
> >
>
> Please revert this, it's not ok to break working userspace
> code. I've
> gotten a few off-line queries as to why this ended up being merged
> when
> it was known to break Android.
It should be fixed by commit 2651225b5ebcdde60f684c4db8ec7e9e3800a74f
("selinux: wrap cgroup seclabel support with its own policy
capability").
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Regression?] 1ea0ce4069 ("selinux: allow changing labels for cgroupfs") stops Android from booting
2017-03-09 17:57 ` Stephen Smalley
@ 2017-03-09 18:36 ` Greg KH
0 siblings, 0 replies; 16+ messages in thread
From: Greg KH @ 2017-03-09 18:36 UTC (permalink / raw)
To: Stephen Smalley
Cc: Nick Kralevich, Paul Moore, John Stultz, Jeffrey Vander Stoep,
Antonio Murdaca, lkml, Android Kernel Team
On Thu, Mar 09, 2017 at 12:57:14PM -0500, Stephen Smalley wrote:
> On Thu, 2017-03-09 at 18:28 +0100, Greg KH wrote:
> > On Mon, Feb 27, 2017 at 04:23:28PM -0500, Stephen Smalley wrote:
> > >
> > > On Mon, 2017-02-27 at 12:48 -0800, Nick Kralevich wrote:
> > > >
> > > > On Mon, Feb 27, 2017 at 11:53 AM, Stephen Smalley <sds@tycho.nsa.
> > > > gov>
> > > > wrote:
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > I can reproduce it on angler (with a back-port of just that
> > > > > > patch),
> > > > > > although I am unclear on the cause. The patch is only
> > > > > > supposed
> > > > > > to
> > > > > > enable explicit setting of security labels by userspace on
> > > > > > cgroup
> > > > > > files, so it isn't supposed to cause any breakage under
> > > > > > existing
> > > > > > policy. Prior to the patch, the kernel would always just
> > > > > > return
> > > > > > -1
> > > > > > with errno EOPNOTSUPP upon attempts to set security labels on
> > > > > > cgroup
> > > > > > files; with the patch, the kernel may instead return -1 with
> > > > > > errno
> > > > > > EACCES if not allowed. So I suppose if userspace was
> > > > > > explicitly
> > > > > > testing for EOPNOTSUPP and not failing hard in that case, it
> > > > > > might
> > > > > > cause breakage. Not sure why existing userspace would be
> > > > > > trying
> > > > > > to
> > > > > > relabel cgroup files, unless it is just a recursive
> > > > > > restorecon
> > > > > > that
> > > > > > happens to traverse into a cgroup mount (and in that case,
> > > > > > not
> > > > > > sure
> > > > > > why
> > > > > > it would be fatal). Other possible interaction would be use
> > > > > > of
> > > > > > setfscreatecon() prior to creating a file in cgroup.
> > > > >
> > > > > Oh, I see - it is the latter.
> > > > >
> > > > > For example, init.rc does mkdir /dev/cpuctl/bg_non_interactive,
> > > > > which
> > > > > internally looks up the context for that directory from
> > > > > file_contexts
> > > > > and does a setfscreatecon() followed by a mkdir(). Previously,
> > > > > that
> > > > > was ignored because cgroup did not support anything other than
> > > > > the
> > > > > policy-defined label. But now it will try to use that label,
> > > > > which
> > > > > in
> > > > > turn will trigger a denial in enforcing mode and the create
> > > > > will
> > > > > fail.
> > > > >
> > > > > So this is an incompatible change and needs to be reverted.
> > > > > We'll need to wrap it up with a policy capability or something
> > > > > to
> > > > > allow
> > > > > it to be enabled only if the policy correctly supports
> > > > > it. Even
> > > > > better, we should instead just allow the policy to specify
> > > > > which
> > > > > filesystems should support this behavior (already on the issues
> > > > > list).
> > > > >
> > > >
> > > > If Android is the only system affected by this bug, I would
> > > > prefer to
> > > > just fix Android to allow for this patch, rather than having
> > > > additional kernel complexity.
> > >
> > > Well, it does break userspace (even if it happens to only affect
> > > Android, which isn't clear, e.g. possibly a distribution would
> > > likewise
> > > suffer breakage under a tighter policy), and we already have a
> > > long-
> > > standing open issue to replace the current set of whitelisted
> > > filesystem types with something configuration-driven. So I'm ok
> > > with
> > > reverting it and requiring it to be done in a more general way.
> > > The
> > > latter is something we want regardless.
> > >
> >
> > Please revert this, it's not ok to break working userspace
> > code. I've
> > gotten a few off-line queries as to why this ended up being merged
> > when
> > it was known to break Android.
>
> It should be fixed by commit 2651225b5ebcdde60f684c4db8ec7e9e3800a74f
> ("selinux: wrap cgroup seclabel support with its own policy
> capability").
Ah, so sorry about this, missed this commit. Nevermind :)
greg k-h
^ permalink raw reply [flat|nested] 16+ messages in thread