lkml.org 
[lkml]   [2009]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: RFC: disablenetwork facility. (v4)
From
Date
"Serge E. Hallyn" <serue@us.ibm.com> writes:

> Quoting Eric W. Biederman (ebiederm@xmission.com):
>> "Serge E. Hallyn" <serue@us.ibm.com> writes:
>>
>> >> In common cap we drop the new capabilities if we are being ptraced.
>> >> Look for brm->unsafe.
>> >
>> > Yes - that isn't the issue.
>>
>> Right. Sorry. I saw that we set unsafe and totally
>> missed that we don't act on it in that case.
>>
>> > It goes back to finding a way to figure out what is inside the
>> > file when the installer obviously thought we shouldn't be able
>> > to read the file.
>> >
>> > Do we care? <shrug>
>>
>> <shrug>
>>
>> I expect two lines of testing bprm->unsafe and failing
>> at the right point would solve that.
>
> But what is the right response? Prevent excecution? Stop the
> tracer? Enter some one-shot mode where the whole exec appears
> as one step, but tracing continues if execution continues on a
> dumpable file?

The whole exec should already appear as one step.

The right response is to either fail the exec or disable
the tracer. Since the other case drops privs. I expect
failing the exec is the simplest and most consistent thing
we can do.

Eric


\
 
 \ /
  Last update: 2009-12-30 22:15    [from the cache]
©2003-2011 Jasper Spaans