On Wed, Jul 29, 2015 at 11:04:50AM -0500, Serge E. Hallyn wrote:
> On Thu, Jul 16, 2015 at 12:04:43AM -0500, Eric W. Biederman wrote:
> > > I tend to thing that, if we're not honoring the fcaps, we shouldn't be
> > > honoring the setuid bit either. After all, it's really not a trusted
> > > file,
On Thu, Jul 16, 2015 at 12:04:43AM -0500, Eric W. Biederman wrote:
> > I tend to thing that, if we're not honoring the fcaps, we shouldn't be
> > honoring the setuid bit either. After all, it's really not a trusted
> > file, even though the only user who could have messed with it really
> > is the
Seth Forshee writes:
> On Thu, Jul 16, 2015 at 12:44:49AM -0500, Eric W. Biederman wrote:
>> Andy Lutomirski writes:
>>
>> > On Wed, Jul 15, 2015 at 10:04 PM, Eric W. Biederman
>> > wrote:
>> >> Andy Lutomirski writes:
>> >>
>> >>>
>> >>> So here's the semantic question:
>> >>>
>> >>> Suppose
On Thu, Jul 16, 2015 at 12:44:49AM -0500, Eric W. Biederman wrote:
> Andy Lutomirski writes:
>
> > On Wed, Jul 15, 2015 at 10:04 PM, Eric W. Biederman
> > wrote:
> >> Andy Lutomirski writes:
> >>
> >>>
> >>> So here's the semantic question:
> >>>
> >>> Suppose an unprivileged user (uid 1000) cr
On Wed, Jul 15, 2015 at 06:23:01PM -0700, Andy Lutomirski wrote:
> > So if we have the s_user_ns check in get_file_caps the mnt_may_suid pass
> > isn't strictly necessary, but I still think it is useful as a mitigation
> > to the "leaks" Eric mentions. It _should_ be impossible for a user to
> > ga
Andy Lutomirski writes:
> On Wed, Jul 15, 2015 at 10:04 PM, Eric W. Biederman
> wrote:
>> Andy Lutomirski writes:
>>
>>>
>>> So here's the semantic question:
>>>
>>> Suppose an unprivileged user (uid 1000) creates a user namespace and a
>>> mount namespace. They stick a file (owned by uid 1000
On Wed, Jul 15, 2015 at 10:04 PM, Eric W. Biederman
wrote:
> Andy Lutomirski writes:
>
>> On Wed, Jul 15, 2015 at 9:23 PM, Eric W. Biederman
>> wrote:
>>>
>>> Ok. Andy I have stopped and really looked at your patch that is 4/7 in
>>> this series. Something I had not done before since it sounde
Andy Lutomirski writes:
> On Wed, Jul 15, 2015 at 9:23 PM, Eric W. Biederman
> wrote:
>>
>> Ok. Andy I have stopped and really looked at your patch that is 4/7 in
>> this series. Something I had not done before since it sounded totally
>> wrong.
>>
>> That combined with your earlier comments I
On Wed, Jul 15, 2015 at 9:23 PM, Eric W. Biederman
wrote:
>
> Ok. Andy I have stopped and really looked at your patch that is 4/7 in
> this series. Something I had not done before since it sounded totally
> wrong.
>
> That combined with your earlier comments I think I can say something
> meaning
Ok. Andy I have stopped and really looked at your patch that is 4/7 in
this series. Something I had not done before since it sounded totally
wrong.
That combined with your earlier comments I think I can say something
meaningful.
Andy as I read your patch the thread you are primarily worried
On Wed, Jul 15, 2015 at 6:14 PM, Seth Forshee
wrote:
> mnt_may_suid would also restrict the namespaces where the capabilities
> would be honored, but not to only namespaces where the mounter is
> already privileged. Of course it does require a user privileged in
> another namespace to perform a mo
On Wed, Jul 15, 2015 at 3:35 PM, Eric W. Biederman
wrote:
> Andy Lutomirski writes:
>
>> On Wed, Jul 15, 2015 at 2:48 PM, Serge E. Hallyn wrote:
>>> On Wed, Jul 15, 2015 at 02:46:04PM -0500, Seth Forshee wrote:
Capability sets attached to files must be ignored except in the
user namesp
On Wed, Jul 15, 2015 at 05:35:24PM -0500, Eric W. Biederman wrote:
> Andy Lutomirski writes:
>
> > On Wed, Jul 15, 2015 at 2:48 PM, Serge E. Hallyn wrote:
> >> On Wed, Jul 15, 2015 at 02:46:04PM -0500, Seth Forshee wrote:
> >>> Capability sets attached to files must be ignored except in the
> >>
Andy Lutomirski writes:
> On Wed, Jul 15, 2015 at 2:48 PM, Serge E. Hallyn wrote:
>> On Wed, Jul 15, 2015 at 02:46:04PM -0500, Seth Forshee wrote:
>>> Capability sets attached to files must be ignored except in the
>>> user namespaces where the mounter is privileged, i.e. s_user_ns
>>> and its d
On Wed, Jul 15, 2015 at 2:48 PM, Serge E. Hallyn wrote:
> On Wed, Jul 15, 2015 at 02:46:04PM -0500, Seth Forshee wrote:
>> Capability sets attached to files must be ignored except in the
>> user namespaces where the mounter is privileged, i.e. s_user_ns
>> and its descendants. Otherwise a vector e
On Wed, Jul 15, 2015 at 02:46:04PM -0500, Seth Forshee wrote:
> Capability sets attached to files must be ignored except in the
> user namespaces where the mounter is privileged, i.e. s_user_ns
> and its descendants. Otherwise a vector exists for gaining
> privileges in namespaces where a user is n
Capability sets attached to files must be ignored except in the
user namespaces where the mounter is privileged, i.e. s_user_ns
and its descendants. Otherwise a vector exists for gaining
privileges in namespaces where a user is not already privileged.
Add a new helper function, in_user_ns(), to te
17 matches
Mail list logo
