* Re: [PATCH v2] coresight-stm: adding driver for CoreSight STM component
From: Mathieu Poirier @ 2015-02-26 14:22 UTC (permalink / raw)
To: Shawn Guo
Cc: Jon Corbet, linux-arm-kernel@lists.infradead.org, linux-api,
linux-kernel@vger.kernel.org, linux-doc
In-Reply-To: <20150226055320.GA20385@dragon>
On 25 February 2015 at 22:53, Shawn Guo <shawn.guo@linaro.org> wrote:
> On Wed, Feb 25, 2015 at 04:32:32PM -0700, Mathieu Poirier wrote:
>> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>> new file mode 100644
>> index 000000000000..3ddb676831ab
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>> @@ -0,0 +1,62 @@
>> +What: /sys/bus/coresight/devices/<memory_map>.stm/enable_source
>> +Date: February 2015
>> +KernelVersion: 3.20
>
> A random comment - there will never be a v3.20 kernel.
That's pretty funny! That part was obviously minted before there was
even an hint of moving to 4.0. Thanks for pointing it out.
>
> Shawn
>
>> +Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
>> +Description: (RW) Enable/disable tracing on this specific trace macrocell.
>> + Enabling the trace macrocell implies it has been configured
>> + properly and a sink has been identidifed for it. The path
>> + of coresight components linking the source to the sink is
>> + configured and managed automatically by the coresight framework.
^ permalink raw reply
* Re: [RFC PATCH 1/3] eeprom: Add a simple EEPROM framework
From: Srinivas Kandagatla @ 2015-02-26 14:56 UTC (permalink / raw)
To: Maxime Ripard
Cc: Stephen Boyd, Rob Herring,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Rob Herring, Pawel Moll, Kumar Gala,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Arnd Bergmann,
Mark Brown, Greg Kroah-Hartman
In-Reply-To: <20150226132107.GH29241@lukather>
On 26/02/15 13:21, Maxime Ripard wrote:
> On Thu, Feb 26, 2015 at 09:16:27AM +0000, Srinivas Kandagatla wrote:
>> I think we are making simple eeprom framework too smart which will
>> break in future.
>>
>> IMHO, Anything on top of eeprom interface that interprets the data should
>> not go into the eeprom framework itself, it can either live some parsers/SOC
>> specific drivers/interfaces.
>
> True, but that doesn't mean that this parser support can't be built
> within the framework itself.
I was more of thinking parsers/interpreters as a layer on top of this
framework. Allowing the simplest users direct access to framework. Also
just eeprom_read() apis would not cater for all the parsers and I think
it would be very difficult to come up with abstracted consumer apis for
all the parsers which could be iterator or link-lists parsers or
something very different.
>
>> As Stephen pointed out earlier lets start with something like this, which
>> would provide a better abstraction to the discussed use cases like
>> serial-number and packed data in eeprom.
>>
>> qfprom@1000000 {
>> reg = <0x1000000 0x1000>;
>> ranges = <0 0x1000000 0x1000>;
>> compatible = "qcom,qfprom-msm8960"
>>
>> pvs-data: pvs-data@40 {
>> compatible = "qcom,pvs-a";
>> reg = <0x40 0x20>,
>> };
>>
>> tsens-data: tmdata@10 {
>> reg = <0x10 40>;
>> };
>>
>> serial-number: serial@50 {
>> compatible = "qcom,serial-msm8960";
>> reg = <0x50 4>, <0x60 4>;
>> };
>>
>> };
>
> And I'm sorry, but I still don't get why the compatibles are needed
> here.
This is an optional property, only purpose of this would be to serve as
parser/soc-specific identifier.
>
>> and then on the consumer side:
>>
>> device {
>> eeproms = <&serial-number>;
>> eeprom-names = "soc-rev-id";
>> };
>>
>> driver side:
>>
>> eeprom_get_cell()
>> eeprom_read();
>
> Looks good otherwise.
thanks
--srini
>
> Maxime
>
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Serge E. Hallyn @ 2015-02-26 15:35 UTC (permalink / raw)
To: Christoph Lameter
Cc: Serge Hallyn, Serge E. Hallyn, Serge Hallyn, Andy Lutomirski,
Aaron Jones, Ted Ts'o, linux-security-module, akpm,
Andrew G. Morgan, Mimi Zohar, Austin S Hemmelgarn, Markku Savela,
Jarkko Sakkinen, linux-kernel, linux-api, Michael Kerrisk,
Jonathan Corbet
In-Reply-To: <alpine.DEB.2.11.1502251423580.13489@gentwo.org>
On Wed, Feb 25, 2015 at 02:25:19PM -0600, Christoph Lameter wrote:
> On Wed, 25 Feb 2015, Serge Hallyn wrote:
>
> > Yeah we could make this
>
> Well doing that breaks su.
Don't what exactly? You're saying that doing
pI' = pI
pA' = pA (pA is ambient)
pP' = (X & fP) | (pI & (fI | pA))
pE' = pP' & (fE | pA)
stopped su from having CAP_SETGID while
pI' = pI
pA' = pA (pA is ambient)
pP' = (X & fP) | (pI & (fI | pA))
pE' = pP' & fE
worked? I'll hope you're saying both "fail", in which case
> Its best to leave perm bits untouched.
> christoph@fujitsu-haswell:~$ su
> setgid: Operation not permitted
Did you initialize by running a program to fill your pI?
-serge
^ permalink raw reply
* [PATCH 3/3] Documentation/ABI: Add file describing the sysfs entries for toshiba_haps
From: Azael Avalos @ 2015-02-26 17:59 UTC (permalink / raw)
To: Darren Hart, platform-driver-x86-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA
Cc: Azael Avalos
This patch adds a new file describing the sysfs entries for the
toshiba_haps driver.
Signed-off-by: Azael Avalos <coproscefalo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Documentation/ABI/testing/sysfs-driver-toshiba_haps | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-toshiba_haps
diff --git a/Documentation/ABI/testing/sysfs-driver-toshiba_haps b/Documentation/ABI/testing/sysfs-driver-toshiba_haps
new file mode 100644
index 0000000..a662370
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-toshiba_haps
@@ -0,0 +1,20 @@
+What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS620A:00/protection_level
+Date: August 16, 2014
+KernelVersion: 3.17
+Contact: Azael Avalos <coproscefalo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+Description: This file controls the built-in accelerometer protection level,
+ valid values are:
+ * 0 -> Disabled
+ * 1 -> Low
+ * 2 -> Medium
+ * 3 -> High
+ The default potection value is set to 2 (Medium).
+Users: KToshiba
+
+What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS620A:00/reset_protection
+Date: August 16, 2014
+KernelVersion: 3.17
+Contact: Azael Avalos <coproscefalo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+Description: This file turns off the built-in accelerometer for a few
+ seconds and then restore normal operation. Accepting 1 as the
+ only parameter.
--
2.2.2
^ permalink raw reply related
* Re: [PATCH] capabilities: Ambient capability set V1
From: Christoph Lameter @ 2015-02-26 18:28 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Serge Hallyn, Serge Hallyn, Andy Lutomirski, Aaron Jones,
Ted Ts'o, linux-security-module-u79uwXL29TY76Z2rM5mHXA,
akpm-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Michael Kerrisk,
Jonathan Corbet
In-Reply-To: <20150226153524.GC15182-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
> > Well doing that breaks su.
>
> Don't what exactly? You're saying that doing
>
> pI' = pI
> pA' = pA (pA is ambient)
> pP' = (X & fP) | (pI & (fI | pA))
> pE' = pP' & (fE | pA)
>
> stopped su from having CAP_SETGID while
>
> pI' = pI
> pA' = pA (pA is ambient)
> pP' = (X & fP) | (pI & (fI | pA))
> pE' = pP' & fE
>
> worked? I'll hope you're saying both "fail", in which case
fE does not exist in cpu_vfs_cap_data. We only get fI and fP. Why in the
world does setcap allow setting fE?
V1 does not use fE. In my newer attempt, I seemed to have worked
with zeroed field that I assumed was filled in.
I will just do
pE' = pP'
Ok?
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Serge E. Hallyn @ 2015-02-26 19:32 UTC (permalink / raw)
To: Christoph Lameter
Cc: Serge E. Hallyn, Serge Hallyn, Serge Hallyn, Andy Lutomirski,
Aaron Jones, Ted Ts'o, linux-security-module, akpm,
Andrew G. Morgan, Mimi Zohar, Austin S Hemmelgarn, Markku Savela,
Jarkko Sakkinen, linux-kernel, linux-api, Michael Kerrisk,
Jonathan Corbet
In-Reply-To: <alpine.DEB.2.11.1502261224580.7451@gentwo.org>
On Thu, Feb 26, 2015 at 12:28:30PM -0600, Christoph Lameter wrote:
> On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
>
> > > Well doing that breaks su.
> >
> > Don't what exactly? You're saying that doing
> >
> > pI' = pI
> > pA' = pA (pA is ambient)
> > pP' = (X & fP) | (pI & (fI | pA))
> > pE' = pP' & (fE | pA)
> >
> > stopped su from having CAP_SETGID while
> >
> > pI' = pI
> > pA' = pA (pA is ambient)
> > pP' = (X & fP) | (pI & (fI | pA))
> > pE' = pP' & fE
> >
> > worked? I'll hope you're saying both "fail", in which case
>
> fE does not exist in cpu_vfs_cap_data. We only get fI and fP. Why in the
> world does setcap allow setting fE?
It sets a bit in the magic_etc. So fE is either all on or all off.
> V1 does not use fE. In my newer attempt, I seemed to have worked
> with zeroed field that I assumed was filled in.
>
> I will just do
>
> pE' = pP'
>
> Ok?
Andrew Morgan was against that. What if we changed
pE' = pP' & (fE | pA)
to
if (pA)
pE' = pP' & fE
else
pE' = pP'
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Andy Lutomirski @ 2015-02-26 19:38 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Christoph Lameter, Serge Hallyn, Serge Hallyn, Aaron Jones,
Ted Ts'o, LSM List, Andrew Morton, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel@vger.kernel.org, Linux API, Michael Kerrisk,
Jonathan Corbet
In-Reply-To: <20150226193200.GA17709@mail.hallyn.com>
On Thu, Feb 26, 2015 at 11:32 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
> On Thu, Feb 26, 2015 at 12:28:30PM -0600, Christoph Lameter wrote:
>> On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
>>
>> > > Well doing that breaks su.
>> >
>> > Don't what exactly? You're saying that doing
>> >
>> > pI' = pI
>> > pA' = pA (pA is ambient)
>> > pP' = (X & fP) | (pI & (fI | pA))
>> > pE' = pP' & (fE | pA)
>> >
>> > stopped su from having CAP_SETGID while
>> >
>> > pI' = pI
>> > pA' = pA (pA is ambient)
>> > pP' = (X & fP) | (pI & (fI | pA))
>> > pE' = pP' & fE
>> >
>> > worked? I'll hope you're saying both "fail", in which case
>>
>> fE does not exist in cpu_vfs_cap_data. We only get fI and fP. Why in the
>> world does setcap allow setting fE?
>
> It sets a bit in the magic_etc. So fE is either all on or all off.
>
>> V1 does not use fE. In my newer attempt, I seemed to have worked
>> with zeroed field that I assumed was filled in.
>>
>> I will just do
>>
>> pE' = pP'
>>
>> Ok?
>
> Andrew Morgan was against that. What if we changed
>
> pE' = pP' & (fE | pA)
>
> to
>
> if (pA)
> pE' = pP' & fE
> else
> pE' = pP'
>
Is this backwards?
Also, on further bikeshedding consideration, I think I like the name
"persistent" much better than "ambient". Alas, "persistent" starts
with a P.
--Andy
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Christoph Lameter @ 2015-02-26 20:13 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Serge Hallyn, Serge Hallyn, Andy Lutomirski, Aaron Jones,
Ted Ts'o, linux-security-module-u79uwXL29TY76Z2rM5mHXA,
akpm-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Michael Kerrisk,
Jonathan Corbet
In-Reply-To: <20150226193200.GA17709-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
> Andrew Morgan was against that. What if we changed
>
> pE' = pP' & (fE | pA)
>
> to
>
> if (pA)
> pE' = pP' & fE
> else
> pE' = pP'
>
Same problem as before. The ambient bits will not be set in pE'.
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Christoph Lameter @ 2015-02-26 20:16 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Serge E. Hallyn, Serge Hallyn, Serge Hallyn, Aaron Jones,
Ted Ts'o, LSM List, Andrew Morton, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux API,
Michael Kerrisk, Jonathan Corbet
In-Reply-To: <CALCETrWpKiurZEEOT25i_xrtQyk5dht+wjUO4+tGs+N_7JCdYA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, 26 Feb 2015, Andy Lutomirski wrote:
> Also, on further bikeshedding consideration, I think I like the name
> "persistent" much better than "ambient". Alas, "persistent" starts
> with a P.
Ambient is like backround lighting. Its always there but barely visible.
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Serge E. Hallyn @ 2015-02-26 20:33 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Serge E. Hallyn, Christoph Lameter, Serge Hallyn, Serge Hallyn,
Aaron Jones, Ted Ts'o, LSM List, Andrew Morton,
Andrew G. Morgan, Mimi Zohar, Austin S Hemmelgarn, Markku Savela,
Jarkko Sakkinen, linux-kernel@vger.kernel.org, Linux API,
Michael Kerrisk, Jonathan Corbet
In-Reply-To: <CALCETrWpKiurZEEOT25i_xrtQyk5dht+wjUO4+tGs+N_7JCdYA@mail.gmail.com>
On Thu, Feb 26, 2015 at 11:38:01AM -0800, Andy Lutomirski wrote:
> On Thu, Feb 26, 2015 at 11:32 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
> > On Thu, Feb 26, 2015 at 12:28:30PM -0600, Christoph Lameter wrote:
> >> On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
> >>
> >> > > Well doing that breaks su.
> >> >
> >> > Don't what exactly? You're saying that doing
> >> >
> >> > pI' = pI
> >> > pA' = pA (pA is ambient)
> >> > pP' = (X & fP) | (pI & (fI | pA))
> >> > pE' = pP' & (fE | pA)
> >> >
> >> > stopped su from having CAP_SETGID while
> >> >
> >> > pI' = pI
> >> > pA' = pA (pA is ambient)
> >> > pP' = (X & fP) | (pI & (fI | pA))
> >> > pE' = pP' & fE
> >> >
> >> > worked? I'll hope you're saying both "fail", in which case
> >>
> >> fE does not exist in cpu_vfs_cap_data. We only get fI and fP. Why in the
> >> world does setcap allow setting fE?
> >
> > It sets a bit in the magic_etc. So fE is either all on or all off.
> >
> >> V1 does not use fE. In my newer attempt, I seemed to have worked
> >> with zeroed field that I assumed was filled in.
> >>
> >> I will just do
> >>
> >> pE' = pP'
> >>
> >> Ok?
> >
> > Andrew Morgan was against that. What if we changed
> >
> > pE' = pP' & (fE | pA)
> >
> > to
> >
> > if (pA)
> > pE' = pP' & fE
> > else
> > pE' = pP'
> >
>
> Is this backwards?
D'oh, yes.
> Also, on further bikeshedding consideration, I think I like the name
> "persistent" much better than "ambient". Alas, "persistent" starts
> with a P.
>
> --Andy
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Serge E. Hallyn @ 2015-02-26 20:34 UTC (permalink / raw)
To: Christoph Lameter
Cc: Serge E. Hallyn, Serge Hallyn, Serge Hallyn, Andy Lutomirski,
Aaron Jones, Ted Ts'o, linux-security-module, akpm,
Andrew G. Morgan, Mimi Zohar, Austin S Hemmelgarn, Markku Savela,
Jarkko Sakkinen, linux-kernel, linux-api, Michael Kerrisk,
Jonathan Corbet
In-Reply-To: <alpine.DEB.2.11.1502261412250.7451@gentwo.org>
On Thu, Feb 26, 2015 at 02:13:00PM -0600, Christoph Lameter wrote:
> On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
>
> > Andrew Morgan was against that. What if we changed
> >
> > pE' = pP' & (fE | pA)
> >
> > to
> >
> > if (pA)
> > pE' = pP' & fE
> > else
> > pE' = pP'
> >
>
> Same problem as before. The ambient bits will not be set in pE'.
And what if I weren't scatterbrained and we did
if (pA)
pE' = pP'
else
pE' = pP' & fE
All pP' bits would be set in pE'.
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Andy Lutomirski @ 2015-02-26 20:51 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Christoph Lameter, Serge Hallyn, Serge Hallyn, Aaron Jones,
Ted Ts'o, LSM List, Andrew Morton, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel@vger.kernel.org, Linux API, Michael Kerrisk,
Jonathan Corbet
In-Reply-To: <20150226203405.GB18926@mail.hallyn.com>
On Thu, Feb 26, 2015 at 12:34 PM, Serge E. Hallyn <serge@hallyn.com> wrote:
> On Thu, Feb 26, 2015 at 02:13:00PM -0600, Christoph Lameter wrote:
>> On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
>>
>> > Andrew Morgan was against that. What if we changed
>> >
>> > pE' = pP' & (fE | pA)
>> >
>> > to
>> >
>> > if (pA)
>> > pE' = pP' & fE
>> > else
>> > pE' = pP'
>> >
>>
>> Same problem as before. The ambient bits will not be set in pE'.
>
> And what if I weren't scatterbrained and we did
>
> if (pA)
> pE' = pP'
> else
> pE' = pP' & fE
>
> All pP' bits would be set in pE'.
That seems reasonable to me, except for my paranoia:
What if there's a program with CAP_DAC_OVERRIDE in fP and fE set to
the empty set (i.e. the magic effective bit cleared), and the program
relies on that. A malicious user has CAP_NET_BIND and sets pA =
CAP_NET_BIND. Boom!
If we changed that to if (pA') and zeroed pA if fP is non-empty then
this problem goes away.
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Serge E. Hallyn @ 2015-02-26 20:55 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Serge E. Hallyn, Christoph Lameter, Serge Hallyn, Serge Hallyn,
Aaron Jones, Ted Ts'o, LSM List, Andrew Morton,
Andrew G. Morgan, Mimi Zohar, Austin S Hemmelgarn, Markku Savela,
Jarkko Sakkinen, linux-kernel@vger.kernel.org, Linux API,
Michael Kerrisk, Jonathan Corbet
In-Reply-To: <CALCETrUB1bb4TiiBgdAMVtRJcEAoDzuOH+StTLPVL8QiXXdOfQ@mail.gmail.com>
On Thu, Feb 26, 2015 at 12:51:57PM -0800, Andy Lutomirski wrote:
> On Thu, Feb 26, 2015 at 12:34 PM, Serge E. Hallyn <serge@hallyn.com> wrote:
> > On Thu, Feb 26, 2015 at 02:13:00PM -0600, Christoph Lameter wrote:
> >> On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
> >>
> >> > Andrew Morgan was against that. What if we changed
> >> >
> >> > pE' = pP' & (fE | pA)
> >> >
> >> > to
> >> >
> >> > if (pA)
> >> > pE' = pP' & fE
> >> > else
> >> > pE' = pP'
> >> >
> >>
> >> Same problem as before. The ambient bits will not be set in pE'.
> >
> > And what if I weren't scatterbrained and we did
> >
> > if (pA)
> > pE' = pP'
> > else
> > pE' = pP' & fE
> >
> > All pP' bits would be set in pE'.
>
> That seems reasonable to me, except for my paranoia:
>
> What if there's a program with CAP_DAC_OVERRIDE in fP and fE set to
> the empty set (i.e. the magic effective bit cleared), and the program
> relies on that. A malicious user has CAP_NET_BIND and sets pA =
> CAP_NET_BIND. Boom!
>
> If we changed that to if (pA') and zeroed pA if fP is non-empty then
> this problem goes away.
Hm, the problem is that then the empty pA is inherited by children.
I do see that any program with fP set should probably run with only
what it requested. Would
if (pA && is_empty(fP))
pE' = pP'
else
pE' = pP' & fE
help? Or are you worried about a program with fP set which then
executes other programs?
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Andy Lutomirski @ 2015-02-26 20:58 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Christoph Lameter, Serge Hallyn, Serge Hallyn, Aaron Jones,
Ted Ts'o, LSM List, Andrew Morton, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux API,
Michael Kerrisk, Jonathan Corbet
In-Reply-To: <20150226205512.GA19273-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
On Thu, Feb 26, 2015 at 12:55 PM, Serge E. Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> wrote:
> On Thu, Feb 26, 2015 at 12:51:57PM -0800, Andy Lutomirski wrote:
>> On Thu, Feb 26, 2015 at 12:34 PM, Serge E. Hallyn <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> wrote:
>> > On Thu, Feb 26, 2015 at 02:13:00PM -0600, Christoph Lameter wrote:
>> >> On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
>> >>
>> >> > Andrew Morgan was against that. What if we changed
>> >> >
>> >> > pE' = pP' & (fE | pA)
>> >> >
>> >> > to
>> >> >
>> >> > if (pA)
>> >> > pE' = pP' & fE
>> >> > else
>> >> > pE' = pP'
>> >> >
>> >>
>> >> Same problem as before. The ambient bits will not be set in pE'.
>> >
>> > And what if I weren't scatterbrained and we did
>> >
>> > if (pA)
>> > pE' = pP'
>> > else
>> > pE' = pP' & fE
>> >
>> > All pP' bits would be set in pE'.
>>
>> That seems reasonable to me, except for my paranoia:
>>
>> What if there's a program with CAP_DAC_OVERRIDE in fP and fE set to
>> the empty set (i.e. the magic effective bit cleared), and the program
>> relies on that. A malicious user has CAP_NET_BIND and sets pA =
>> CAP_NET_BIND. Boom!
>>
>> If we changed that to if (pA') and zeroed pA if fP is non-empty then
>> this problem goes away.
>
> Hm, the problem is that then the empty pA is inherited by children.
> I do see that any program with fP set should probably run with only
> what it requested. Would
>
> if (pA && is_empty(fP))
> pE' = pP'
> else
> pE' = pP' & fE
>
> help? Or are you worried about a program with fP set which then
> executes other programs?
The particular worry I expressed there was just about pE.
I'm still extremely nervous about allowing nonempty pA to propagate to
setuid or nonzero fP programs. It's less obviously dangerous if pA is
never a superset of pP, but it could still cause problems with setuid
programs that execute intentionally deprivileged helpers.
--Andy
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Christoph Lameter @ 2015-02-26 21:09 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Serge Hallyn, Serge Hallyn, Andy Lutomirski, Aaron Jones,
Ted Ts'o, linux-security-module, akpm, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel, linux-api, Michael Kerrisk, Jonathan Corbet
In-Reply-To: <20150226203405.GB18926@mail.hallyn.com>
On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
> > Same problem as before. The ambient bits will not be set in pE'.
>
> And what if I weren't scatterbrained and we did
>
> if (pA)
> pE' = pP'
> else
> pE' = pP' & fE
>
> All pP' bits would be set in pE'.
Ok and the non ambient case would break because fE is not available?
Doesnt this reduce to
pE' = pP'
in either case?
Here is a a patch that does just that. The patch works. Maybe I just dont
understand how this is supposed to work.
Subject: [PATCH] capabilities: Ambient capability set V2(draft)
V1->V2(draft):
- Modify bit calculations.
Signed-off-by: Christoph Lameter <cl@linux.com>
Index: linux/security/commoncap.c
===================================================================
--- linux.orig/security/commoncap.c 2015-02-25 13:43:06.929973954 -0600
+++ linux/security/commoncap.c 2015-02-26 12:36:32.361726374 -0600
@@ -347,15 +347,16 @@ static inline int bprm_caps_from_vfs_cap
*has_cap = true;
CAP_FOR_EACH_U32(i) {
+ __u32 ambient = current_cred()->cap_ambient.cap[i];
__u32 permitted = caps->permitted.cap[i];
__u32 inheritable = caps->inheritable.cap[i];
/*
- * pP' = (X & fP) | (pI & fI)
+ * pP' = (X & fP) | (pI & (fI | pA))
*/
new->cap_permitted.cap[i] =
(new->cap_bset.cap[i] & permitted) |
- (new->cap_inheritable.cap[i] & inheritable);
+ (new->cap_inheritable.cap[i] & (inheritable | ambient));
if (permitted & ~new->cap_permitted.cap[i])
/* insufficient to execute correctly */
@@ -453,8 +454,12 @@ static int get_file_caps(struct linux_bi
if (rc == -EINVAL)
printk(KERN_NOTICE "%s: get_vfs_caps_from_disk returned %d for %s\n",
__func__, rc, bprm->filename);
- else if (rc == -ENODATA)
+ else if (rc == -ENODATA) {
rc = 0;
+ /* The ambient caps are permitted for files that have no caps */
+ bprm->cred->cap_permitted = bprm->cred->cap_effective =
+ current_cred()->cap_ambient;
+ }
goto out;
}
@@ -548,10 +553,16 @@ skip:
new->suid = new->fsuid = new->euid;
new->sgid = new->fsgid = new->egid;
- if (effective)
- new->cap_effective = new->cap_permitted;
- else
- cap_clear(new->cap_effective);
+ /* pE' = pP' & (fE | pA)
+ new->cap_effective = cap_intersect(new->cap_permitted,
+ cap_combine(new->cap_effective, old->cap_ambient));
+ */
+
+ /* fE is not available */
+ new->cap_effective = new->cap_permitted;
+
+ /* pA' = pA */
+ new->cap_ambient = old->cap_ambient;
bprm->cap_effective = effective;
/*
@@ -566,7 +577,7 @@ skip:
* Number 1 above might fail if you don't have a full bset, but I think
* that is interesting information to audit.
*/
- if (!cap_isclear(new->cap_effective)) {
+ if (!cap_issubset(new->cap_effective, new->cap_ambient)) {
if (!cap_issubset(CAP_FULL_SET, new->cap_effective) ||
!uid_eq(new->euid, root_uid) || !uid_eq(new->uid, root_uid) ||
issecure(SECURE_NOROOT)) {
@@ -598,7 +609,7 @@ int cap_bprm_secureexec(struct linux_bin
if (!uid_eq(cred->uid, root_uid)) {
if (bprm->cap_effective)
return 1;
- if (!cap_isclear(cred->cap_permitted))
+ if (!cap_issubset(cred->cap_permitted, cred->cap_ambient))
return 1;
}
@@ -933,6 +944,23 @@ int cap_task_prctl(int option, unsigned
new->securebits &= ~issecure_mask(SECURE_KEEP_CAPS);
return commit_creds(new);
+ case PR_CAP_AMBIENT:
+ if (!ns_capable(current_user_ns(), CAP_SETPCAP))
+ return -EPERM;
+
+ if (!cap_valid(arg2))
+ return -EINVAL;
+
+ if (!ns_capable(current_user_ns(), arg2))
+ return -EPERM;
+
+ new = prepare_creds();
+ if (arg3 == 0)
+ cap_lower(new->cap_ambient, arg2);
+ else
+ cap_raise(new->cap_ambient, arg2);
+ return commit_creds(new);
+
default:
/* No functionality available - continue with default */
return -ENOSYS;
Index: linux/include/linux/cred.h
===================================================================
--- linux.orig/include/linux/cred.h 2015-02-25 13:43:06.929973954 -0600
+++ linux/include/linux/cred.h 2015-02-25 13:43:06.925972078 -0600
@@ -122,6 +122,7 @@ struct cred {
kernel_cap_t cap_permitted; /* caps we're permitted */
kernel_cap_t cap_effective; /* caps we can actually use */
kernel_cap_t cap_bset; /* capability bounding set */
+ kernel_cap_t cap_ambient; /* Ambient capability set */
#ifdef CONFIG_KEYS
unsigned char jit_keyring; /* default keyring to attach requested
* keys to */
Index: linux/include/uapi/linux/prctl.h
===================================================================
--- linux.orig/include/uapi/linux/prctl.h 2015-02-25 13:43:06.929973954 -0600
+++ linux/include/uapi/linux/prctl.h 2015-02-25 13:43:06.925972078 -0600
@@ -185,4 +185,7 @@ struct prctl_mm_map {
#define PR_MPX_ENABLE_MANAGEMENT 43
#define PR_MPX_DISABLE_MANAGEMENT 44
+/* Control the ambient capability set */
+#define PR_CAP_AMBIENT 45
+
#endif /* _LINUX_PRCTL_H */
Index: linux/fs/proc/array.c
===================================================================
--- linux.orig/fs/proc/array.c 2015-02-25 13:43:06.929973954 -0600
+++ linux/fs/proc/array.c 2015-02-25 13:43:06.925972078 -0600
@@ -302,7 +302,8 @@ static void render_cap_t(struct seq_file
static inline void task_cap(struct seq_file *m, struct task_struct *p)
{
const struct cred *cred;
- kernel_cap_t cap_inheritable, cap_permitted, cap_effective, cap_bset;
+ kernel_cap_t cap_inheritable, cap_permitted, cap_effective,
+ cap_bset, cap_ambient;
rcu_read_lock();
cred = __task_cred(p);
@@ -310,12 +311,14 @@ static inline void task_cap(struct seq_f
cap_permitted = cred->cap_permitted;
cap_effective = cred->cap_effective;
cap_bset = cred->cap_bset;
+ cap_ambient = cred->cap_ambient;
rcu_read_unlock();
render_cap_t(m, "CapInh:\t", &cap_inheritable);
render_cap_t(m, "CapPrm:\t", &cap_permitted);
render_cap_t(m, "CapEff:\t", &cap_effective);
render_cap_t(m, "CapBnd:\t", &cap_bset);
+ render_cap_t(m, "CapAmb:\t", &cap_ambient);
}
static inline void task_seccomp(struct seq_file *m, struct task_struct *p)
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Serge E. Hallyn @ 2015-02-26 21:13 UTC (permalink / raw)
To: Christoph Lameter
Cc: Serge E. Hallyn, Serge Hallyn, Serge Hallyn, Andy Lutomirski,
Aaron Jones, Ted Ts'o,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
akpm-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Michael Kerrisk,
Jonathan Corbet
In-Reply-To: <alpine.DEB.2.11.1502261507450.8274-gkYfJU5Cukgdnm+yROfE0A@public.gmane.org>
On Thu, Feb 26, 2015 at 03:09:48PM -0600, Christoph Lameter wrote:
> On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
>
> > > Same problem as before. The ambient bits will not be set in pE'.
> >
> > And what if I weren't scatterbrained and we did
> >
> > if (pA)
> > pE' = pP'
> > else
> > pE' = pP' & fE
> >
> > All pP' bits would be set in pE'.
>
> Ok and the non ambient case would break because fE is not available?
> Doesnt this reduce to
>
> pE' = pP'
>
> in either case?
No. fE is not "not available". If you set it with setcap, you *should*
(if i'm tinking right) find fE full when calculating the new capability
sets, because of magic_etc.
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Serge E. Hallyn @ 2015-02-26 21:19 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Serge E. Hallyn, Christoph Lameter, Serge Hallyn, Serge Hallyn,
Aaron Jones, Ted Ts'o, LSM List, Andrew Morton,
Andrew G. Morgan, Mimi Zohar, Austin S Hemmelgarn, Markku Savela,
Jarkko Sakkinen, linux-kernel@vger.kernel.org, Linux API,
Michael Kerrisk, Jonathan Corbet
In-Reply-To: <CALCETrXGO+ejHAfic4fozf1y48WDBdk3Mo=dFt8MMxtN1HOuUg@mail.gmail.com>
On Thu, Feb 26, 2015 at 12:58:33PM -0800, Andy Lutomirski wrote:
> On Thu, Feb 26, 2015 at 12:55 PM, Serge E. Hallyn <serge@hallyn.com> wrote:
> > On Thu, Feb 26, 2015 at 12:51:57PM -0800, Andy Lutomirski wrote:
> >> On Thu, Feb 26, 2015 at 12:34 PM, Serge E. Hallyn <serge@hallyn.com> wrote:
> >> > On Thu, Feb 26, 2015 at 02:13:00PM -0600, Christoph Lameter wrote:
> >> >> On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
> >> >>
> >> >> > Andrew Morgan was against that. What if we changed
> >> >> >
> >> >> > pE' = pP' & (fE | pA)
> >> >> >
> >> >> > to
> >> >> >
> >> >> > if (pA)
> >> >> > pE' = pP' & fE
> >> >> > else
> >> >> > pE' = pP'
> >> >> >
> >> >>
> >> >> Same problem as before. The ambient bits will not be set in pE'.
> >> >
> >> > And what if I weren't scatterbrained and we did
> >> >
> >> > if (pA)
> >> > pE' = pP'
> >> > else
> >> > pE' = pP' & fE
> >> >
> >> > All pP' bits would be set in pE'.
> >>
> >> That seems reasonable to me, except for my paranoia:
> >>
> >> What if there's a program with CAP_DAC_OVERRIDE in fP and fE set to
> >> the empty set (i.e. the magic effective bit cleared), and the program
> >> relies on that. A malicious user has CAP_NET_BIND and sets pA =
> >> CAP_NET_BIND. Boom!
> >>
> >> If we changed that to if (pA') and zeroed pA if fP is non-empty then
> >> this problem goes away.
> >
> > Hm, the problem is that then the empty pA is inherited by children.
> > I do see that any program with fP set should probably run with only
> > what it requested. Would
> >
> > if (pA && is_empty(fP))
> > pE' = pP'
> > else
> > pE' = pP' & fE
> >
> > help? Or are you worried about a program with fP set which then
> > executes other programs?
>
> The particular worry I expressed there was just about pE.
>
> I'm still extremely nervous about allowing nonempty pA to propagate to
> setuid or nonzero fP programs. It's less obviously dangerous if pA is
> never a superset of pP, but it could still cause problems with setuid
> programs that execute intentionally deprivileged helpers.
I don't think that what you want is compatible with what Christoph
wants. (He also thinks that what I want is not compatible with what
he wants, but I still think it is)
The approach I'm taking is that pA is useless if pI is not set. For
a privileged program to fill its pI is a pretty special thing now,
so this shouldn't be catching anyone by surprise. Furthermore,
the privileged program which is filling both its pI and pA
and then executing other files could achieve the same result
by filling pI and setting file capaiblities on all executables.
Setting pA gives them a different tradeoff (limiting the
capabilities trust to its process tree, but to all binaries)
which should do what Christoph wants. By limiting the effective pA to fP
if fP is not empty, we'r eonly prevneting the file which
had fP set from running in an unexpected way which should be
safer. (But if it executes another file, that file, it will
receive the original pA)
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Christoph Lameter @ 2015-02-26 21:23 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Serge Hallyn, Serge Hallyn, Andy Lutomirski, Aaron Jones,
Ted Ts'o, linux-security-module, akpm, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel, linux-api, Michael Kerrisk, Jonathan Corbet
In-Reply-To: <20150226211324.GB19273@mail.hallyn.com>
On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
> No. fE is not "not available". If you set it with setcap, you *should*
> (if i'm tinking right) find fE full when calculating the new capability
> sets, because of magic_etc.
There is nothing in get_vfs_caps_from_disk that does this and the magic
vanishes after this function is done.
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Christoph Lameter @ 2015-02-26 21:29 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Serge E. Hallyn, Serge Hallyn, Serge Hallyn, Aaron Jones,
Ted Ts'o, LSM List, Andrew Morton, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel@vger.kernel.org, Linux API, Michael Kerrisk,
Jonathan Corbet
In-Reply-To: <CALCETrXGO+ejHAfic4fozf1y48WDBdk3Mo=dFt8MMxtN1HOuUg@mail.gmail.com>
On Thu, 26 Feb 2015, Andy Lutomirski wrote:
> I'm still extremely nervous about allowing nonempty pA to propagate to
> setuid or nonzero fP programs. It's less obviously dangerous if pA is
> never a superset of pP, but it could still cause problems with setuid
> programs that execute intentionally deprivileged helpers.
Well but the intend of the ambient caps is that all processes spawned have
those caps. So they should not be dropped implicitly by othe mechanisms
because they could spawn scripts etc that need these privs again.
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Serge E. Hallyn @ 2015-02-26 21:32 UTC (permalink / raw)
To: Christoph Lameter
Cc: Serge E. Hallyn, Serge Hallyn, Serge Hallyn, Andy Lutomirski,
Aaron Jones, Ted Ts'o, linux-security-module, akpm,
Andrew G. Morgan, Mimi Zohar, Austin S Hemmelgarn, Markku Savela,
Jarkko Sakkinen, linux-kernel, linux-api, Michael Kerrisk,
Jonathan Corbet
In-Reply-To: <alpine.DEB.2.11.1502261522300.8444@gentwo.org>
On Thu, Feb 26, 2015 at 03:23:35PM -0600, Christoph Lameter wrote:
> On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
>
> > No. fE is not "not available". If you set it with setcap, you *should*
> > (if i'm tinking right) find fE full when calculating the new capability
> > sets, because of magic_etc.
>
> There is nothing in get_vfs_caps_from_disk that does this and the magic
> vanishes after this function is done.
get_vfs_caps_from_disk does:
cpu_caps->magic_etc = magic_etc = le32_to_cpu(caps.magic_etc);
then bprm_caps_from_vfs_caps does:
if (caps->magic_etc & VFS_CAP_FLAGS_EFFECTIVE)
*effective = true;
and finally cap_bprm_set_creds does:
if (effective)
new->cap_effective = new->cap_permitted;
else
cap_clear(new->cap_effective);
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Christoph Lameter @ 2015-02-26 21:37 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Serge Hallyn, Serge Hallyn, Andy Lutomirski, Aaron Jones,
Ted Ts'o, linux-security-module, akpm, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel, linux-api, Michael Kerrisk, Jonathan Corbet
In-Reply-To: <20150226213236.GA19753@mail.hallyn.com>
On Thu, 26 Feb 2015, Serge E. Hallyn wrote:
> > There is nothing in get_vfs_caps_from_disk that does this and the magic
> > vanishes after this function is done.
>
> get_vfs_caps_from_disk does:
>
> cpu_caps->magic_etc = magic_etc = le32_to_cpu(caps.magic_etc);
>
> then bprm_caps_from_vfs_caps does:
>
> if (caps->magic_etc & VFS_CAP_FLAGS_EFFECTIVE)
> *effective = true;
Ahhh.. I was wondering what that is.
> and finally cap_bprm_set_creds does:
>
> if (effective)
> new->cap_effective = new->cap_permitted;
> else
> cap_clear(new->cap_effective);
Ok. I took that out thats why it worked.
^ permalink raw reply
* Re: [PATCH 2/2] fbcon: expose cursor blink interval via sysfs
From: Pavel Machek @ 2015-02-26 22:02 UTC (permalink / raw)
To: Scot Doyle
Cc: Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Geert Uytterhoeven, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.LNX.2.11.1502252319330.276@localhost>
On Wed 2015-02-25 23:32:00, Scot Doyle wrote:
> On Wed, 25 Feb 2015, Pavel Machek wrote:
> > On Mon 2015-01-26 20:41:53, Scot Doyle wrote:
> > > The fbcon cursor, when set to blink, is hardcoded to toggle display state
> > > five times per second. Expose this setting via
> > > /sys/class/graphics/fbcon/cursor_blink_ms
> > >
> > > Values written to the interface set the approximate time interval in
> > > milliseconds between cursor toggles, from 1 to 32767. Since the interval
> > > is stored internally as a number of jiffies, the millisecond value read
> > > from the interface may not exactly match the entered value.
> > >
> > > An outstanding blink timer is reset after a new value is entered.
> > >
> > > If the cursor blink is disabled, either via the 'cursor_blink' boolean
> > > setting or some other mechanism, the 'cursor_blink_ms' setting may still
> > > be modified. The new value will be used if the blink is reactivated.
> > >
> > > Signed-off-by: Scot Doyle <lkml14-enLWO88E2pdl57MIdRCFDg@public.gmane.org>
> >
> > Normally, this would be set by ansi escape sequences, no? We can hide
> > cursor using them, set its appearance.. makes sense to change timing
> > value there, too....
> > Pavel
>
> Hi Pavel, what about something like this? For example,
> "echo -e '\033[16;500]' would set the blink interval to 500 milliseconds.
>
> The duration is stored twice to avoid locking the console in
> cursor_timer_handler().
Yes, I'd say this matches the existing code better.
Acked-by: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
> + case 16: /* set cursor blink duration in msec */
> + if (vc->vc_npar >= 1 && vc->vc_par[1] > 0 &&
> + vc->vc_par[1] <= USHRT_MAX)
> + vc->vc_cur_blink_ms = vc->vc_par[1];
> + else
Actually, vc_cur_blink_ms less then about 50 probably does not make
sense (and may overload the system). Should that be checked?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH] capabilities: Ambient capability set V2
From: Christoph Lameter @ 2015-02-26 22:14 UTC (permalink / raw)
To: Serge Hallyn
Cc: Andy Lutomirski, Jonathan Corbet, Aaron Jones,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
akpm-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-api-u79uwXL29TY76Z2rM5mHXA, Michael Kerrisk
V1->V2:
- Fix up the processing of the caps bits after discussions
with Any and Serge. Make patch less intrusive.
Ambient caps are something like restricted root privileges.
A process has a set of additional capabilities and those
are inherited without have to set capabilites in other
binaries involved. This allow the partial use of root
like features in a controlled way. It is often useful
to do this for user space device drivers or software that
needs increased priviledges for networking or to control
its own scheduling. Ambient caps allow one to avoid
having to run these with full root priviledges.
Control over this feature is avaialable via a new
prctl option called PR_CAP_AMBIENT. The second argument to prctl
is a the capability number and the third the desired state.
0 for off. Otherwise on.
Ambient bits are enabled regardless of the inheritance
mask of the target binary. They are only restricted
by the bounding set.
History:
Linux capabilities have suffered from the problem that they are not
inheritable like unregular process characteristics under Unix. This is
behavior that is counter intuitive to the expected behavior of processes
in Unix.
In particular there has been recently software that controls NICs from user
space and provides IP stack like behavior also in user space (DPDK and RDMA
kernel API based implementations). Those typically need either capabilities
to allow raw network access or have to be run setsuid. There is scripting and
LD_PREFLOAD etc involved, arbitrary binaries may be run from those scripts
including those setting additional capabilites or requiring root access.
That does not go well with having file capabilities set that would enable
the capabilities. Maybe it would work if one would setup capabilities on
all executables but that would also defeat a secure design since these
binaries may only need those caps for certain situations. Ok setting the
inheritable flags on everything may also get one there (if there would not
be the issues with LD_PRELOAD, debugging etc etc).
The easy solution is to allow some capabilities be inherited like setsuid
is. We really prefer to use capabilities instead of setsuid (we want to
limit what damage someone can do after all!). Therefore we have been
running a patch like this in production for the last 6 years. At some
point it becomes tedious to run your own custom kernel so we would like
to have this functionality upstream.
See some of the earlier related discussions on the problems with capability
inheritance:
0. Recent surprise:
https://lkml.org/lkml/2014/1/21/175
1. Attempt to revise caps
http://www.madore.org/~david/linux/newcaps/
2. Problems of passing caps through exec
http://unix.stackexchange.com/questions/128394/passing-capabilities-through-exec
3. Problems of binding to privileged ports
http://stackoverflow.com/questions/413807/is-there-a-way-for-non-root-processes-to-bind-to-privileged-ports-1024-on-l
4. Reviving capabilities
http://lwn.net/Articles/199004/
There does not seem to be an alternative on the horizon. Some involved
in security development under Linux have even stated that they want to
rip out the whole thing and replace it. Its been a couple of years now
and we are still suffering from the capabilities mess. Let us just
fix it. Others have already done implementations like this like Nokia
for the N900.
This patch does not change the default behavior but it allows to set up
a list of capabilities via prctl that will enable regular
unix inheritance only for the selected group of capabilities.
With that it is then possible to do something trivial like setting
CAP_NET_RAW on an executable that can then allow that capability to
be inherited by others.
Lets have a look at a coding example of a wrapper that enables
a couple of capabilities:
------------------------------ ambient_test.c
/*
* Test program for the ambient capabilities
*
*
* Compile using:
* gcc -o ambient_test ambient_test.o
*
* This program must have the following capabilities to run properly:
* CAP_SETPCAP, CAP_NET_RAW, CAP_NET_ADMIN, CAP_SYS_NICE
*
* A command to equip this with the right caps is:
*
* setcap cap_setpcap,cap_net_raw,cap_net_admin,cap_sys_nice+eip ambient_test
*
* To get a shell with additional caps that can be inherited do:
*
* ./ambient_test /bin/bash
*
*/
#include <stdlib.h>
#include <stdio.h>
#include <errno.h>
#include <sys/prctl.h>
#include <linux/capability.h>
/* Defintion to be updated in the user space include files */
#define PR_CAP_AMBIENT 45
int main(int argc, char **argv)
{
int rc;
if (prctl(PR_CAP_AMBIENT, CAP_NET_RAW))
perror("Cannot set CAP_NET_RAW");
if (prctl(PR_CAP_AMBIENT, CAP_NET_ADMIN))
perror("Cannot set CAP_NET_ADMIN");
if (prctl(PR_CAP_AMBIENT, CAP_SYS_NICE))
perror("Cannot set CAP_SYS_NICE");
printf("Ambient_test forking shell\n");
if (execv(argv[1], argv + 1))
perror("Cannot exec");
return 0;
}
-------------------------------- ambient_test.c
Allows the inheritance of CAP_SYS_NICE, CAP_NET_RAW and CAP_NET_ADMIN.
With that device raw access is possible and also real time priorities
can be set from user space. This is a frequently needed set of
priviledged operations in HPC and HFT applications. User space
processes need to be able to directly access devices as well as
have full control over scheduling.
Signed-off-by: Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>
Index: linux/security/commoncap.c
===================================================================
--- linux.orig/security/commoncap.c 2015-02-25 13:43:06.929973954 -0600
+++ linux/security/commoncap.c 2015-02-26 16:10:02.347913397 -0600
@@ -347,15 +347,17 @@ static inline int bprm_caps_from_vfs_cap
*has_cap = true;
CAP_FOR_EACH_U32(i) {
+ __u32 ambient = current_cred()->cap_ambient.cap[i];
__u32 permitted = caps->permitted.cap[i];
__u32 inheritable = caps->inheritable.cap[i];
/*
- * pP' = (X & fP) | (pI & fI)
+ * pP' = (X & fP) | (pI & (fI | pA))
*/
new->cap_permitted.cap[i] =
(new->cap_bset.cap[i] & permitted) |
- (new->cap_inheritable.cap[i] & inheritable);
+ (new->cap_inheritable.cap[i] &
+ (inheritable | ambient));
if (permitted & ~new->cap_permitted.cap[i])
/* insufficient to execute correctly */
@@ -453,8 +455,18 @@ static int get_file_caps(struct linux_bi
if (rc == -EINVAL)
printk(KERN_NOTICE "%s: get_vfs_caps_from_disk returned %d for %s\n",
__func__, rc, bprm->filename);
- else if (rc == -ENODATA)
+ else if (rc == -ENODATA) {
rc = 0;
+ if (!cap_isclear(current_cred()->cap_ambient)) {
+ /*
+ * The ambient caps are permitted for
+ * files that have no caps
+ */
+ bprm->cred->cap_permitted =
+ current_cred()->cap_ambient;
+ *effective = true;
+ }
+ }
goto out;
}
@@ -549,9 +561,20 @@ skip:
new->sgid = new->fsgid = new->egid;
if (effective)
+ /*
+ * pE' = pP' & (fE | pA)
+ *
+ * fE is implicity all set if effective == true.
+ * Therefore the above reduces to
+ *
+ * pE' = pP'
+ */
new->cap_effective = new->cap_permitted;
else
cap_clear(new->cap_effective);
+
+ /* pA' = pA */
+ new->cap_ambient = old->cap_ambient;
bprm->cap_effective = effective;
/*
@@ -566,7 +589,7 @@ skip:
* Number 1 above might fail if you don't have a full bset, but I think
* that is interesting information to audit.
*/
- if (!cap_isclear(new->cap_effective)) {
+ if (!cap_issubset(new->cap_effective, new->cap_ambient)) {
if (!cap_issubset(CAP_FULL_SET, new->cap_effective) ||
!uid_eq(new->euid, root_uid) || !uid_eq(new->uid, root_uid) ||
issecure(SECURE_NOROOT)) {
@@ -598,7 +621,7 @@ int cap_bprm_secureexec(struct linux_bin
if (!uid_eq(cred->uid, root_uid)) {
if (bprm->cap_effective)
return 1;
- if (!cap_isclear(cred->cap_permitted))
+ if (!cap_issubset(cred->cap_permitted, cred->cap_ambient))
return 1;
}
@@ -933,6 +956,23 @@ int cap_task_prctl(int option, unsigned
new->securebits &= ~issecure_mask(SECURE_KEEP_CAPS);
return commit_creds(new);
+ case PR_CAP_AMBIENT:
+ if (!ns_capable(current_user_ns(), CAP_SETPCAP))
+ return -EPERM;
+
+ if (!cap_valid(arg2))
+ return -EINVAL;
+
+ if (!ns_capable(current_user_ns(), arg2))
+ return -EPERM;
+
+ new = prepare_creds();
+ if (arg3 == 0)
+ cap_lower(new->cap_ambient, arg2);
+ else
+ cap_raise(new->cap_ambient, arg2);
+ return commit_creds(new);
+
default:
/* No functionality available - continue with default */
return -ENOSYS;
Index: linux/include/linux/cred.h
===================================================================
--- linux.orig/include/linux/cred.h 2015-02-25 13:43:06.929973954 -0600
+++ linux/include/linux/cred.h 2015-02-25 13:43:06.925972078 -0600
@@ -122,6 +122,7 @@ struct cred {
kernel_cap_t cap_permitted; /* caps we're permitted */
kernel_cap_t cap_effective; /* caps we can actually use */
kernel_cap_t cap_bset; /* capability bounding set */
+ kernel_cap_t cap_ambient; /* Ambient capability set */
#ifdef CONFIG_KEYS
unsigned char jit_keyring; /* default keyring to attach requested
* keys to */
Index: linux/include/uapi/linux/prctl.h
===================================================================
--- linux.orig/include/uapi/linux/prctl.h 2015-02-25 13:43:06.929973954 -0600
+++ linux/include/uapi/linux/prctl.h 2015-02-25 13:43:06.925972078 -0600
@@ -185,4 +185,7 @@ struct prctl_mm_map {
#define PR_MPX_ENABLE_MANAGEMENT 43
#define PR_MPX_DISABLE_MANAGEMENT 44
+/* Control the ambient capability set */
+#define PR_CAP_AMBIENT 45
+
#endif /* _LINUX_PRCTL_H */
Index: linux/fs/proc/array.c
===================================================================
--- linux.orig/fs/proc/array.c 2015-02-25 13:43:06.929973954 -0600
+++ linux/fs/proc/array.c 2015-02-25 13:43:06.925972078 -0600
@@ -302,7 +302,8 @@ static void render_cap_t(struct seq_file
static inline void task_cap(struct seq_file *m, struct task_struct *p)
{
const struct cred *cred;
- kernel_cap_t cap_inheritable, cap_permitted, cap_effective, cap_bset;
+ kernel_cap_t cap_inheritable, cap_permitted, cap_effective,
+ cap_bset, cap_ambient;
rcu_read_lock();
cred = __task_cred(p);
@@ -310,12 +311,14 @@ static inline void task_cap(struct seq_f
cap_permitted = cred->cap_permitted;
cap_effective = cred->cap_effective;
cap_bset = cred->cap_bset;
+ cap_ambient = cred->cap_ambient;
rcu_read_unlock();
render_cap_t(m, "CapInh:\t", &cap_inheritable);
render_cap_t(m, "CapPrm:\t", &cap_permitted);
render_cap_t(m, "CapEff:\t", &cap_effective);
render_cap_t(m, "CapBnd:\t", &cap_bset);
+ render_cap_t(m, "CapAmb:\t", &cap_ambient);
}
static inline void task_seccomp(struct seq_file *m, struct task_struct *p)
^ permalink raw reply
* Re: [PATCH v2] coresight-stm: adding driver for CoreSight STM component
From: Rob Herring @ 2015-02-26 22:24 UTC (permalink / raw)
To: Mathieu Poirier, Will Deacon
Cc: linux-api@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Jonathan Corbet
In-Reply-To: <1424907152-18808-1-git-send-email-mathieu.poirier@linaro.org>
Adding Will D...
On Wed, Feb 25, 2015 at 5:32 PM, Mathieu Poirier
<mathieu.poirier@linaro.org> wrote:
> From: Pratik Patel <pratikp@codeaurora.org>
>
> This driver adds support for the STM CoreSight IP block,
> allowing any system compoment (HW or SW) to log and
> aggregate messages via a single entity.
>
> The STM exposes an application defined number of channels
> called stimulus port. Configuration is done using entries
> in sysfs and channels made available to userspace via devfs.
>
> Signed-off-by: Pratik Patel <pratikp@codeaurora.org>
> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> ---
> Changes for v2:
> - Fixed typo in struct stm_node documentation
> - Added CPU_32v3 to list of architecture STM can't work with
Is this because of no strd instr only?
> +#ifndef CONFIG_64BIT
> +static inline void __raw_writeq(u64 val, volatile void __iomem *addr)
> +{
> + asm volatile("strd %1, %0"
> + : "+Qo" (*(volatile u64 __force *)addr)
> + : "r" (val));
> +}
> +#undef writeq_relaxed
> +#define writeq_relaxed(v, c) __raw_writeq((__force u64) cpu_to_le64(v), c)
> +#endif
We really shouldn't do private implementation here. It there really
any reason not to allow readq/writeq generically for 32-bit or just
for arm32?
Rob
^ permalink raw reply
* Re: [PATCH] fork: report pid reservation failure properly
From: Andrew Morton @ 2015-02-26 22:49 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-api, Oleg Nesterov, Eric W. Biederman, Michael Kerrisk,
LKML
In-Reply-To: <20150223201701.GA28639@dhcp22.suse.cz>
On Mon, 23 Feb 2015 21:17:01 +0100 Michal Hocko <mhocko@suse.cz> wrote:
> ping on this one? Should I just resend (your way Andrew)? Or are there
> any objections to the patch as is.
Were Eric's concerns all addressed?
Oleg: wake up ;)
Overall it looks like a pretty minor issue?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox