* [PATCH v3 2/2] capabilities: Add a securebit to disable PR_CAP_AMBIENT_RAISE
From: Andy Lutomirski @ 2015-05-27 23:47 UTC (permalink / raw)
To: Serge Hallyn, Andrew Morton, James Morris
Cc: Jarkko Sakkinen, Andrew Lutomirski, Ted Ts'o,
Andrew G. Morgan, Linux API, Mimi Zohar, Michael Kerrisk,
Austin S Hemmelgarn, linux-security-module, Aaron Jones,
Serge Hallyn, LKML, Markku Savela, Kees Cook, Jonathan Corbet,
Christoph Lameter, Andy Lutomirski
In-Reply-To: <cover.1432770087.git.luto@kernel.org>
Per Andrew Morgan's request, add a securebit to allow admins to
disable PR_CAP_AMBIENT_RAISE. This securebit will prevent processes
from adding capabilities to their ambient set.
For simplicity, this disables PR_CAP_AMBIENT_RAISE entirely rather
than just disabling setting previously cleared bits.
Acked-By: Andrew G. Morgan <morgan@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: Serge Hallyn <serge.hallyn@canonical.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Aaron Jones <aaronmdjones@gmail.com>
CC: Ted Ts'o <tytso@mit.edu>
Cc: linux-security-module@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-api@vger.kernel.org
Cc: akpm@linuxfoundation.org
Cc: Andrew G. Morgan <morgan@kernel.org>
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: Austin S Hemmelgarn <ahferroin7@gmail.com>
Cc: Markku Savela <msa@moth.iki.fi>
Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
include/uapi/linux/securebits.h | 11 ++++++++++-
security/commoncap.c | 3 ++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/securebits.h b/include/uapi/linux/securebits.h
index 985aac9e6bf8..35ac35cef217 100644
--- a/include/uapi/linux/securebits.h
+++ b/include/uapi/linux/securebits.h
@@ -43,9 +43,18 @@
#define SECBIT_KEEP_CAPS (issecure_mask(SECURE_KEEP_CAPS))
#define SECBIT_KEEP_CAPS_LOCKED (issecure_mask(SECURE_KEEP_CAPS_LOCKED))
+/* When set, a process cannot add new capabilities to its ambient set. */
+#define SECURE_NO_CAP_AMBIENT_RAISE 6
+#define SECURE_NO_CAP_AMBIENT_RAISE_LOCKED 7 /* make bit-6 immutable */
+
+#define SECBIT_NO_CAP_AMBIENT_RAISE (issecure_mask(SECURE_NO_CAP_AMBIENT_RAISE))
+#define SECBIT_NO_CAP_AMBIENT_RAISE_LOCKED \
+ (issecure_mask(SECURE_NO_CAP_AMBIENT_RAISE_LOCKED))
+
#define SECURE_ALL_BITS (issecure_mask(SECURE_NOROOT) | \
issecure_mask(SECURE_NO_SETUID_FIXUP) | \
- issecure_mask(SECURE_KEEP_CAPS))
+ issecure_mask(SECURE_KEEP_CAPS) | \
+ issecure_mask(SECURE_NO_CAP_AMBIENT_RAISE))
#define SECURE_ALL_LOCKS (SECURE_ALL_BITS << 1)
#endif /* _UAPI_LINUX_SECUREBITS_H */
diff --git a/security/commoncap.c b/security/commoncap.c
index 835a7584f7ea..22b7b91c5eae 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -987,7 +987,8 @@ int cap_task_prctl(int option, unsigned long arg2, unsigned long arg3,
if (arg2 == PR_CAP_AMBIENT_RAISE &&
(!cap_raised(current_cred()->cap_permitted, arg3) ||
!cap_raised(current_cred()->cap_inheritable,
- arg3)))
+ arg3) ||
+ issecure(SECURE_NO_CAP_AMBIENT_RAISE)))
return -EPERM;
new = prepare_creds();
--
2.1.0
^ permalink raw reply related
* Re: [char-misc-next 04/11 V2] uuid: extract macros for assigning raw arrays
From: Greg KH @ 2015-05-28 0:13 UTC (permalink / raw)
To: Winkler, Tomas
Cc: arnd-r2nGTMty4D4@public.gmane.org, Stephen Rothwell,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <5B8DA87D05A7694D9FA63FD143655C1B3C4A3096-Jy8z56yoSI/jxeytcECX8bfspsVTdybXVpNB7YpNyf8@public.gmane.org>
On Wed, May 27, 2015 at 11:25:59PM +0000, Winkler, Tomas wrote:
>
>
> > -----Original Message-----
> > From: Greg KH [mailto:gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org]
> > Sent: Thursday, May 28, 2015 02:23
> > To: Winkler, Tomas
> > Cc: arnd-r2nGTMty4D4@public.gmane.org; Stephen Rothwell; linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Subject: Re: [char-misc-next 04/11 V2] uuid: extract macros for assigning raw
> > arrays
> >
> > On Wed, May 27, 2015 at 04:14:20PM -0700, Greg KH wrote:
> > > On Wed, May 27, 2015 at 05:42:22PM +0000, Winkler, Tomas wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Greg KH [mailto:gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org]
> > > > > Sent: Wednesday, May 27, 2015 20:29
> > > > > To: Winkler, Tomas
> > > > > Cc: arnd-r2nGTMty4D4@public.gmane.org; Stephen Rothwell; linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > > > > Subject: Re: [char-misc-next 04/11 V2] uuid: extract macros for assigning
> > raw
> > > > > arrays
> > > > >
> > > > > On Wed, May 27, 2015 at 05:24:01PM +0000, Winkler, Tomas wrote:
> > > > > >
> > > > > > >
> > > > > > > On Wed, May 27, 2015 at 06:42:13PM +0300, Tomas Winkler wrote:
> > > > > > > > In order for mei client devices to use device id based on uuid we
> > > > > > > > have to use common types between user space (file2alias.c).
> > > > > > > > Similarly to vmbus, mei uses raw 16 byte array for that.
> > > > > > > > To leverage on existing infrastructure around uuid_le type
> > > > > > > > defined in uuid.h we add helper macros to handle conversions
> > between
> > > > > > > > raw 16 byte array and uuid_{le,be} types.
> > > > > > >
> > > > > > > You aren't adding a helper macro, you are just redefining the existing
> > > > > > > macros using a different one.
> > > > > >
> > > > > > Not exactly I'm using both the one I've added for device ids and the old
> > one for
> > > > > all the other flows.
> > > > > >
> > > > > > But I can't see why this is needed, what
> > > > > > > does this solve that vmbus and other uses of the existing macros don't
> > > > > > > need? In other words, what makes mei so special that it needs a
> > "lower"
> > > > > > > level macro than every other subsystem?
> > > > > >
> > > > > > It's not special there is actually a lot of code duplication around uuid
> > handling
> > > > > > every subsystem is using their own macros but it can be consolidated
> > around
> > > > > uuid.h
> > > > > >
> > > > > > So vmbus can use that
> > > > > > Instead of
> > > > > > /*
> > > > > > * Network GUID
> > > > > > * {f8615163-df3e-46c5-913f-f2d2f965ed0e}
> > > > > > */
> > > > > > #define HV_NIC_GUID \
> > > > > > .guid = { \
> > > > > > 0x63, 0x51, 0x61, 0xf8, 0x3e, 0xdf, 0xc5, 0x46, \
> > > > > > 0x91, 0x3f, 0xf2, 0xd2, 0xf9, 0x65, 0xed, 0x0e \
> > > > > > }
> > > > > >
> > > > > > The can use the new macro to make it more readable, something in spirit
> > of:
> > > > > >
> > > > > > #define HV_NIC_GUID __UUID_LE(f8615163-df3e-46c5-913f-
> > f2d2f965ed0e)
> > > > >
> > > > > Why the "__" usage here? That signifies a "private" namespace, why add
> > > > > that to the user visible header files?
> > > >
> > > > I take any other suggestion for macro names.
> > > > Not sure how I would reuse the macros if I don't export them both,
> > > > second this can be used also by user space.
> > >
> > > But it's not needed at all.
> > >
> > > Below is a patch on top of my current tree that makes this patch not
> > > needed. Any objection to me just applying it instead?
> > >
> > > > > And are you going to send patches for vmbus and other drivers to fix
> > > > > everything up to use these new macros? Someone has to...
> > > >
> > > > Can be done but I cannot test their code and now I'm busy with splitting the
> > big bus patch :)
> > >
> > > Ok, that means no one is ever going to do that work, so it's not a valid
> > > reason to accept such a change. I prefer the patch below.
> >
> > Oops, that didn't build, I forgot one change in the mei core (getting
> > rid of two casts.) Try this one instead.
> >
> > thanks,
> >
> > greg k-h
> >
> >
> > diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
> > index de8fd089a8a4..dd52f224027e 100644
> > --- a/drivers/misc/mei/bus.c
> > +++ b/drivers/misc/mei/bus.c
> > @@ -54,9 +54,9 @@ static int mei_cl_device_match(struct device *dev, struct
> > device_driver *drv)
> >
> > id = driver->id_table;
> >
> > - while (uuid_le_cmp(NULL_UUID_LE, uuid_le_cast(id->uuid))) {
> > + while (uuid_le_cmp(NULL_UUID_LE, id->uuid)) {
> >
> > - if (!uuid_le_cmp(*uuid, uuid_le_cast(id->uuid))) {
> > + if (!uuid_le_cmp(*uuid, id->uuid)) {
> > if (id->name[0]) {
> > if (!strncmp(name, id->name, sizeof(id->name)))
> > return 1;
>
> You can also drop the uuid_le_cast function
Odd that gcc didn't complain about that. Now removed, I'll resend it in
"official" form.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] mei: fix up uuid matching
From: Greg KH @ 2015-05-28 0:17 UTC (permalink / raw)
To: Winkler, Tomas
Cc: Samuel Ortiz, arnd@arndb.de, Stephen Rothwell,
linux-api@vger.kernel.org, linux-kernel
In-Reply-To: <5B8DA87D05A7694D9FA63FD143655C1B3C4A3096@hasmsx109.ger.corp.intel.com>
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A previous commit, c93b76b34b4d ("mei: bus: report also uuid in module
alias") caused a build error as I missed applying a needed patch to add
some macros to uapi/linux/uuid.h. Instead of those additional macros,
change the mei code to use the existing uuid structure directly.
Fixes: c93b76b34b4d
Cc: Tomas Winkler <tomas.winkler@intel.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index de8fd089a8a4..357b6ae4d207 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -30,11 +30,6 @@
#define to_mei_cl_driver(d) container_of(d, struct mei_cl_driver, driver)
#define to_mei_cl_device(d) container_of(d, struct mei_cl_device, dev)
-static inline uuid_le uuid_le_cast(const __u8 uuid[16])
-{
- return *(uuid_le *)uuid;
-}
-
static int mei_cl_device_match(struct device *dev, struct device_driver *drv)
{
struct mei_cl_device *device = to_mei_cl_device(dev);
@@ -54,9 +49,9 @@ static int mei_cl_device_match(struct device *dev, struct device_driver *drv)
id = driver->id_table;
- while (uuid_le_cmp(NULL_UUID_LE, uuid_le_cast(id->uuid))) {
+ while (uuid_le_cmp(NULL_UUID_LE, id->uuid)) {
- if (!uuid_le_cmp(*uuid, uuid_le_cast(id->uuid))) {
+ if (!uuid_le_cmp(*uuid, id->uuid)) {
if (id->name[0]) {
if (!strncmp(name, id->name, sizeof(id->name)))
return 1;
diff --git a/drivers/nfc/mei_phy.h b/drivers/nfc/mei_phy.h
index a51f8f2685cc..fbfa3e61738f 100644
--- a/drivers/nfc/mei_phy.h
+++ b/drivers/nfc/mei_phy.h
@@ -5,7 +5,7 @@
#include <net/nfc/hci.h>
#include <linux/uuid.h>
-#define MEI_NFC_UUID __UUID_LE(0x0bb17a78, 0x2a8e, 0x4c50, \
+#define MEI_NFC_UUID UUID_LE(0x0bb17a78, 0x2a8e, 0x4c50, \
0x94, 0xd4, 0x50, 0x26, 0x67, 0x23, 0x77, 0x5c)
#define MEI_NFC_HEADER_SIZE 10
#define MEI_NFC_MAX_HCI_PAYLOAD 300
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 2d2b2b571d61..048c270822f9 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -614,7 +614,7 @@ struct ipack_device_id {
*/
struct mei_cl_device_id {
char name[MEI_CL_NAME_SIZE];
- __u8 uuid[16];
+ uuid_le uuid;
kernel_ulong_t driver_info;
};
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 62c517f4b592..718b2a29bd43 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -34,6 +34,9 @@ typedef Elf64_Addr kernel_ulong_t;
typedef uint32_t __u32;
typedef uint16_t __u16;
typedef unsigned char __u8;
+typedef struct {
+ __u8 b[16];
+} uuid_le;
/* Big exception to the "don't include kernel headers into userspace, which
* even potentially has different endianness and word sizes, since
@@ -131,13 +134,13 @@ static inline void add_wildcard(char *str)
strcat(str + len, "*");
}
-static inline void add_uuid(char *str, __u8 uuid[16])
+static inline void add_uuid(char *str, uuid_le uuid)
{
int len = strlen(str);
int i;
for (i = 0; i < 16; i++)
- sprintf(str + len + (i << 1), "%02x", uuid[i]);
+ sprintf(str + len + (i << 1), "%02x", uuid.b[i]);
}
/**
^ permalink raw reply related
* Re: [PATCH v6 1/8] virtio: introduce virtio_is_little_endian() helper
From: David Gibson @ 2015-05-28 4:57 UTC (permalink / raw)
To: Greg Kurz
Cc: Rusty Russell, Michael S. Tsirkin, Thomas Huth,
kvm-u79uwXL29TY76Z2rM5mHXA, linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Cornelia Huck
In-Reply-To: <20150424122423.19156.34555.stgit-GiB8zCg7hOfDOqzlkpFKJg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 429 bytes --]
On Fri, Apr 24, 2015 at 02:24:27PM +0200, Greg Kurz wrote:
> Signed-off-by: Greg Kurz <gkurz-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Reviewed-by: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v6 2/8] tun: add tun_is_little_endian() helper
From: David Gibson @ 2015-05-28 4:57 UTC (permalink / raw)
To: Greg Kurz
Cc: Rusty Russell, Michael S. Tsirkin, Thomas Huth,
kvm-u79uwXL29TY76Z2rM5mHXA, linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Cornelia Huck
In-Reply-To: <20150424122435.19156.18985.stgit-GiB8zCg7hOfDOqzlkpFKJg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 429 bytes --]
On Fri, Apr 24, 2015 at 02:24:38PM +0200, Greg Kurz wrote:
> Signed-off-by: Greg Kurz <gkurz-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Reviewed-by: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v6 3/8] macvtap: introduce macvtap_is_little_endian() helper
From: David Gibson @ 2015-05-28 4:58 UTC (permalink / raw)
To: Greg Kurz
Cc: Rusty Russell, Michael S. Tsirkin, Thomas Huth, kvm, linux-api,
linux-kernel, virtualization, Cornelia Huck
In-Reply-To: <20150424122446.19156.93123.stgit@bahia.local>
[-- Attachment #1: Type: text/plain, Size: 370 bytes --]
On Fri, Apr 24, 2015 at 02:24:48PM +0200, Greg Kurz wrote:
> Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v6 4/8] vringh: introduce vringh_is_little_endian() helper
From: David Gibson @ 2015-05-28 4:58 UTC (permalink / raw)
To: Greg Kurz
Cc: Rusty Russell, Michael S. Tsirkin, Thomas Huth, kvm, linux-api,
linux-kernel, virtualization, Cornelia Huck
In-Reply-To: <20150424122456.19156.56558.stgit@bahia.local>
[-- Attachment #1: Type: text/plain, Size: 370 bytes --]
On Fri, Apr 24, 2015 at 02:24:58PM +0200, Greg Kurz wrote:
> Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v6 5/8] vhost: introduce vhost_is_little_endian() helper
From: David Gibson @ 2015-05-28 4:58 UTC (permalink / raw)
To: Greg Kurz
Cc: Rusty Russell, Michael S. Tsirkin, Thomas Huth, kvm, linux-api,
linux-kernel, virtualization, Cornelia Huck
In-Reply-To: <20150424122507.19156.55673.stgit@bahia.local>
[-- Attachment #1: Type: text/plain, Size: 370 bytes --]
On Fri, Apr 24, 2015 at 02:25:12PM +0200, Greg Kurz wrote:
> Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v6 6/8] virtio: add explicit big-endian support to memory accessors
From: David Gibson @ 2015-05-28 4:59 UTC (permalink / raw)
To: Greg Kurz
Cc: Thomas Huth, kvm, Michael S. Tsirkin, linux-api, linux-kernel,
virtualization
In-Reply-To: <20150424122521.19156.65586.stgit@bahia.local>
[-- Attachment #1.1: Type: text/plain, Size: 949 bytes --]
On Fri, Apr 24, 2015 at 02:26:24PM +0200, Greg Kurz wrote:
> The current memory accessors logic is:
> - little endian if little_endian
> - native endian (i.e. no byteswap) if !little_endian
>
> If we want to fully support cross-endian vhost, we also need to be
> able to convert to big endian.
>
> Instead of changing the little_endian argument to some 3-value enum, this
> patch changes the logic to:
> - little endian if little_endian
> - big endian if !little_endian
>
> The native endian case is handled by all users with a trivial helper. This
> patch doesn't change any functionality, nor it does add overhead.
>
> Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v6 7/8] vhost: cross-endian support for legacy devices
From: David Gibson @ 2015-05-28 4:59 UTC (permalink / raw)
To: Greg Kurz
Cc: Thomas Huth, kvm, Michael S. Tsirkin, linux-api, linux-kernel,
virtualization
In-Reply-To: <20150424122632.19156.88058.stgit@bahia.local>
[-- Attachment #1.1: Type: text/plain, Size: 1194 bytes --]
On Fri, Apr 24, 2015 at 02:27:24PM +0200, Greg Kurz wrote:
> This patch brings cross-endian support to vhost when used to implement
> legacy virtio devices. Since it is a relatively rare situation, the
> feature availability is controlled by a kernel config option (not set
> by default).
>
> The vq->is_le boolean field is added to cache the endianness to be
> used for ring accesses. It defaults to native endian, as expected
> by legacy virtio devices. When the ring gets active, we force little
> endian if the device is modern. When the ring is deactivated, we
> revert to the native endian default.
>
> If cross-endian was compiled in, a vq->user_be boolean field is added
> so that userspace may request a specific endianness. This field is
> used to override the default when activating the ring of a legacy
> device. It has no effect on modern devices.
>
> Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v6 8/8] macvtap/tun: cross-endian support for little-endian hosts
From: David Gibson @ 2015-05-28 4:59 UTC (permalink / raw)
To: Greg Kurz
Cc: Thomas Huth, kvm, Michael S. Tsirkin, linux-api, linux-kernel,
virtualization
In-Reply-To: <20150424122732.19156.77709.stgit@bahia.local>
[-- Attachment #1.1: Type: text/plain, Size: 935 bytes --]
On Fri, Apr 24, 2015 at 02:50:36PM +0200, Greg Kurz wrote:
> The VNET_LE flag was introduced to fix accesses to virtio 1.0 headers
> that are always little-endian. It can also be used to handle the special
> case of a legacy little-endian device implemented by a big-endian host.
>
> Let's add a flag and ioctls for big-endian devices as well. If both flags
> are set, little-endian wins.
>
> Since this is isn't a common usecase, the feature is controlled by a kernel
> config option (not set by default).
>
> Both macvtap and tun are covered by this patch since they share the same
> API with userland.
>
> Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [CFT][PATCH 00/10] Making new mounts of proc and sysfs as safe as bind mounts (take 2)
From: Serge Hallyn @ 2015-05-28 14:08 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Eric W. Biederman, Seth Forshee, Linux API, Linux Containers,
Greg Kroah-Hartman, Kenton Varda, Michael Kerrisk-manpages,
Richard Weinberger, Linux FS Devel, Tejun Heo
In-Reply-To: <CALCETrUhXBR5WQ6gXr9KzGc4=7tph7kzopY29Hug4g+FhOzEKg@mail.gmail.com>
Quoting Andy Lutomirski (luto@amacapital.net):
> On Fri, May 22, 2015 at 10:39 AM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
> > I had hoped to get some Tested-By's on that patch series.
>
> Sorry, I've been totally swamped.
>
> I suspect that Sandstorm is okay, but I haven't had a chance to test
> it for real. Sandstorm makes only limited use of proc and sysfs in
> containers, but I'll see if I can test it for real this weekend.
Testing this with unprivileged containers, I get
lxc-start: conf.c: lxc_mount_auto_mounts: 808 Operation not permitted - error mounting sysfs on /usr/lib/x86_64-linux-gnu/lxc/sys/devices/virtual/net flags 0
> > Oh well. The fundamentals seem sound, and my biggest concern the
> > implicit nodev does not apply so I will put this patchset in linux-next
> > and aim at merging it in the next merge window. Hopefully that will
> > leave enough time catch problems.
> >
> > Eric
> >
>
>
>
> --
> Andy Lutomirski
> AMA Capital Management, LLC
> _______________________________________________
> Containers mailing list
> Containers@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply
* Re: [PATCH] mei: fix up uuid matching
From: Stephen Rothwell @ 2015-05-28 14:40 UTC (permalink / raw)
To: Greg KH
Cc: Winkler, Tomas, Samuel Ortiz, arnd-r2nGTMty4D4@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150528001727.GB2033-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]
Hi Greg,
On Wed, 27 May 2015 17:17:27 -0700 Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
>
> From: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
>
> A previous commit, c93b76b34b4d ("mei: bus: report also uuid in module
> alias") caused a build error as I missed applying a needed patch to add
> some macros to uapi/linux/uuid.h. Instead of those additional macros,
> change the mei code to use the existing uuid structure directly.
>
> Fixes: c93b76b34b4d
> Cc: Tomas Winkler <tomas.winkler-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Reported-by: Stephen Rothwell <sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
I added this to linux-next today (well, yesterday now :-)).
--
Cheers,
Stephen Rothwell sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [CFT][PATCH 00/10] Making new mounts of proc and sysfs as safe as bind mounts (take 2)
From: Eric W. Biederman @ 2015-05-28 15:03 UTC (permalink / raw)
To: Serge Hallyn
Cc: Andy Lutomirski, Seth Forshee, Linux API, Linux Containers,
Greg Kroah-Hartman, Kenton Varda, Michael Kerrisk-manpages,
Richard Weinberger, Linux FS Devel, Tejun Heo
In-Reply-To: <20150528140839.GD28842@ubuntumail>
Serge Hallyn <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org> writes:
> Quoting Andy Lutomirski (luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org):
>> On Fri, May 22, 2015 at 10:39 AM, Eric W. Biederman
>> <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>> > I had hoped to get some Tested-By's on that patch series.
>>
>> Sorry, I've been totally swamped.
>>
>> I suspect that Sandstorm is okay, but I haven't had a chance to test
>> it for real. Sandstorm makes only limited use of proc and sysfs in
>> containers, but I'll see if I can test it for real this weekend.
>
> Testing this with unprivileged containers, I get
>
> lxc-start: conf.c: lxc_mount_auto_mounts: 808 Operation not permitted
> - error mounting sysfs on
> /usr/lib/x86_64-linux-gnu/lxc/sys/devices/virtual/net flags 0
Grr.. I was afraid this would break something. :(
Looking at my system I see that sysfs is currently mounted
"nosuid,nodev,noexec"
Looking at the lxc-start code I don't see it as including any of those
mount options. In practice for sysfs I think those options are
meaningless (as there should be no devices and nothing executable in
sysfs) but I can understand the past concerns with chmod on virtual
filesystems that would incline people to use them, so I think the
failure is reporting a legitimate security issue in the lxc userspace
code where the the unprivileged code is currently attempting to give
greater access to sysfs than was given by the original mount of sysfs.
As nosuid,nodev,noexec should not impair the operation of sysfs
operation it looks like you can always specify those options and just
make this concern go away.
Something like the untested patch below I expect.
diff --git a/src/lxc/conf.c b/src/lxc/conf.c
index 9870455b3cae..d9ccd03afe68 100644
--- a/src/lxc/conf.c
+++ b/src/lxc/conf.c
@@ -770,8 +770,8 @@ static int lxc_mount_auto_mounts(struct lxc_conf *conf, int flags, struct lxc_ha
{ LXC_AUTO_PROC_MASK, LXC_AUTO_PROC_MIXED, "%r/proc/sysrq-trigger", "%r/proc/sysrq-trigger", NULL, MS_BIND, NULL },
{ LXC_AUTO_PROC_MASK, LXC_AUTO_PROC_MIXED, NULL, "%r/proc/sysrq-trigger", NULL, MS_REMOUNT|MS_BIND|MS_RDONLY, NULL },
{ LXC_AUTO_PROC_MASK, LXC_AUTO_PROC_RW, "proc", "%r/proc", "proc", MS_NODEV|MS_NOEXEC|MS_NOSUID, NULL },
- { LXC_AUTO_SYS_MASK, LXC_AUTO_SYS_RW, "sysfs", "%r/sys", "sysfs", 0, NULL },
- { LXC_AUTO_SYS_MASK, LXC_AUTO_SYS_RO, "sysfs", "%r/sys", "sysfs", MS_RDONLY, NULL },
+ { LXC_AUTO_SYS_MASK, LXC_AUTO_SYS_RW, "sysfs", "%r/sys", "sysfs", MS_NODEV|MS_NOEXEC|MS_NOSUID, NULL },
+ { LXC_AUTO_SYS_MASK, LXC_AUTO_SYS_RO, "sysfs", "%r/sys", "sysfs", MS_NODEV|MS_NOEXEC|MS_NOSUID|MS_RDONLY, NULL },
{ LXC_AUTO_SYS_MASK, LXC_AUTO_SYS_MIXED, "sysfs", "%r/sys", "sysfs", MS_NODEV|MS_NOEXEC|MS_NOSUID, NULL },
{ LXC_AUTO_SYS_MASK, LXC_AUTO_SYS_MIXED, "%r/sys", "%r/sys", NULL, MS_BIND, NULL },
{ LXC_AUTO_SYS_MASK, LXC_AUTO_SYS_MIXED, NULL, "%r/sys", NULL, MS_REMOUNT|MS_BIND|MS_RDONLY, NULL },
Alternately you can read the flags off of the original mount of proc or sysfs.
diff --git a/src/lxc/conf.c b/src/lxc/conf.c
index 9870455b3cae..50ea49973e80 100644
--- a/src/lxc/conf.c
+++ b/src/lxc/conf.c
@@ -712,7 +712,9 @@ static unsigned long add_required_remount_flags(const char *s, const char *d,
struct statvfs sb;
unsigned long required_flags = 0;
- if (!(flags & MS_REMOUNT))
+ if (!(flags & MS_REMOUNT) &&
+ (strcmp(s, "proc") != 0) &&
+ (strcmp(s, "sysfs") != 0))
return flags;
if (!s)
Eric
^ permalink raw reply related
* Re: [CFT][PATCH 00/10] Making new mounts of proc and sysfs as safe as bind mounts (take 2)
From: Andy Lutomirski @ 2015-05-28 17:33 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Serge Hallyn, Seth Forshee, Linux API, Linux Containers,
Greg Kroah-Hartman, Kenton Varda, Michael Kerrisk-manpages,
Richard Weinberger, Linux FS Devel, Tejun Heo
In-Reply-To: <87lhg8pwvz.fsf@x220.int.ebiederm.org>
On Thu, May 28, 2015 at 8:03 AM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Serge Hallyn <serge.hallyn@ubuntu.com> writes:
>
>> Quoting Andy Lutomirski (luto@amacapital.net):
>>> On Fri, May 22, 2015 at 10:39 AM, Eric W. Biederman
>>> <ebiederm@xmission.com> wrote:
>>> > I had hoped to get some Tested-By's on that patch series.
>>>
>>> Sorry, I've been totally swamped.
>>>
>>> I suspect that Sandstorm is okay, but I haven't had a chance to test
>>> it for real. Sandstorm makes only limited use of proc and sysfs in
>>> containers, but I'll see if I can test it for real this weekend.
>>
>> Testing this with unprivileged containers, I get
>>
>> lxc-start: conf.c: lxc_mount_auto_mounts: 808 Operation not permitted
>> - error mounting sysfs on
>> /usr/lib/x86_64-linux-gnu/lxc/sys/devices/virtual/net flags 0
>
> Grr.. I was afraid this would break something. :(
>
> Looking at my system I see that sysfs is currently mounted
> "nosuid,nodev,noexec"
>
> Looking at the lxc-start code I don't see it as including any of those
> mount options. In practice for sysfs I think those options are
> meaningless (as there should be no devices and nothing executable in
> sysfs) but I can understand the past concerns with chmod on virtual
> filesystems that would incline people to use them, so I think the
> failure is reporting a legitimate security issue in the lxc userspace
> code where the the unprivileged code is currently attempting to give
> greater access to sysfs than was given by the original mount of sysfs.
>
> As nosuid,nodev,noexec should not impair the operation of sysfs
> operation it looks like you can always specify those options and just
> make this concern go away.
Linus is pretty strict about not breaking the ABI, and this definitely
counts as breaking the ABI. There's an exception for security issues,
but is there really a security issue here? That is, do we lose
anything important if we just drop the offending part of the patch
set? As you've said, there shouldn't be sensitive device nodes,
executables, or setuid files in proc or sysfs in the first place.
--Andy
^ permalink raw reply
* Re: [CFT][PATCH 00/10] Making new mounts of proc and sysfs as safe as bind mounts (take 2)
From: Kenton Varda @ 2015-05-28 18:20 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Richard Weinberger, Greg Kroah-Hartman, Linux Containers,
Serge Hallyn, Seth Forshee, Eric W. Biederman, Linux API,
Linux FS Devel, Tejun Heo, Michael Kerrisk-manpages
In-Reply-To: <CALCETrXXax28s9kMTQ-zDx0MttQWG4rg2y-oz3bSGiumSL=3sg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, May 28, 2015 at 10:33 AM, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> wrote:
> On Thu, May 28, 2015 at 8:03 AM, Eric W. Biederman
> <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>> Serge Hallyn <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org> writes:
>>
>>> Quoting Andy Lutomirski (luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org):
>>>> On Fri, May 22, 2015 at 10:39 AM, Eric W. Biederman
>>>> <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>>>> > I had hoped to get some Tested-By's on that patch series.
>>>>
>>>> Sorry, I've been totally swamped.
>>>>
>>>> I suspect that Sandstorm is okay, but I haven't had a chance to test
>>>> it for real. Sandstorm makes only limited use of proc and sysfs in
>>>> containers, but I'll see if I can test it for real this weekend.
>>>
>>> Testing this with unprivileged containers, I get
>>>
>>> lxc-start: conf.c: lxc_mount_auto_mounts: 808 Operation not permitted
>>> - error mounting sysfs on
>>> /usr/lib/x86_64-linux-gnu/lxc/sys/devices/virtual/net flags 0
>>
>> Grr.. I was afraid this would break something. :(
>>
>> Looking at my system I see that sysfs is currently mounted
>> "nosuid,nodev,noexec"
>>
>> Looking at the lxc-start code I don't see it as including any of those
>> mount options. In practice for sysfs I think those options are
>> meaningless (as there should be no devices and nothing executable in
>> sysfs) but I can understand the past concerns with chmod on virtual
>> filesystems that would incline people to use them, so I think the
>> failure is reporting a legitimate security issue in the lxc userspace
>> code where the the unprivileged code is currently attempting to give
>> greater access to sysfs than was given by the original mount of sysfs.
>>
>> As nosuid,nodev,noexec should not impair the operation of sysfs
>> operation it looks like you can always specify those options and just
>> make this concern go away.
>
> Linus is pretty strict about not breaking the ABI, and this definitely
> counts as breaking the ABI. There's an exception for security issues,
> but is there really a security issue here? That is, do we lose
> anything important if we just drop the offending part of the patch
> set? As you've said, there shouldn't be sensitive device nodes,
> executables, or setuid files in proc or sysfs in the first place.
Speaking as a user of the mount() interfaces, I really think it would
be less confusing overall if mount() simply ignored the requested
flags when the caller doesn't have a choice. That is, in cases where
mount() currently fails with EPERM when not given, say, MS_NOSUID, it
should instead just pretend the caller actually set MS_NOSUID and go
ahead with a nosuid mount. Or put another way, the absence of
MS_NOSUID should not be interpreted as "remove the nosuid bit" but
rather "don't set the nosuid bit if not required".
Consider:
- This approach will actually cause lxc to have the correct behavior,
without any changes to lxc. I suspect that this generalizes: In the
vast majority of cases, when users have failed to set MS_NOSUID, it's
not because they are explicitly requesting that the flag be turned
off, but rather that they didn't know it mattered.
- If a user actually *does* expect not passing MS_NOSUID to remove the
nosuid bit, and they find instead that the nosuid bit is silently
kept, I don't think they'll be confused: it's pretty obvious in
context that this must be for security reasons.
- On the other hand, the current behavior *is* very confusing: mount()
returns EPERM because of rules the caller probably doesn't know
anything about. I've spent a fair amount of time frustrated by this
sort of thing.
-Kenton
^ permalink raw reply
* Re: [CFT][PATCH 00/10] Making new mounts of proc and sysfs as safe as bind mounts (take 2)
From: Eric W. Biederman @ 2015-05-28 19:14 UTC (permalink / raw)
To: Kenton Varda
Cc: Andy Lutomirski, Serge Hallyn, Seth Forshee, Linux API,
Linux Containers, Greg Kroah-Hartman, Michael Kerrisk-manpages,
Richard Weinberger, Linux FS Devel, Tejun Heo
In-Reply-To: <CAOP=4wid+N_80iyPpiVMN96_fuHZZRGtYQ6AOPn-HFBj2H6Vgg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Kenton Varda <kenton-AuYgBwuPrUQTaNkGU808tA@public.gmane.org> writes:
> On Thu, May 28, 2015 at 10:33 AM, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> wrote:
>> On Thu, May 28, 2015 at 8:03 AM, Eric W. Biederman
>> <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>>> Serge Hallyn <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org> writes:
>>>
>>>> Quoting Andy Lutomirski (luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org):
>>>>> On Fri, May 22, 2015 at 10:39 AM, Eric W. Biederman
>>>>> <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>>>>> > I had hoped to get some Tested-By's on that patch series.
>>>>>
>>>>> Sorry, I've been totally swamped.
>>>>>
>>>>> I suspect that Sandstorm is okay, but I haven't had a chance to test
>>>>> it for real. Sandstorm makes only limited use of proc and sysfs in
>>>>> containers, but I'll see if I can test it for real this weekend.
>>>>
>>>> Testing this with unprivileged containers, I get
>>>>
>>>> lxc-start: conf.c: lxc_mount_auto_mounts: 808 Operation not permitted
>>>> - error mounting sysfs on
>>>> /usr/lib/x86_64-linux-gnu/lxc/sys/devices/virtual/net flags 0
>>>
>>> Grr.. I was afraid this would break something. :(
>>>
>>> Looking at my system I see that sysfs is currently mounted
>>> "nosuid,nodev,noexec"
>>>
>>> Looking at the lxc-start code I don't see it as including any of those
>>> mount options. In practice for sysfs I think those options are
>>> meaningless (as there should be no devices and nothing executable in
>>> sysfs) but I can understand the past concerns with chmod on virtual
>>> filesystems that would incline people to use them, so I think the
>>> failure is reporting a legitimate security issue in the lxc userspace
>>> code where the the unprivileged code is currently attempting to give
>>> greater access to sysfs than was given by the original mount of sysfs.
>>>
>>> As nosuid,nodev,noexec should not impair the operation of sysfs
>>> operation it looks like you can always specify those options and just
>>> make this concern go away.
>>
>> Linus is pretty strict about not breaking the ABI, and this definitely
>> counts as breaking the ABI. There's an exception for security issues,
>> but is there really a security issue here? That is, do we lose
>> anything important if we just drop the offending part of the patch
>> set? As you've said, there shouldn't be sensitive device nodes,
>> executables, or setuid files in proc or sysfs in the first place.
We do need to enforce retaining the existing mount flags one way or
another. Where this really matters is with MS_RDONLY. We don't want
any old user to be able to mount /proc read-write when root mounted it
read-only. There is a very real attack vector there. That attack
almost works in docker container today and is avoided simply because
docker mounts over a few files on proc.
Which leads to the second side of the reason for these changes. I am
fixing a very small but long standing ABI break. That is in some small
ways I broke some sandboxes and when I realized they were broken I could
not imagine think how to fix the code until now.
It is the goal that user namespaces don't introduce anything for people
to worry about security wise more than simply the ability to execute
more kernel code. So at least when the kernel implementation is correct
developers of existing applications simply do not need care. Sadly we are
not quite there yet.
> Speaking as a user of the mount() interfaces, I really think it would
> be less confusing overall if mount() simply ignored the requested
> flags when the caller doesn't have a choice. That is, in cases where
> mount() currently fails with EPERM when not given, say, MS_NOSUID, it
> should instead just pretend the caller actually set MS_NOSUID and go
> ahead with a nosuid mount. Or put another way, the absence of
> MS_NOSUID should not be interpreted as "remove the nosuid bit" but
> rather "don't set the nosuid bit if not required".
I am conflicted. Implicits are nice but confusing. If we can do
something reliable and robust and maintainable here that is truly worth
the cost I am all for it.
If I mount proc read-write I likely want to be able to write to proc
files, and I will be much happier if the mount fails than if a bazillion
syscalls later something else fails when it tries to write to proc.
> Consider:
>
> - This approach will actually cause lxc to have the correct behavior,
> without any changes to lxc. I suspect that this generalizes: In the
> vast majority of cases, when users have failed to set MS_NOSUID, it's
> not because they are explicitly requesting that the flag be turned
> off, but rather that they didn't know it mattered.
>
> - If a user actually *does* expect not passing MS_NOSUID to remove the
> nosuid bit, and they find instead that the nosuid bit is silently
> kept, I don't think they'll be confused: it's pretty obvious in
> context that this must be for security reasons.
>
> - On the other hand, the current behavior *is* very confusing: mount()
> returns EPERM because of rules the caller probably doesn't know
> anything about. I've spent a fair amount of time frustrated by this
> sort of thing.
My sympathies. This all started with an oh crap we overlooked corner
case X and it actually matters, and the fixes were quite likely a little
bit hasty. The only case where this really shows up is remount insode
of a user namespace of filesystems that were mounted outside of the user
namespace is where this all actually matters. And mounting new
instances of proc and sysfs wind up being weird instances of that
nonsense.
But please someone test sandstorm with this patchset and tell me if it
bites you. The impetus to find a way to avoid breaking slightly buggy
userspace is higher if it is more than unprivileged lxc that is broken.
Eric
^ permalink raw reply
* Re: [CFT][PATCH 00/10] Making new mounts of proc and sysfs as safe as bind mounts (take 2)
From: Richard Weinberger @ 2015-05-28 19:36 UTC (permalink / raw)
To: Serge Hallyn, Andy Lutomirski
Cc: Eric W. Biederman, Seth Forshee, Linux API, Linux Containers,
Greg Kroah-Hartman, Kenton Varda, Michael Kerrisk-manpages,
Linux FS Devel, Tejun Heo
In-Reply-To: <20150528140839.GD28842@ubuntumail>
Am 28.05.2015 um 16:08 schrieb Serge Hallyn:
> Quoting Andy Lutomirski (luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org):
>> On Fri, May 22, 2015 at 10:39 AM, Eric W. Biederman
>> <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>>> I had hoped to get some Tested-By's on that patch series.
>>
>> Sorry, I've been totally swamped.
>>
>> I suspect that Sandstorm is okay, but I haven't had a chance to test
>> it for real. Sandstorm makes only limited use of proc and sysfs in
>> containers, but I'll see if I can test it for real this weekend.
>
> Testing this with unprivileged containers, I get
>
> lxc-start: conf.c: lxc_mount_auto_mounts: 808 Operation not permitted - error mounting sysfs on /usr/lib/x86_64-linux-gnu/lxc/sys/devices/virtual/net flags 0
>
FWIW, it breaks also libvirt-lxc:
Error: internal error: guest failed to start: Failed to re-mount /proc/sys on /proc/sys flags=1021: Operation not permitted
Thanks,
//richard
^ permalink raw reply
* Re: [CFT][PATCH 00/10] Making new mounts of proc and sysfs as safe as bind mounts (take 2)
From: Eric W. Biederman @ 2015-05-28 19:57 UTC (permalink / raw)
To: Richard Weinberger
Cc: Kenton Varda, Greg Kroah-Hartman, Linux Containers, Serge Hallyn,
Andy Lutomirski, Seth Forshee, Michael Kerrisk-manpages,
Linux API, Linux FS Devel, Tejun Heo
In-Reply-To: <55676E32.3050006-/L3Ra7n9ekc@public.gmane.org>
Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org> writes:
> Am 28.05.2015 um 16:08 schrieb Serge Hallyn:
>> Quoting Andy Lutomirski (luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org):
>>> On Fri, May 22, 2015 at 10:39 AM, Eric W. Biederman
>>> <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
>>>> I had hoped to get some Tested-By's on that patch series.
>>>
>>> Sorry, I've been totally swamped.
>>>
>>> I suspect that Sandstorm is okay, but I haven't had a chance to test
>>> it for real. Sandstorm makes only limited use of proc and sysfs in
>>> containers, but I'll see if I can test it for real this weekend.
>>
>> Testing this with unprivileged containers, I get
>>
>> lxc-start: conf.c: lxc_mount_auto_mounts: 808 Operation not permitted - error mounting sysfs on /usr/lib/x86_64-linux-gnu/lxc/sys/devices/virtual/net flags 0
>>
>
> FWIW, it breaks also libvirt-lxc:
> Error: internal error: guest failed to start: Failed to re-mount /proc/sys on /proc/sys flags=1021: Operation not permitted
Interesting. I had not anticipated a failure there? And it is failing
in remount? Oh that is interesting.
That implies that there is some flag of the original mount of /proc that
the remount of /proc/sys is clearing, and that previously
The flags specified are current rdonly,remount,bind so I expect there
are some other flags on proc that libvirt-lxc is clearing by accident
and we did not fail before because the kernel was not enforcing things.
What are the mount flags in a working libvirt-lxc?
Eric
^ permalink raw reply
* Re: [CFT][PATCH 00/10] Making new mounts of proc and sysfs as safe as bind mounts (take 2)
From: Kenton Varda @ 2015-05-28 20:12 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Andy Lutomirski, Serge Hallyn, Seth Forshee, Linux API,
Linux Containers, Greg Kroah-Hartman, Michael Kerrisk-manpages,
Richard Weinberger, Linux FS Devel, Tejun Heo
In-Reply-To: <87fv6gikfn.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
On Thu, May 28, 2015 at 12:14 PM, Eric W. Biederman
<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> wrote:
> But please someone test sandstorm with this patchset and tell me if it
> bites you. The impetus to find a way to avoid breaking slightly buggy
> userspace is higher if it is more than unprivileged lxc that is broken.
One of these days I'm going to learn how to compile and test kernels
again (last time I did it was 1999). Unfortunately I don't think I
have time at the moment, but hopefully Andy can do it.
I note, though, that we only have two mount() calls in the sandstorm
codebase that seem like they could be affected:
run-bundle.c++:1264: KJ_SYSCALL(mount("proc", "proc", "proc",
MS_NOSUID | MS_NODEV | MS_NOEXEC, ""));
minibox.c++:251: KJ_SYSCALL(mount("proc", vpath.cStr(), "proc",
MS_NOSUID | MS_NODEV | MS_NOEXEC, ""),
supervisor.c++:921: KJ_SYSCALL(mount("/proc", "proc", nullptr, MS_BIND
| MS_REC, nullptr));
The first two seem like they should be fine since they set all the
flags (except readonly, which would be inappropriate for proc). I
guess my habit of setting every security flag I see came in handy. The
third case looks like it will be broken, BUT this line is in a
debug-only code path, so I don't care. Also we have the ability to
push any needed update within 24 hours, so we're generally in good
shape.
We never mount sysfs in Sandstorm.
> If I mount proc read-write I likely want to be able to write to proc
> files, and I will be much happier if the mount fails than if a bazillion
> syscalls later something else fails when it tries to write to proc.
I'm not sure that's true. Consider the broader context:
1) Your system's /proc is mounted read-only.
2) Now you're trying to mount a new proc in a new pid namespace, and
you do *not* specify MS_READONLY.
What should we expect here? Let's back off a bit and state user intent:
1) The system administrator has set a system-wide policy that /proc
may only be read, not written.
2) You made a PID namespace and it needed its own proc.
It seems intuitive here that the administrator's policy should apply
in the namespace. Certainly everyone using the system and/or all
software on the system already needs to be aware of this policy, since
it's unusual and will break things. Running software on this system
outside of any container already has the problem that syscalls
randomly break, so why should it be surprising when this happens
inside the container as well? Why do we need to go out of our way to
break at mount() time?
-Kenton
^ permalink raw reply
* Re: [CFT][PATCH 00/10] Making new mounts of proc and sysfs as safe as bind mounts (take 2)
From: Richard Weinberger @ 2015-05-28 20:30 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Serge Hallyn, Andy Lutomirski, Seth Forshee, Linux API,
Linux Containers, Greg Kroah-Hartman, Kenton Varda,
Michael Kerrisk-manpages, Linux FS Devel, Tejun Heo
In-Reply-To: <87382gh3uo.fsf@x220.int.ebiederm.org>
Am 28.05.2015 um 21:57 schrieb Eric W. Biederman:
>> FWIW, it breaks also libvirt-lxc:
>> Error: internal error: guest failed to start: Failed to re-mount /proc/sys on /proc/sys flags=1021: Operation not permitted
>
> Interesting. I had not anticipated a failure there? And it is failing
> in remount? Oh that is interesting.
>
> That implies that there is some flag of the original mount of /proc that
> the remount of /proc/sys is clearing, and that previously
>
> The flags specified are current rdonly,remount,bind so I expect there
> are some other flags on proc that libvirt-lxc is clearing by accident
> and we did not fail before because the kernel was not enforcing things.
Please see:
http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/lxc/lxc_container.c;h=9a9ae5c2aaf0f90ff472f24fda43c077b44998c7;hb=HEAD#l933
lxcContainerMountBasicFS()
and:
http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/lxc/lxc_container.c;h=9a9ae5c2aaf0f90ff472f24fda43c077b44998c7;hb=HEAD#l850
lxcBasicMounts
> What are the mount flags in a working libvirt-lxc?
See:
test1:~ # cat /proc/self/mountinfo
147 100 0:30 /srv/container/test1/rootfs / rw,relatime - btrfs /dev/sda2 rw,space_cache
149 147 0:56 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
150 149 0:56 /sys /proc/sys ro,nodev,relatime - proc proc rw
151 150 0:3 /sys/net/ipv4 /proc/sys/net/ipv4 rw,nosuid,nodev,noexec,relatime - proc proc rw
152 150 0:3 /sys/net/ipv6 /proc/sys/net/ipv6 rw,nosuid,nodev,noexec,relatime - proc proc rw
153 147 0:57 / /sys ro,nodev,relatime - sysfs sysfs rw
154 149 0:53 /meminfo /proc/meminfo rw,nosuid,nodev,relatime - fuse libvirt rw,user_id=0,group_id=0,allow_other
155 153 0:58 / /sys/fs/cgroup rw,nosuid,nodev,noexec,relatime - tmpfs tmpfs rw,size=64k,mode=755,uid=10000,gid=10000
156 155 0:22 /machine.slice/machine-lxc\134x2dtest1.scope /sys/fs/cgroup/cpu,cpuacct rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,cpu,cpuacct
157 155 0:21 /machine.slice/machine-lxc\134x2dtest1.scope /sys/fs/cgroup/cpuset rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,cpuset
158 155 0:23 /machine.slice/machine-lxc\134x2dtest1.scope /sys/fs/cgroup/memory rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,memory
159 155 0:24 /machine.slice/machine-lxc\134x2dtest1.scope /sys/fs/cgroup/devices rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,devices
160 155 0:25 /machine.slice/machine-lxc\134x2dtest1.scope /sys/fs/cgroup/freezer rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,freezer
161 155 0:27 /machine.slice/machine-lxc\134x2dtest1.scope /sys/fs/cgroup/blkio rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,blkio
162 155 0:26 /machine.slice/machine-lxc\134x2dtest1.scope /sys/fs/cgroup/net_cls,net_prio rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,net_cls,net_prio
163 155 0:28 /machine.slice/machine-lxc\134x2dtest1.scope /sys/fs/cgroup/perf_event rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,perf_event
164 155 0:19 /machine.slice/machine-lxc\134x2dtest1.scope /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup cgroup
rw,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd
165 147 0:52 / /dev rw,nosuid,relatime - tmpfs devfs rw,size=64k,mode=755
166 165 0:51 / /dev/pts rw,nosuid,relatime - devpts devpts rw,gid=10005,mode=620,ptmxmode=666
167 165 0:51 /ptmx /dev/ptmx rw,nosuid,relatime - devpts devpts rw,gid=10005,mode=620,ptmxmode=666
101 165 0:55 / /dev/shm rw,nosuid,nodev - tmpfs tmpfs rw,uid=10000,gid=10000
102 147 0:59 / /run rw,nosuid,nodev - tmpfs tmpfs rw,mode=755,uid=10000,gid=10000
103 165 0:54 / /dev/mqueue rw,nodev,relatime - mqueue mqueue rw
104 147 0:59 / /var/run rw,nosuid,nodev - tmpfs tmpfs rw,mode=755,uid=10000,gid=10000
105 147 0:59 /lock /var/lock rw,nosuid,nodev - tmpfs tmpfs rw,mode=755,uid=10000,gid=10000
If you need more info, please let me know. :-)
Thanks,
//richard
^ permalink raw reply
* Re: [PATCH v2 1/5] nohz_full: add support for "cpu_isolated" mode
From: Chris Metcalf @ 2015-05-28 20:38 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Gilad Ben Yossef, Steven Rostedt, Ingo Molnar, Peter Zijlstra,
Andrew Morton, Rik van Riel, Tejun Heo, Frederic Weisbecker,
Paul E. McKenney, Christoph Lameter, Viresh Kumar,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.DEB.2.11.1505152337170.4225@nanos>
Thomas, thanks for the feedback. My reply was delayed by being in meetings
all last week and then catching up this week - sorry about that.
On 05/15/2015 06:17 PM, Thomas Gleixner wrote:
> On Fri, 15 May 2015, Chris Metcalf wrote:
>> +/*
>> + * We normally return immediately to userspace.
>> + *
>> + * In "cpu_isolated" mode we wait until no more interrupts are
>> + * pending. Otherwise we nap with interrupts enabled and wait for the
>> + * next interrupt to fire, then loop back and retry.
>> + *
>> + * Note that if you schedule two "cpu_isolated" processes on the same
>> + * core, neither will ever leave the kernel, and one will have to be
>> + * killed manually.
> And why are we not preventing that situation in the first place? The
> scheduler should be able to figure that out easily..
This is an interesting observation. My instinct is that adding tests in the
scheduler costs time on a hot path for all processes, and I'm trying to
avoid adding cost where we don't need it. It's pretty much a straight-up
application bug if two threads or processes explicitly request the
cpu_isolated semantics, and then explicitly schedule themselves onto
the same core, so my preference was to let the application writer
identify and fix the problem if it comes up.
However, I'm certainly open to thinking about checking for this failure
mode in the scheduler, though I don't know enough about the
scheduler to immediately identify where such a change might go.
Would it be appropriate to think about this as a follow-on patch, if it's
determined that the cost of testing for this condition is worth it?
>> + Otherwise in situations where another process is
>> + * in the runqueue on this cpu, this task will just wait for that
>> + * other task to go idle before returning to user space.
>> + */
>> +void tick_nohz_cpu_isolated_enter(void)
>> +{
>> + struct clock_event_device *dev =
>> + __this_cpu_read(tick_cpu_device.evtdev);
>> + struct task_struct *task = current;
>> + unsigned long start = jiffies;
>> + bool warned = false;
>> +
>> + /* Drain the pagevecs to avoid unnecessary IPI flushes later. */
>> + lru_add_drain();
>> +
>> + while (ACCESS_ONCE(dev->next_event.tv64) != KTIME_MAX) {
> What's the ACCESS_ONCE for?
We are technically in a loop here where we are waiting for an
interrupt handler to update dev->next_event.tv64, so I felt it was
appropriate to flag it as such. If we didn't have function calls inside
the loop, the compiler would eliminate the loop.
But it's just a style thing, and we can certainly drop it if it seems
confusing. In any case I've changed it to READ_ONCE() since
that's preferred now anyway; this code was originally written
a while ago.
>> + if (!warned && (jiffies - start) >= (5 * HZ)) {
>> + pr_warn("%s/%d: cpu %d: cpu_isolated task blocked for %ld jiffies\n",
>> + task->comm, task->pid, smp_processor_id(),
>> + (jiffies - start));
> What additional value has the jiffies delta over a plain human
> readable '5sec' ?
Good point. I've changed it to emit a value in seconds.
>> + warned = true;
>> + }
>> + if (should_resched())
>> + schedule();
>> + if (test_thread_flag(TIF_SIGPENDING))
>> + break;
>> +
>> + /* Idle with interrupts enabled and wait for the tick. */
>> + set_current_state(TASK_INTERRUPTIBLE);
>> + arch_cpu_idle();
> Oh NO! Not another variant of fake idle task. The idle implementations
> can call into code which rightfully expects that the CPU is actually
> IDLE.
>
> I wasted enough time already debugging the resulting wreckage. Feel
> free to use it for experimental purposes, but this is not going
> anywhere near to a mainline kernel.
>
> I completely understand WHY you want to do that, but we need proper
> mechanisms for that and not some duct tape engineering band aids which
> will create hard to debug side effects.
Yes, I worried about that a little when I put it in. In particular it's
certainly true that arch_cpu_idle() isn't necessarily designed to
behave properly in this context, even if it may do the right thing
somewhat by accident.
In fact, we don't need the cpu-idling semantics in this loop;
the loop can spin quite happily waiting for next_event in the
tick_cpu_device to stop being defined (or a signal or scheduling
request to occur). I've changed the code to make it opt-in, so
that a weak no-op function that just calls cpu_relax() can be
replaced by an architecture-defined function that safely waits
until an interrupt is delivered, reducing the number of times we
spin around in the outer loop.
> Hint: It's a scheduler job to make sure that the machine has quiesced
> _BEFORE_ letting the magic task off to user land.
This is not so clear to me. There may, for example, be RCU events
that occur after the scheduler is done with its part, that still require
another timer tick on the cpu to finish quiescing RCU. I think we
need to check for the timer-quiesced state as late as possible to
handle things like this.
Arguably the scheduler could also try to do the right thing with
a cpu_isolated task, but again, this feels like time spent in the
scheduler hot path that affects the non-cpu_isolated tasks. For
cpu_isolated tasks they should be the only thing that's runnable
on the core 99.999% of the time, or you've done something quite
wrong anyway.
>> + set_current_state(TASK_RUNNING);
>> + }
>> + if (warned) {
>> + pr_warn("%s/%d: cpu %d: cpu_isolated task unblocked after %ld jiffies\n",
>> + task->comm, task->pid, smp_processor_id(),
>> + (jiffies - start));
>> + dump_stack();
> And that dump_stack() tells us which important information?
>
> tick_nohz_cpu_isolated_enter
> context_tracking_enter
> context_tracking_user_enter
> arch_return_to_user_code
For tile, the dump_stack() includes the register state, which includes
the interrupt type that took us into the kernel, which might be helpful.
That said, I'm certainly willing to remove it, or make it call a weak
no-op function where architectures can add more info if they have it.
Thanks again! I'll put out v3 of the patch series shortly, with changes
from your comments incorporated.
--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com
^ permalink raw reply
* Re: [CFT][PATCH 00/10] Making new mounts of proc and sysfs as safe as bind mounts (take 2)
From: Richard Weinberger @ 2015-05-28 20:47 UTC (permalink / raw)
To: Kenton Varda, Eric W. Biederman
Cc: Andy Lutomirski, Serge Hallyn, Seth Forshee, Linux API,
Linux Containers, Greg Kroah-Hartman, Michael Kerrisk-manpages,
Linux FS Devel, Tejun Heo
In-Reply-To: <CAOP=4wieEaR_wESNyba7EKPAhi6kf+ujxhoMAFKVRozqWtXHvQ@mail.gmail.com>
Am 28.05.2015 um 22:12 schrieb Kenton Varda:
> We never mount sysfs in Sandstorm.
sysfs is ABI and applications depend on it.
Even glibc is using sysfs. Currently it has
fallback paths but these may go away...
Thanks,
//richard
^ permalink raw reply
* Re: [CFT][PATCH 00/10] Making new mounts of proc and sysfs as safe as bind mounts (take 2)
From: Serge E. Hallyn @ 2015-05-28 21:04 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Serge Hallyn, Richard Weinberger, Kenton Varda, Linux API,
Linux Containers, Andy Lutomirski, Seth Forshee,
Michael Kerrisk-manpages, Greg Kroah-Hartman, Linux FS Devel,
Tejun Heo
In-Reply-To: <87lhg8pwvz.fsf@x220.int.ebiederm.org>
On Thu, May 28, 2015 at 10:03:28AM -0500, Eric W. Biederman wrote:
> Serge Hallyn <serge.hallyn@ubuntu.com> writes:
>
> > Quoting Andy Lutomirski (luto@amacapital.net):
> >> On Fri, May 22, 2015 at 10:39 AM, Eric W. Biederman
> >> <ebiederm@xmission.com> wrote:
> >> > I had hoped to get some Tested-By's on that patch series.
> >>
> >> Sorry, I've been totally swamped.
> >>
> >> I suspect that Sandstorm is okay, but I haven't had a chance to test
> >> it for real. Sandstorm makes only limited use of proc and sysfs in
> >> containers, but I'll see if I can test it for real this weekend.
> >
> > Testing this with unprivileged containers, I get
> >
> > lxc-start: conf.c: lxc_mount_auto_mounts: 808 Operation not permitted
> > - error mounting sysfs on
> > /usr/lib/x86_64-linux-gnu/lxc/sys/devices/virtual/net flags 0
>
> Grr.. I was afraid this would break something. :(
>
> Looking at my system I see that sysfs is currently mounted
> "nosuid,nodev,noexec"
>
> Looking at the lxc-start code I don't see it as including any of those
> mount options. In practice for sysfs I think those options are
> meaningless (as there should be no devices and nothing executable in
> sysfs) but I can understand the past concerns with chmod on virtual
> filesystems that would incline people to use them, so I think the
> failure is reporting a legitimate security issue in the lxc userspace
> code where the the unprivileged code is currently attempting to give
> greater access to sysfs than was given by the original mount of sysfs.
>
> As nosuid,nodev,noexec should not impair the operation of sysfs
> operation it looks like you can always specify those options and just
> make this concern go away.
>
> Something like the untested patch below I expect.
>
> diff --git a/src/lxc/conf.c b/src/lxc/conf.c
> index 9870455b3cae..d9ccd03afe68 100644
> --- a/src/lxc/conf.c
> +++ b/src/lxc/conf.c
> @@ -770,8 +770,8 @@ static int lxc_mount_auto_mounts(struct lxc_conf *conf, int flags, struct lxc_ha
> { LXC_AUTO_PROC_MASK, LXC_AUTO_PROC_MIXED, "%r/proc/sysrq-trigger", "%r/proc/sysrq-trigger", NULL, MS_BIND, NULL },
> { LXC_AUTO_PROC_MASK, LXC_AUTO_PROC_MIXED, NULL, "%r/proc/sysrq-trigger", NULL, MS_REMOUNT|MS_BIND|MS_RDONLY, NULL },
> { LXC_AUTO_PROC_MASK, LXC_AUTO_PROC_RW, "proc", "%r/proc", "proc", MS_NODEV|MS_NOEXEC|MS_NOSUID, NULL },
> - { LXC_AUTO_SYS_MASK, LXC_AUTO_SYS_RW, "sysfs", "%r/sys", "sysfs", 0, NULL },
> - { LXC_AUTO_SYS_MASK, LXC_AUTO_SYS_RO, "sysfs", "%r/sys", "sysfs", MS_RDONLY, NULL },
> + { LXC_AUTO_SYS_MASK, LXC_AUTO_SYS_RW, "sysfs", "%r/sys", "sysfs", MS_NODEV|MS_NOEXEC|MS_NOSUID, NULL },
> + { LXC_AUTO_SYS_MASK, LXC_AUTO_SYS_RO, "sysfs", "%r/sys", "sysfs", MS_NODEV|MS_NOEXEC|MS_NOSUID|MS_RDONLY, NULL },
> { LXC_AUTO_SYS_MASK, LXC_AUTO_SYS_MIXED, "sysfs", "%r/sys", "sysfs", MS_NODEV|MS_NOEXEC|MS_NOSUID, NULL },
> { LXC_AUTO_SYS_MASK, LXC_AUTO_SYS_MIXED, "%r/sys", "%r/sys", NULL, MS_BIND, NULL },
> { LXC_AUTO_SYS_MASK, LXC_AUTO_SYS_MIXED, NULL, "%r/sys", NULL, MS_REMOUNT|MS_BIND|MS_RDONLY, NULL },
fwiw - the first one works, the second one does not due to an apparent
inability to statvfs the origin.
> Alternately you can read the flags off of the original mount of proc or sysfs.
>
> diff --git a/src/lxc/conf.c b/src/lxc/conf.c
> index 9870455b3cae..50ea49973e80 100644
> --- a/src/lxc/conf.c
> +++ b/src/lxc/conf.c
> @@ -712,7 +712,9 @@ static unsigned long add_required_remount_flags(const char *s, const char *d,
> struct statvfs sb;
> unsigned long required_flags = 0;
>
> - if (!(flags & MS_REMOUNT))
> + if (!(flags & MS_REMOUNT) &&
> + (strcmp(s, "proc") != 0) &&
> + (strcmp(s, "sysfs") != 0))
> return flags;
>
> if (!s)
>
> Eric
> _______________________________________________
> Containers mailing list
> Containers@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply
* Re: [CFT][PATCH 00/10] Making new mounts of proc and sysfs as safe as bind mounts (take 2)
From: Kenton Varda @ 2015-05-28 21:07 UTC (permalink / raw)
To: Richard Weinberger
Cc: Eric W. Biederman, Andy Lutomirski, Serge Hallyn, Seth Forshee,
Linux API, Linux Containers, Greg Kroah-Hartman,
Michael Kerrisk-manpages, Linux FS Devel, Tejun Heo
In-Reply-To: <55677EE4.2040903@nod.at>
On Thu, May 28, 2015 at 1:47 PM, Richard Weinberger <richard@nod.at> wrote:
> Am 28.05.2015 um 22:12 schrieb Kenton Varda:
>> We never mount sysfs in Sandstorm.
>
> sysfs is ABI and applications depend on it.
> Even glibc is using sysfs. Currently it has
> fallback paths but these may go away...
Off-topic, but Sandstorm isn't intended to provide a full Linux ABI.
It is intended to provide a secure sandbox that can run apps that have
been explicitly ported to Sandstorm. More background if you're interested:
https://github.com/sandstorm-io/sandstorm/wiki/Security-Practices-Overview#server-sandboxing
https://blog.sandstorm.io/news/2014-08-13-sandbox-security.html
-Kenton
^ 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