> Does ntpd need root for anything other than opening files/interfaces?
It doesn't even need it to open files if you set the permissions right.
Last I checked FreeBSD didn't have a way to allow non-root to set the system
clock.
Linix has a capability bit.
NetBSD has /dev/clockctl
--
These
> At least under Linux, you'd better trace kernel calls with ftrace, not
> strace. The newer kernels should have dtrace-like capabilities to tailor
> your probes.
What do I gain by using it? strace does exactly what I want -- it tells me
which syscalls are being used. I don't care about any
Hal Murray via devel writes:
> It seems obvious that we should drop root as early as possible. But it's not
> obvious that we should enable seccomp early.
Root should be dropped before ntpsec starts accepting network input.
Dropping it even earlier doesn't buy you much, since it'd only reduce
th
Hal Murray via devel writes:
> I'm working on a way to semi-automate generating the list. The basic idea is
> to run ntpd under strace on the type of system you are interested in to
> collect a lot of data, then run a script to extract the list of syscalls from
> the strace log file.
If you do
e...@thyrsus.com said:
> 46 to 55. If just 9 syscalls are the difference, the very slightly reduced
> assurance starts to look like a reasonable trade to make the whole problem go
> away.
That was comparing 2 lists from the same distro+version, just different
hardware platforms, so I'd expect
Hal Murray :
> I don't think it's worth the effort to maintain 2 lists. We can revisit that
> if you think it's appropriate.
No, I agree with you.
> There are 46 syscalls in each list and 55 in the merged list.
Brings up a question. Is the list of all syscalls used by everybody
large relative
> Is there anything preventing the possibility of an early looser
> seccomp setup and then tightening it later possibly with a knob
> to generate terse or verbose warnings instead of dying.
> Do you have an implementation strategy in mind?
The API, or the subset we are using, is:
This list
On Tue, Feb 25, 2020, at 1:37 PM Eric S. Raymond wrote:
>
> James Browning via devel :
> > Is there anything preventing the possibility of an early looser
> > seccomp setup and then tightening it later possibly with a knob
> > to generate terse or verbose warnings instead of dying.
>
> That is a v
James Browning via devel :
> Is there anything preventing the possibility of an early looser
> seccomp setup and then tightening it later possibly with a knob
> to generate terse or verbose warnings instead of dying.
That is a very interesting idea that I think deserves further
examination.
Do yo
On Tue, Feb 25, 2020, 7:37 AM Richard Laager via devel
wrote:
> On 2/24/20 11:02 PM, Hal Murray via devel wrote:
> > I'm looking at strace output. There are a few calls used only once or
> twice.
> >
> > It seems obvious that we should drop root as early as possible. But
> it's not
> > obvious
On 2/24/20 11:02 PM, Hal Murray via devel wrote:
> I'm looking at strace output. There are a few calls used only once or twice.
>
> It seems obvious that we should drop root as early as possible. But it's not
> obvious that we should enable seccomp early.
>
> If we turn on seccomp early, then
I'm looking at strace output. There are a few calls used only once or twice.
It seems obvious that we should drop root as early as possible. But it's not
obvious that we should enable seccomp early.
If we turn on seccomp early, then we have to allow all the syscalls used
during initialization
12 matches
Mail list logo
