Message-ID: <CAGTjWtC-iGP1RGbE8R9EGEM9X_YeA+2wahmNtcNzcU=sb7EBbw@mail.gmail.com>
Date:	Tue, 2 Aug 2011 15:56:03 -0700
From:	Mike Waychison <mikew@...gle.com>
To:	"Andrew G. Morgan" <agm@...gle.com>
Cc:	Maximilian Attems <max@...o.at>,
	Eric Northup <digitaleric@...gle.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"H. Peter Anvin" <hpa@...or.com>,
	Eric Paris <eparis@...isplace.org>, klibc@...or.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 2/2] run-init: Add drop_capabilities support.

On Tue, Aug 2, 2011 at 3:50 PM, Andrew G. Morgan <agm@...gle.com> wrote:
> Which part of the version check are you dropping?

The version check in the patch I posted is used when access to
/proc/sys/kernel/usermodehelper/{bset|inheritable} files fails with
ENOENT (which looking closer is broken in the patch I sent as the
wrong pathnames are used).

Given that I'm only planning on using this on kernels that are v3.0 or
have this code back ported anyway, and the fact the option is new, I'm
going to try changing this over to _always_ failing like in all the
other *something went wrong enforcing the security policy* paths.

>
> Also, I'm not clear you need/want to drop the permitted/effective
> bits. All that will survive the exec() are the inheritable bits.

Okay.  Will drop these.

>
> Cheers
>
> Andrew
>
> On Tue, Aug 2, 2011 at 2:42 PM, Mike Waychison <mikew@...gle.com> wrote:
>> On Tue, Aug 2, 2011 at 2:09 PM, Maximilian Attems <max@...o.at> wrote:
>>> On Fri, 29 Jul 2011, Mike Waychison wrote:
>>>
>>>> On Fri, Jul 29, 2011 at 1:45 PM, Maximilian Attems <max@...o.at> wrote:
>>>> > On Tue, 19 Jul 2011, Mike Waychison wrote:
>>>> >
>>>> >> This patch adds the ability to run-init to allow the dropping of
>>>> >> POSIX capabilities.
>>>> >>
>>>> >> This works by adding a "-d" flag to run-init, which takes a comma
>>>> >> separated list of capability names that should be dropped right before
>>>> >> exec'ing the real init binary.
>>>> >>
>>>> >> kinit is also modified by this change, such that it understands the same
>>>> >> argument when prepended with "drop_capabilities=" on the kernel command
>>>> >> line.
>>>> >>
>>>> >> When processing capabilities to drop, CAP_SETPCAP is special cased to be
>>>> >> dropped last, so that the order that capabilities are given does not
>>>> >> cause dropping of later enumerated capabilities to fail if it is listed
>>>> >> early on.
>>>> >>
>>>> >> Dropping of capabilities happens in three parts.  We explicitly drop the
>>>> >> capability from init's inherited, permitted and effective masks.  We
>>>> >> also drop the capability from the bounding set using PR_CAPBSET_DROP.
>>>> >> Lastly, if available, we drop the capabilities from the bset and
>>>> >> inheritted masks exposed at /proc/sys/kernel/usermodehelper if available
>>>> >> (introduced in v3.0.0).
>>>> >
>>>> > hmm as 3.0 is out, I don't think we need more backward compatibility.
>>>> > do you have a strong arg for it?
>>>> > especially since this is an *optional* calling arg I really don't see
>>>> > the need of that backward crap.
>>>>
>>>> I'd like to keep it for the time being. I'm still building both 2.6.34
>>>> and 2.6.39 kernels at the moment, though I can maintain these last few
>>>> compatibility bits in-house if that makes it easier for you.
>>>
>>> you include anyway linux/version.h, would build disabling help you?
>>> that way that macro doesn't need duplicating.
>>>
>>
>> For correctness sake, I think it's still a runtime check thing
>> (consider the case of an image that is reused between kernel builds).
>>
>> Reflecting on it a bit more though, I'd be okay if we removed the
>> version check altogether and just made it warn if the file isn't
>> present.
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists