[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: file(1) now with seccomp support enabled



Philipp Kern wrote...

> That being said: It feels like if you face this situation, you could also
> fork off a binary with a clean environment (i.e. without LD_PRELOAD) and
> minimal dependencies and only protect that with seccomp. Of course you lose
> the integration point of LD_PRELOAD that others might want to use if you do
> that, in which case I guess one could offer a flag to skip that fork.

... and I'm back at a point where I've already been: The default has to 
be the secure way else it's not worth the time. So if application really
would break otherwise and can with some reason trade the security,
they'll either have to provide that flag (patching, patching), or 
file(1) would have to detect that situation (hacky, fragile).

> In terms of prior art SSH also forks off an unprivileged worker to handle
> network authentication in preauth and only seccomps that one rather than its
> main process. But it's also not doing the environment cleanup AFAICS.

Yeah, but as I already wrote here, this requires some sorts of IPC and
of lot of joys come with it.

> Kind regards and thanks for making all of us more secure! :)

Trying my best but my hopes are getting low.

    Christoph

Attachment: signature.asc
Description: PGP signature


Reply to: