Hal Murray :
>
> e...@thyrsus.com said:
> > Aaarrgghhh. It;s a huge pain in the ass and I wish it weren't interesting.
> > But given our mission statememnnt, it has to be.
>
> Just to make sure we are on the same wavelength...
>
> My question/proposal was not to drop seccomp if we didn't do wh
Hal Murray :
> The first quirk is that ntpd isn't on the #include search path.
> (My hack was to put a link from include to ntpd/seccomp)
> What's the right way to handle this? (Maybe I just fatfingered things.)
Generating the requred stuff into include, where all the headers live,
ought to work.
e...@thyrsus.com said:
> Aaarrgghhh. It;s a huge pain in the ass and I wish it weren't interesting.
> But given our mission statememnnt, it has to be.
Just to make sure we are on the same wavelength...
My question/proposal was not to drop seccomp if we didn't do what I sketched
out. It was
Yo Hal!
On Tue, 26 May 2020 18:23:55 -0700
Hal Murray via devel wrote:
> I was thinking of putting the individual lists in ntpd/seccomp/
> with something like
> #include "seccomp/foo.c"
> in ntp_sandbox.
Why not just load a text file at runtime during startup?
seccomp does not protect agains
e...@thyrsus.com said:
>> If yes, I'll need some help to work out the details.
> Aaarrgghhh. It;s a huge pain in the ass and I wish it weren't interesting.
> But given our mission statememnnt, it has to be.
OK. Let's discuss how to do it.
I was thinking of putting the individual lists in ntp
Hal Murray via devel :
>
> I've been experimenting with some code to allow custom scccomp lists.
>
> The idea is to replace the --enable-seccomp configure option with
> --enable-seccomp=foo
> and ntp_sandbox would include syscomp/foo.c which would be a list of syscalls
> used by this system.
>
Richard said:
> I do not. It seems really fragile to me. A change in an underlying library
> can break a working binary, possibly only in some scenarios. That's scary.
> It'd be safer (but still not completely safe) to enable if I had good (or
> any) "as installed" tests using Debian's autopkgt
Richard Laager via devel writes:
> I do not. It seems really fragile to me. A change in an underlying
> library can break a working binary, possibly only in some scenarios.
> That's scary.
It's also somewhat the point of using it: any un-audited change rather
breaks the application than the system
On 2/23/20 4:59 AM, Hal Murray via devel wrote:
> Should we drop secomp? It's a pain to maintain.
I wouldn't cry.
> How many people use it? Richard: do you turn it on for the Debian builds?
I do not. It seems really fragile to me. A change in an underlying
library can break a working binary, p
e...@thyrsus.com said:
[dropping seccomp]
> We're a security-focused prodict. I don't think it would be good optics to
> drop a layer of defense just because it's a pain to maintain.
Have you considered the lost opportunity cost?
This current approach of tossing everything in gives is braggin
Hal Murray via devel :
> Should we drop secomp? It's a pain to maintain.
We're a security-focused prodict. I don't think it would be good optics
to drop a layer of defense just because it's a pain to maintain.
> How many people use it? Richard: do you turn it on for the Debian builds?
I have
11 matches
Mail list logo
