On Thu, Oct 03, 2013 at 08:12:44AM +0200, Ingo Molnar wrote:
> So please first get consensus on this fundamental design question before
> spreading your solution to more areas.
Check file_ns_capable() added in commit 935d8aabd4331 by Linus
Add file_ns_capable() helper function for open-time capabi
On Wed, Oct 2, 2013 at 11:07 AM, Kees Cook wrote:
>
> On Wed, Oct 2, 2013 at 11:00 AM, Andy Lutomirski wrote:
> > On Wed, Oct 2, 2013 at 10:48 AM, Kees Cook wrote:
> >> On Wed, Oct 2, 2013 at 9:51 AM, Andy Lutomirski
> >> wrote:
> >>> On Wed, Oct 2, 2013 at 3:37 PM, Djalal Harouni wrote:
> >>
(Andy sorry for the delay, real life...)
On Thu, Oct 03, 2013 at 04:50:54PM +0100, Andy Lutomirski wrote:
> On Thu, Oct 3, 2013 at 4:40 PM, Djalal Harouni wrote:
> > On Thu, Oct 03, 2013 at 04:15:43PM +0100, Andy Lutomirski wrote:
> >> On Thu, Oct 3, 2013 at 1:29 PM, Djalal Harouni wrote:
> >> >
On Thu, Oct 3, 2013 at 4:40 PM, Djalal Harouni wrote:
> On Thu, Oct 03, 2013 at 04:15:43PM +0100, Andy Lutomirski wrote:
>> On Thu, Oct 3, 2013 at 1:29 PM, Djalal Harouni wrote:
>> > On Thu, Oct 03, 2013 at 08:12:44AM +0200, Ingo Molnar wrote:
>> >> Now procfs might be special, as by its nature o
On Thu, Oct 03, 2013 at 04:15:43PM +0100, Andy Lutomirski wrote:
> On Thu, Oct 3, 2013 at 1:29 PM, Djalal Harouni wrote:
> > On Thu, Oct 03, 2013 at 08:12:44AM +0200, Ingo Molnar wrote:
> >> Now procfs might be special, as by its nature of a pseudofilesystem it's
> >> far more atomic than other fi
On Thu, Oct 3, 2013 at 1:29 PM, Djalal Harouni wrote:
> On Thu, Oct 03, 2013 at 08:12:44AM +0200, Ingo Molnar wrote:
>>
>> * Djalal Harouni wrote:
>>
>> > > Regardless, glibc uses /proc/self/maps, which would be fine here, right?
>> >
>> > I did not touch /proc/self/maps and others, but I'm plann
* Djalal Harouni wrote:
> On Thu, Oct 03, 2013 at 08:22:56AM +0200, Ingo Molnar wrote:
> >
> > * Djalal Harouni wrote:
> >
> > > * You can't do it for /proc/*/stat otherwise you will break userspace
> > > "ps"..., ps must access /proc/1/stat etc... so the proposed solution
> > > will wor
On Thu, Oct 03, 2013 at 08:22:56AM +0200, Ingo Molnar wrote:
>
> * Djalal Harouni wrote:
>
> > * You can't do it for /proc/*/stat otherwise you will break userspace
> > "ps"..., ps must access /proc/1/stat etc... so the proposed solution
> > will work without any side effect.
>
> The thing
On Thu, Oct 03, 2013 at 08:12:44AM +0200, Ingo Molnar wrote:
>
> * Djalal Harouni wrote:
>
> > > Regardless, glibc uses /proc/self/maps, which would be fine here, right?
> >
> > I did not touch /proc/self/maps and others, but I'm planning to fix them
> > if this solution is accepted.
> >
> > I
* Djalal Harouni wrote:
> * You can't do it for /proc/*/stat otherwise you will break userspace
> "ps"..., ps must access /proc/1/stat etc... so the proposed solution
> will work without any side effect.
The thing is, returning -EINVAL is not the only way to reject access to
privileged in
* Djalal Harouni wrote:
> > Regardless, glibc uses /proc/self/maps, which would be fine here, right?
>
> I did not touch /proc/self/maps and others, but I'm planning to fix them
> if this solution is accepted.
>
> I'll do the same thing as in /proc/*/stat for maps, let it be 0444, and
> try t
On Wed, Oct 2, 2013 at 11:48 AM, Djalal Harouni wrote:
> On Wed, Oct 02, 2013 at 11:35:45AM -0700, Kees Cook wrote:
>> On Wed, Oct 2, 2013 at 11:22 AM, Djalal Harouni wrote:
>> > On Wed, Oct 02, 2013 at 10:48:55AM -0700, Kees Cook wrote:
>> >> On Wed, Oct 2, 2013 at 9:51 AM, Andy Lutomirski
>>
On Wed, Oct 02, 2013 at 11:35:45AM -0700, Kees Cook wrote:
> On Wed, Oct 2, 2013 at 11:22 AM, Djalal Harouni wrote:
> > On Wed, Oct 02, 2013 at 10:48:55AM -0700, Kees Cook wrote:
> >> On Wed, Oct 2, 2013 at 9:51 AM, Andy Lutomirski
> >> wrote:
> >> > On Wed, Oct 2, 2013 at 3:37 PM, Djalal Haroun
On Wed, Oct 02, 2013 at 07:26:43PM +0100, Djalal Harouni wrote:
> On Wed, Oct 02, 2013 at 11:00:26AM -0700, Andy Lutomirski wrote:
> > On Wed, Oct 2, 2013 at 10:48 AM, Kees Cook wrote:
> > > I think revoking the fd would be great. Does that mechanism exist?
> >
> > There's this thing that never g
On Wed, Oct 2, 2013 at 11:22 AM, Djalal Harouni wrote:
> On Wed, Oct 02, 2013 at 10:48:55AM -0700, Kees Cook wrote:
>> On Wed, Oct 2, 2013 at 9:51 AM, Andy Lutomirski wrote:
>> > On Wed, Oct 2, 2013 at 3:37 PM, Djalal Harouni wrote:
>> >> On Tue, Oct 01, 2013 at 06:40:41PM -0700, Andy Lutomirski
On Wed, Oct 02, 2013 at 11:00:26AM -0700, Andy Lutomirski wrote:
> On Wed, Oct 2, 2013 at 10:48 AM, Kees Cook wrote:
> > On Wed, Oct 2, 2013 at 9:51 AM, Andy Lutomirski wrote:
> >> On Wed, Oct 2, 2013 at 3:37 PM, Djalal Harouni wrote:
> >>> On Tue, Oct 01, 2013 at 06:40:41PM -0700, Andy Lutomirs
On Wed, Oct 02, 2013 at 10:48:55AM -0700, Kees Cook wrote:
> On Wed, Oct 2, 2013 at 9:51 AM, Andy Lutomirski wrote:
> > On Wed, Oct 2, 2013 at 3:37 PM, Djalal Harouni wrote:
> >> On Tue, Oct 01, 2013 at 06:40:41PM -0700, Andy Lutomirski wrote:
> >>> On 10/01/2013 01:26 PM, Djalal Harouni wrote:
>
On Wed, Oct 02, 2013 at 05:51:15PM +0100, Andy Lutomirski wrote:
> On Wed, Oct 2, 2013 at 3:37 PM, Djalal Harouni wrote:
> > On Tue, Oct 01, 2013 at 06:40:41PM -0700, Andy Lutomirski wrote:
> >> On 10/01/2013 01:26 PM, Djalal Harouni wrote:
> >> > /proc//* entries varies at runtime, appropriate pe
On Wed, Oct 2, 2013 at 11:00 AM, Andy Lutomirski wrote:
> On Wed, Oct 2, 2013 at 10:48 AM, Kees Cook wrote:
>> On Wed, Oct 2, 2013 at 9:51 AM, Andy Lutomirski wrote:
>>> On Wed, Oct 2, 2013 at 3:37 PM, Djalal Harouni wrote:
On Tue, Oct 01, 2013 at 06:40:41PM -0700, Andy Lutomirski wrote:
>
On Wed, Oct 2, 2013 at 10:48 AM, Kees Cook wrote:
> On Wed, Oct 2, 2013 at 9:51 AM, Andy Lutomirski wrote:
>> On Wed, Oct 2, 2013 at 3:37 PM, Djalal Harouni wrote:
>>> On Tue, Oct 01, 2013 at 06:40:41PM -0700, Andy Lutomirski wrote:
On 10/01/2013 01:26 PM, Djalal Harouni wrote:
> /proc
On Wed, Oct 2, 2013 at 9:51 AM, Andy Lutomirski wrote:
> On Wed, Oct 2, 2013 at 3:37 PM, Djalal Harouni wrote:
>> On Tue, Oct 01, 2013 at 06:40:41PM -0700, Andy Lutomirski wrote:
>>> On 10/01/2013 01:26 PM, Djalal Harouni wrote:
>>> > /proc//* entries varies at runtime, appropriate permission che
On Wed, Oct 2, 2013 at 3:37 PM, Djalal Harouni wrote:
> On Tue, Oct 01, 2013 at 06:40:41PM -0700, Andy Lutomirski wrote:
>> On 10/01/2013 01:26 PM, Djalal Harouni wrote:
>> > /proc//* entries varies at runtime, appropriate permission checks
>> > need to happen during each system call.
>> >
>> > Cu
On Tue, Oct 01, 2013 at 06:40:41PM -0700, Andy Lutomirski wrote:
> On 10/01/2013 01:26 PM, Djalal Harouni wrote:
> > /proc//* entries varies at runtime, appropriate permission checks
> > need to happen during each system call.
> >
> > Currently some of these sensitive entries are protected by perf
On 10/01/2013 01:26 PM, Djalal Harouni wrote:
> /proc//* entries varies at runtime, appropriate permission checks
> need to happen during each system call.
>
> Currently some of these sensitive entries are protected by performing
> the ptrace_may_access() check. However even with that the /proc fi
/proc//* entries varies at runtime, appropriate permission checks
need to happen during each system call.
Currently some of these sensitive entries are protected by performing
the ptrace_may_access() check. However even with that the /proc file
descriptors can be passed to a more privileged proces
25 matches
Mail list logo
