Re: [systemd-devel] Seeking advice for configuring SystemCallFilter=

2016-01-25 Thread Lennart Poettering 
On Fri, 22.01.16 21:17, David Timothy Strauss (da...@davidstrauss.net) wrote:

> Rebooting an old thread now that we're finally testing this out.
> 
> > "strace" should do the job. It should give you a pretty good idea of all
> syscalls a process uses. That's what I used when testing SyscallFilters=.
> 
> This turns out to be less useful than it seems.
> 
> There are two major ways to invoke strace, each with caveats:
> 
>- Launch the process with strace. This captures everything from the
>first syscall to daemonized operation, but it's hard to create an
>equivalent context and environment versus how the service runs normally.
>This is especially bad for socket-activated services because those may
>actually use fewer or different syscalls than if they have to open their
>own listener sockets.
>- Attach to an existing process. This allows seeing behavior under
>systemd, but it misses early service startup because the PID is only
>knowable after the service has started. We've specifically seen issues
>where some syscalls are only used in early service startup.
> 
> It would be useful if systemd could help packagers, developers, and
> administrators configure better sandboxes for services by, say, using
> strace (or equivalent) to capture any unique syscalls in use, starting from
> the beginning of execution. This wouldn't be the normal mode of operation,
> but maybe part of a service profiling mode or a property in unit files.

strace -D from the ExecStart= line should work.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Seeking advice for configuring SystemCallFilter=

2016-01-22 Thread David Timothy Strauss 
Rebooting an old thread now that we're finally testing this out.

> "strace" should do the job. It should give you a pretty good idea of all
syscalls a process uses. That's what I used when testing SyscallFilters=.

This turns out to be less useful than it seems.

There are two major ways to invoke strace, each with caveats:

   - Launch the process with strace. This captures everything from the
   first syscall to daemonized operation, but it's hard to create an
   equivalent context and environment versus how the service runs normally.
   This is especially bad for socket-activated services because those may
   actually use fewer or different syscalls than if they have to open their
   own listener sockets.
   - Attach to an existing process. This allows seeing behavior under
   systemd, but it misses early service startup because the PID is only
   knowable after the service has started. We've specifically seen issues
   where some syscalls are only used in early service startup.

It would be useful if systemd could help packagers, developers, and
administrators configure better sandboxes for services by, say, using
strace (or equivalent) to capture any unique syscalls in use, starting from
the beginning of execution. This wouldn't be the normal mode of operation,
but maybe part of a service profiling mode or a property in unit files.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Seeking advice for configuring SystemCallFilter=

2016-01-22 Thread Mantas Mikulėnas 
On Fri, Jan 22, 2016 at 11:17 PM, David Timothy Strauss <
da...@davidstrauss.net> wrote:

> Rebooting an old thread now that we're finally testing this out.
>
> > "strace" should do the job. It should give you a pretty good idea of all
> syscalls a process uses. That's what I used when testing SyscallFilters=.
>
> This turns out to be less useful than it seems.
>
> There are two major ways to invoke strace, each with caveats:
>
>- Launch the process with strace. This captures everything from the
>first syscall to daemonized operation, but it's hard to create an
>equivalent context and environment versus how the service runs normally.
>This is especially bad for socket-activated services because those may
>actually use fewer or different syscalls than if they have to open their
>own listener sockets.
>- Attach to an existing process. This allows seeing behavior under
>systemd, but it misses early service startup because the PID is only
>knowable after the service has started. We've specifically seen issues
>where some syscalls are only used in early service startup.
>
> There's a third way:

ExecStart=/usr/bin/strace -D -ff -o /tmp/myservice.trace /usr/bin/myservlce
--foo

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Seeking advice for configuring SystemCallFilter=

2016-01-22 Thread David Timothy Strauss 
On Fri, Jan 22, 2016 at 1:36 PM Mantas Mikulėnas  wrote:

> There's a third way:
>
> ExecStart=/usr/bin/strace -D -ff -o /tmp/myservice.trace
> /usr/bin/myservlce --foo
>

Do you know if that would pass through file descriptors for socket
activation?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Seeking advice for configuring SystemCallFilter=

2016-01-22 Thread Mantas Mikulėnas 
On Fri, Jan 22, 2016 at 11:47 PM, David Timothy Strauss <
da...@davidstrauss.net> wrote:

> On Fri, Jan 22, 2016 at 1:36 PM Mantas Mikulėnas 
> wrote:
>
>> There's a third way:
>>
>> ExecStart=/usr/bin/strace -D -ff -o /tmp/myservice.trace
>> /usr/bin/myservlce --foo
>>
>
> Do you know if that would pass through file descriptors for socket
> activation?
>

Yeah, fd's are passed by default and strace doesn't do anything special
with them.

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Seeking advice for configuring SystemCallFilter=

2014-08-14 Thread Lennart Poettering 
On Tue, 08.07.14 17:33, David Timothy Strauss (da...@davidstrauss.net) wrote:

 Is there a good way to empirically determine the additional calls
 required for an application, sort of like selinux permissive mode?
 We're often running user code on our servers, and we'd like to perform
 analysis and gradually roll out filtering. We'd like to be as
 non-disruptive as possible.

strace should do the job. It should give you a pretty good idea of all
syscalls a process uses. That's what I used when testing SyscallFilters=.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Seeking advice for configuring SystemCallFilter=

2014-07-08 Thread David Timothy Strauss 
Is there a good way to empirically determine the additional calls
required for an application, sort of like selinux permissive mode?
We're often running user code on our servers, and we'd like to perform
analysis and gradually roll out filtering. We'd like to be as
non-disruptive as possible.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel