On Tue, Jun 20, 2017 at 08:42:45AM +0300, Amir Goldstein wrote:
> On Tue, Jun 20, 2017 at 12:34 AM, Eric W. Biederman
> wrote:
> > "Serge E. Hallyn" writes:
> >
> >> Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
> >>> On 06/14/2017 11:05 PM, Serge E. Hallyn wrote:
> >>> >On Wed, Jun 14, 201
On Tue, Jun 20, 2017 at 8:33 PM, Stefan Berger
wrote:
> On 06/20/2017 08:19 AM, Stefan Berger wrote:
>>
>> On 06/20/2017 01:42 AM, Amir Goldstein wrote:
>>> Apropos stackable filesystems [cc some overlayfs folks], is there any
>>> way that parts of this work could be generalized towards ns a
On 06/20/2017 08:19 AM, Stefan Berger wrote:
On 06/20/2017 01:42 AM, Amir Goldstein wrote:
On Tue, Jun 20, 2017 at 12:34 AM, Eric W. Biederman
wrote:
"Serge E. Hallyn" writes:
Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
On 06/14/2017 11:05 PM, Serge E. Hallyn wrote:
On Wed, Jun 14
On 06/20/2017 01:42 AM, Amir Goldstein wrote:
On Tue, Jun 20, 2017 at 12:34 AM, Eric W. Biederman
wrote:
"Serge E. Hallyn" writes:
Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
On 06/14/2017 11:05 PM, Serge E. Hallyn wrote:
On Wed, Jun 14, 2017 at 08:27:40AM -0400, Stefan Berger wrot
On Sun, Jun 18, 2017 at 09:13:28PM -0400, Stefan Berger wrote:
> Can you adapt your test cases. I haven't tried them, but having
> them would be important.
branch nsfscaps of github.com/hallyn/ltp now has a patch on top
which makes it work with your capabilities. Tests are passing.
thanks,
-ser
On Tue, Jun 20, 2017 at 12:34 AM, Eric W. Biederman
wrote:
> "Serge E. Hallyn" writes:
>
>> Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
>>> On 06/14/2017 11:05 PM, Serge E. Hallyn wrote:
>>> >On Wed, Jun 14, 2017 at 08:27:40AM -0400, Stefan Berger wrote:
>>> >>On 06/13/2017 07:55 PM, Serg
"Serge E. Hallyn" writes:
> Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
>> On 06/14/2017 11:05 PM, Serge E. Hallyn wrote:
>> >On Wed, Jun 14, 2017 at 08:27:40AM -0400, Stefan Berger wrote:
>> >>On 06/13/2017 07:55 PM, Serge E. Hallyn wrote:
>> >>>Quoting Stefan Berger (stef...@linux.vnet.
On 06/18/2017 09:13 PM, Stefan Berger wrote:
On 06/18/2017 06:14 PM, Serge E. Hallyn wrote:
Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
On 06/14/2017 11:05 PM, Serge E. Hallyn wrote:
On Wed, Jun 14, 2017 at 08:27:40AM -0400, Stefan Berger wrote:
On 06/13/2017 07:55 PM, Serge E. Hallyn
On 06/18/2017 06:14 PM, Serge E. Hallyn wrote:
Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
On 06/14/2017 11:05 PM, Serge E. Hallyn wrote:
On Wed, Jun 14, 2017 at 08:27:40AM -0400, Stefan Berger wrote:
On 06/13/2017 07:55 PM, Serge E. Hallyn wrote:
Quoting Stefan Berger (stef...@linux.
Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
> On 06/14/2017 11:05 PM, Serge E. Hallyn wrote:
> >On Wed, Jun 14, 2017 at 08:27:40AM -0400, Stefan Berger wrote:
> >>On 06/13/2017 07:55 PM, Serge E. Hallyn wrote:
> >>>Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
> If all extended
On 06/14/2017 11:05 PM, Serge E. Hallyn wrote:
On Wed, Jun 14, 2017 at 08:27:40AM -0400, Stefan Berger wrote:
On 06/13/2017 07:55 PM, Serge E. Hallyn wrote:
Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
If all extended
attributes were to support this model, maybe the 'uid' could be
ass
On 06/14/2017 11:05 PM, Serge E. Hallyn wrote:
On Wed, Jun 14, 2017 at 08:27:40AM -0400, Stefan Berger wrote:
On 06/13/2017 07:55 PM, Serge E. Hallyn wrote:
Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
If all extended
attributes were to support this model, maybe the 'uid' could be
ass
> "Serge E. Hallyn" hat am 15. Juni 2017 um 05:05
> geschrieben:
>
>
> On Wed, Jun 14, 2017 at 08:27:40AM -0400, Stefan Berger wrote:
> > On 06/13/2017 07:55 PM, Serge E. Hallyn wrote:
> > >Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
> > >> If all extended
> > >>attributes were to supp
On Wed, Jun 14, 2017 at 08:27:40AM -0400, Stefan Berger wrote:
> On 06/13/2017 07:55 PM, Serge E. Hallyn wrote:
> >Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
> >> If all extended
> >>attributes were to support this model, maybe the 'uid' could be
> >>associated with the 'name' of the xatt
On 06/13/2017 07:55 PM, Serge E. Hallyn wrote:
Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
On 06/13/2017 01:18 PM, Serge E. Hallyn wrote:
Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
On 05/08/2017 02:11 PM, Serge E. Hallyn wrote:
Root in a non-initial user ns cannot be trusted
Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
> On 06/13/2017 01:18 PM, Serge E. Hallyn wrote:
> >Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
> >>On 05/08/2017 02:11 PM, Serge E. Hallyn wrote:
> >>>Root in a non-initial user ns cannot be trusted to write a traditional
> >>>security.ca
Quoting Serge E. Hallyn (se...@hallyn.com):
> Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
> > On 05/08/2017 02:11 PM, Serge E. Hallyn wrote:
> > >Root in a non-initial user ns cannot be trusted to write a traditional
> > >security.capability xattr. If it were allowed to do so, then any
> >
Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
> On 05/08/2017 02:11 PM, Serge E. Hallyn wrote:
> >Root in a non-initial user ns cannot be trusted to write a traditional
> >security.capability xattr. If it were allowed to do so, then any
> >unprivileged user on the host could map his own uid
On Tue, Jun 13, 2017 at 04:59:30PM -0400, Mimi Zohar wrote:
> Assuming you want to support container specific executables, you would
> want them specifically signed by a key not on the system IMA keyring.
Yes, this is a good point.
Cheers,
Tycho
On Tue, 2017-06-13 at 14:53 -0600, Tycho Andersen wrote:
> On Tue, Jun 13, 2017 at 04:49:03PM -0400, Stefan Berger wrote:
> > On 06/13/2017 04:46 PM, Tycho Andersen wrote:
> > > On Tue, Jun 13, 2017 at 10:45:02AM -0700, James Bottomley wrote:
> > > > On Tue, 2017-06-13 at 11:14 -0600, Tycho Anderse
On 06/13/2017 04:53 PM, Tycho Andersen wrote:
On Tue, Jun 13, 2017 at 04:49:03PM -0400, Stefan Berger wrote:
On 06/13/2017 04:46 PM, Tycho Andersen wrote:
On Tue, Jun 13, 2017 at 10:45:02AM -0700, James Bottomley wrote:
On Tue, 2017-06-13 at 11:14 -0600, Tycho Andersen via Containers wrote:
H
On Tue, Jun 13, 2017 at 04:49:03PM -0400, Stefan Berger wrote:
> On 06/13/2017 04:46 PM, Tycho Andersen wrote:
> > On Tue, Jun 13, 2017 at 10:45:02AM -0700, James Bottomley wrote:
> > > On Tue, 2017-06-13 at 11:14 -0600, Tycho Andersen via Containers wrote:
> > > > Hi Stefan,
> > > >
> > > > On Tu
On Tue, Jun 13, 2017 at 01:42:24PM -0400, Stefan Berger wrote:
> On 06/13/2017 01:14 PM, Tycho Andersen wrote:
> > Hi Stefan,
> >
> > On Tue, Jun 13, 2017 at 11:47:26AM -0400, Stefan Berger wrote:
> > > On 05/08/2017 02:11 PM, Serge E. Hallyn wrote:
> > > > Root in a non-initial user ns cannot be
On 06/13/2017 04:46 PM, Tycho Andersen wrote:
On Tue, Jun 13, 2017 at 10:45:02AM -0700, James Bottomley wrote:
On Tue, 2017-06-13 at 11:14 -0600, Tycho Andersen via Containers wrote:
Hi Stefan,
On Tue, Jun 13, 2017 at 11:47:26AM -0400, Stefan Berger wrote:
On 05/08/2017 02:11 PM, Serge E. Hal
On Tue, Jun 13, 2017 at 10:45:02AM -0700, James Bottomley wrote:
> On Tue, 2017-06-13 at 11:14 -0600, Tycho Andersen via Containers wrote:
> > Hi Stefan,
> >
> > On Tue, Jun 13, 2017 at 11:47:26AM -0400, Stefan Berger wrote:
> > > On 05/08/2017 02:11 PM, Serge E. Hallyn wrote:
> > > > Root in a no
On 06/13/2017 01:18 PM, Serge E. Hallyn wrote:
Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
On 05/08/2017 02:11 PM, Serge E. Hallyn wrote:
Root in a non-initial user ns cannot be trusted to write a traditional
security.capability xattr. If it were allowed to do so, then any
unprivileged
On Tue, 2017-06-13 at 11:14 -0600, Tycho Andersen via Containers wrote:
> Hi Stefan,
>
> On Tue, Jun 13, 2017 at 11:47:26AM -0400, Stefan Berger wrote:
> > On 05/08/2017 02:11 PM, Serge E. Hallyn wrote:
> > > Root in a non-initial user ns cannot be trusted to write a
> > > traditional security.ca
On 06/13/2017 01:14 PM, Tycho Andersen wrote:
Hi Stefan,
On Tue, Jun 13, 2017 at 11:47:26AM -0400, Stefan Berger wrote:
On 05/08/2017 02:11 PM, Serge E. Hallyn wrote:
Root in a non-initial user ns cannot be trusted to write a traditional
security.capability xattr. If it were allowed to do so,
Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
> On 05/08/2017 02:11 PM, Serge E. Hallyn wrote:
> >Root in a non-initial user ns cannot be trusted to write a traditional
> >security.capability xattr. If it were allowed to do so, then any
> >unprivileged user on the host could map his own uid
Hi Stefan,
On Tue, Jun 13, 2017 at 11:47:26AM -0400, Stefan Berger wrote:
> On 05/08/2017 02:11 PM, Serge E. Hallyn wrote:
> > Root in a non-initial user ns cannot be trusted to write a traditional
> > security.capability xattr. If it were allowed to do so, then any
> > unprivileged user on the h
On 05/08/2017 02:11 PM, Serge E. Hallyn wrote:
Root in a non-initial user ns cannot be trusted to write a traditional
security.capability xattr. If it were allowed to do so, then any
unprivileged user on the host could map his own uid to root in a private
namespace, write the xattr, and execute
"Serge E. Hallyn" writes:
> Quoting Eric W. Biederman (ebied...@xmission.com):
>> "Serge E. Hallyn" writes:
>> > Changelog:
>> [snip]
>> >May 8, 2017:
>> > . fix leaking dentry refcount in cap_inode_getsecurity
>> >
>> [snip]
>> > +/*
>> > + * getsecurity: We are called for security.*
Quoting Eric W. Biederman (ebied...@xmission.com):
> "Serge E. Hallyn" writes:
> > Changelog:
> [snip]
> >May 8, 2017:
> > . fix leaking dentry refcount in cap_inode_getsecurity
> >
> [snip]
> > +/*
> > + * getsecurity: We are called for security.* before any attempt to read the
> > + *
"Serge E. Hallyn" writes:
> Changelog:
[snip]
>May 8, 2017:
> . fix leaking dentry refcount in cap_inode_getsecurity
>
[snip]
> +/*
> + * getsecurity: We are called for security.* before any attempt to read the
> + * xattr from the inode itself.
> + *
> + * This gives us a chance to read
Root in a non-initial user ns cannot be trusted to write a traditional
security.capability xattr. If it were allowed to do so, then any
unprivileged user on the host could map his own uid to root in a private
namespace, write the xattr, and execute the file with privilege on the
host.
However sup
35 matches
Mail list logo
