6:58 a.m.
In chrony 2.2-pre1 was added support for system call filtering with
the kernel seccomp facility. In chrony it's mainly useful to reduce
the damage from attackers who can execute arbitrary code, e.g. prevent
gaining the root privileges through a kernel vulnerability.
The rawhide chrony package is now compiled with the seccomp support,
but the filtering is not enabled by default. The trouble is it has to
cover all system calls needed in all possible configurations of chrony
and all libraries it depends on, which is difficult and it may even
change over time as the libraries are updated.
I'm interested to know if this works in other configurations than what
I tried, especially non-default NSS configurations, and get an idea if
this could be enabled by default at some point.
If you would like to help with the testing:
1. echo 'OPTIONS="-F -1"' > /etc/sysconfig/chronyd
2. systemctl restart chronyd
3. occasionally check if chronyd is still running
If you see in the log that the process was killed with status=31/SYS,
it's a problem in the seccomp support. Please let me know it has
crashed for you. Unfortunately, abrt doesn't seem to catch these
crashes, even when /proc/sys/fs/suid_dumpable is set to 2.
For F22 and F23 there is a COPR repo with packages built from the
current development code:
https://copr.fedoraproject.org/coprs/mlichvar/chrony/
Thanks,
--
Miroslav Lichvar
8:23 a.m.
On Mon, 2015-10-05 at 13:58 +0200, Miroslav Lichvar wrote:
The rawhide chrony package is now compiled with the seccomp support,
but the filtering is not enabled by default. The trouble is it has to
cover all system calls needed in all possible configurations of
chrony
and all libraries it depends on, which is difficult and it may even
change over time as the libraries are updated.
Yes; depending on your dependencies (...yeah!) this could be highly
problematic. As you say, it imposes the requirement that all of your
dependencies in Fedora never begin to use new syscalls, and never use
syscalls in unexpected ways, over the supported lifetime of a Fedora
release, or bundle their updates with corresponding chrony updates if
they do. Frankly it's a recipe for disaster, given that many
maintainers submit major version updates in flagrant disregard for our
current updates policy, and using seccomp would require tightening the
updates policy much more (since it makes minor version updates quite
risky -- but we still want to do those...), but the security benefits
of seccomp are huge so it's possibly worth working towards....
Random example: when I was testing WebKit's experimental seccomp mode
in Fedora 21, the maintainers of libxshmfence submitted an update to
start using the new syscall memfd_create() rather than putting shared
memory in /var/tmp. That's an acceptable update under all of our
guidelines, since that's an implementation detail that ordinarily
wouldn't affect programs, but it caused WebKit to crash on start, and
would have broken pretty much anything else using libxshmfence and
seccomp, since programs aren't going to have whitelisted a syscall that
was not previously used (and in this case, didn't even exist when it
was written). With chrony using seccomp, its dependencies must never do
such a thing (except in rawhide).
(Also fun is to try making the same list of filters work across
distros.)
So chrony might work perfectly now, but who knows how broken it will be
after a couple months of updates.... Well, you'll find out after
testing it in rawhide. Hope seccomp works better for you than it did
for me. Of course, for programs with few dependencies, there's not
really much problem.
Michael
9:02 a.m.
On Oct 5, 2015 6:23 AM, "Michael Catanzaro" <mcatanzaro(a)gnome.org> wrote:
On Mon, 2015-10-05 at 13:58 +0200, Miroslav Lichvar wrote:
> The rawhide chrony package is now compiled with the seccomp support,
> but the filtering is not enabled by default. The trouble is it has to
> cover all system calls needed in all possible configurations of
> chrony
> and all libraries it depends on, which is difficult and it may even
> change over time as the libraries are updated.
Yes; depending on your dependencies (...yeah!) this could be highly
problematic. As you say, it imposes the requirement that all of your
dependencies in Fedora never begin to use new syscalls, and never use
syscalls in unexpected ways, over the supported lifetime of a Fedora
release, or bundle their updates with corresponding chrony updates if
they do. Frankly it's a recipe for disaster, given that many
maintainers submit major version updates in flagrant disregard for our
current updates policy, and using seccomp would require tightening the
updates policy much more (since it makes minor version updates quite
risky -- but we still want to do those...), but the security benefits
of seccomp are huge so it's possibly worth working towards....
Why is the filter causing SIGSYS instead of forcing an ENOSYS return?
I'll look into the abrt thing. It might be an easy fix.
--Andy
Random example: when I was testing WebKit's experimental seccomp mode
in Fedora 21, the maintainers of libxshmfence submitted an update to
start using the new syscall memfd_create() rather than putting shared
memory in /var/tmp. That's an acceptable update under all of our
guidelines, since that's an implementation detail that ordinarily
wouldn't affect programs, but it caused WebKit to crash on start, and
would have broken pretty much anything else using libxshmfence and
seccomp, since programs aren't going to have whitelisted a syscall that
was not previously used (and in this case, didn't even exist when it
was written). With chrony using seccomp, its dependencies must never do
such a thing (except in rawhide).
(Also fun is to try making the same list of filters work across
distros.)
So chrony might work perfectly now, but who knows how broken it will be
after a couple months of updates.... Well, you'll find out after
testing it in rawhide. Hope seccomp works better for you than it did
for me. Of course, for programs with few dependencies, there's not
really much problem.
Michael
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
10:25 a.m.
On Mon, 2015-10-05 at 07:02 -0700, Andrew Lutomirski wrote:
Why is the filter causing SIGSYS instead of forcing an ENOSYS
return?
I'll look into the abrt thing. It might be an easy fix.
--Andy
Simply because it's an experimental project, and it's much easier to
crash with a core dump so it can be debugged, than to have obscure
failures all over the place.
10:56 a.m.
On Mon, Oct 5, 2015 at 8:25 AM, Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
On Mon, 2015-10-05 at 07:02 -0700, Andrew Lutomirski wrote:
> Why is the filter causing SIGSYS instead of forcing an ENOSYS return?
>
> I'll look into the abrt thing. It might be an easy fix.
>
> --Andy
Simply because it's an experimental project, and it's much easier to
crash with a core dump so it can be debugged, than to have obscure
failures all over the place.
For deployment, though, I think the other approach is better. If,
say, memfd_create returns ENOSYS, most libraries will fall back to
older mechanisms.
--Andy
10:27 a.m.
On Mon, Oct 05, 2015 at 08:23:05AM -0500, Michael Catanzaro wrote:
(Also fun is to try making the same list of filters work across
distros.)
And across supported architectures. So far, I tested it only on x86_64
and i686 and there were quite a few differences. I would be surprised
if it worked on arm even in the default configuration :).
So chrony might work perfectly now, but who knows how broken it will
be
after a couple months of updates.... Well, you'll find out after
testing it in rawhide. Hope seccomp works better for you than it did
for me. Of course, for programs with few dependencies, there's not
really much problem.
I guess glibc and getaddrinfo() will be the most problematic part in
the chrony seccomp support. Is there a precedent in Fedora of a
package using a seccomp filter and getaddrinfo() by default?
If we can't enable it by default, I'll be ok with that. Currently I'm
just interested in how it works for others.
Another possibility is to add a new level to the chrony seccomp
support that would use a blacklisting approach, disabling syscalls or
their arguments that historically are most dangerous and we can be
sure won't be ever needed. I hope that's not an empty set.
--
Miroslav Lichvar
10:31 a.m.
On Mon, 2015-10-05 at 17:27 +0200, Miroslav Lichvar wrote:
Another possibility is to add a new level to the chrony seccomp
support that would use a blacklisting approach, disabling syscalls or
their arguments that historically are most dangerous and we can be
sure won't be ever needed. I hope that's not an empty set.
Sandstorm and systemd-nspawn have lists like that, if you want to
investigate them... of course, the security benefits are much less, but
it's better than no seccomp and you don't have to worry much about
compatibility issues. No reason for chrony to be using kexec, for
example.
3:15 a.m.
On 10/05/2015 05:27 PM, Miroslav Lichvar wrote:
I guess glibc and getaddrinfo() will be the most problematic part in
the chrony seccomp support. Is there a precedent in Fedora of a
package using a seccomp filter and getaddrinfo() by default?
getaddrinfo uses NSS under the cover, which loads NSS modules and runs
their code to perform lookups. The system configuration may even use
modules which do not come with the distribution.
You need to run getaddrinfo from a separate process/thread which lacks a
seccomp filter.
Florian
8:22 a.m.
On Tue, Oct 06, 2015 at 10:15:38AM +0200, Florian Weimer wrote:
On 10/05/2015 05:27 PM, Miroslav Lichvar wrote:
> I guess glibc and getaddrinfo() will be the most problematic part in
> the chrony seccomp support. Is there a precedent in Fedora of a
> package using a seccomp filter and getaddrinfo() by default?
getaddrinfo uses NSS under the cover, which loads NSS modules and runs
their code to perform lookups. The system configuration may even use
modules which do not come with the distribution.
You need to run getaddrinfo from a separate process/thread which lacks a
seccomp filter.
FWIW, the latest upstream code now does name resolving in a separate
process as you have suggested. Since the original post I already had
to add some system calls that were apparently made with some NSS
configurations. Hopefully it will be more reliable now. The COPR has a
build of the current code if anyone is interested in testing.
Thanks,
--
Miroslav Lichvar
2:24 a.m.
On Mon, 5 Oct 2015 13:58:26 +0200
Miroslav Lichvar <mlichvar(a)redhat.com> wrote:
In chrony 2.2-pre1 was added support for system call filtering with
the kernel seccomp facility. In chrony it's mainly useful to reduce
the damage from attackers who can execute arbitrary code, e.g. prevent
gaining the root privileges through a kernel vulnerability.
please keep in mind that libseccomp currently supports only limited set
of architectures -
http://pkgs.fedoraproject.org/cgit/libseccomp.git/tree/libseccomp.spec#n5
It will change (in Rawhide) after mainline kernel 4.3 release when s390
and ppc will become supported as well.
Dan
The rawhide chrony package is now compiled with the seccomp support,
but the filtering is not enabled by default. The trouble is it has to
cover all system calls needed in all possible configurations of chrony
and all libraries it depends on, which is difficult and it may even
change over time as the libraries are updated.
I'm interested to know if this works in other configurations than what
I tried, especially non-default NSS configurations, and get an idea if
this could be enabled by default at some point.
If you would like to help with the testing:
1. echo 'OPTIONS="-F -1"' > /etc/sysconfig/chronyd
2. systemctl restart chronyd
3. occasionally check if chronyd is still running
If you see in the log that the process was killed with status=31/SYS,
it's a problem in the seccomp support. Please let me know it has
crashed for you. Unfortunately, abrt doesn't seem to catch these
crashes, even when /proc/sys/fs/suid_dumpable is set to 2.
For F22 and F23 there is a COPR repo with packages built from the
current development code:
https://copr.fedoraproject.org/coprs/mlichvar/chrony/
Thanks,
--
Miroslav Lichvar
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
7:13 a.m.
On Wed, Oct 07, 2015 at 09:24:22AM +0200, Dan Horák wrote:
On Mon, 5 Oct 2015 13:58:26 +0200
Miroslav Lichvar <mlichvar(a)redhat.com> wrote:
> In chrony 2.2-pre1 was added support for system call filtering with
> the kernel seccomp facility. In chrony it's mainly useful to reduce
> the damage from attackers who can execute arbitrary code, e.g. prevent
> gaining the root privileges through a kernel vulnerability.
please keep in mind that libseccomp currently supports only limited set
of architectures -
http://pkgs.fedoraproject.org/cgit/libseccomp.git/tree/libseccomp.spec#n5
It will change (in Rawhide) after mainline kernel 4.3 release when s390
and ppc will become supported as well.
The chrony spec should now follow that. Thanks.
--
Miroslav Lichvar
7:20 a.m.
On Wed, 7 Oct 2015 14:13:36 +0200
Miroslav Lichvar <mlichvar(a)redhat.com> wrote:
On Wed, Oct 07, 2015 at 09:24:22AM +0200, Dan Horák wrote:
> On Mon, 5 Oct 2015 13:58:26 +0200
> Miroslav Lichvar <mlichvar(a)redhat.com> wrote:
>
> > In chrony 2.2-pre1 was added support for system call filtering
> > with the kernel seccomp facility. In chrony it's mainly useful to
> > reduce the damage from attackers who can execute arbitrary code,
> > e.g. prevent gaining the root privileges through a kernel
> > vulnerability.
>
> please keep in mind that libseccomp currently supports only limited
> set of architectures -
> http://pkgs.fedoraproject.org/cgit/libseccomp.git/tree/libseccomp.spec#n5
> It will change (in Rawhide) after mainline kernel 4.3 release when
> s390 and ppc will become supported as well.
The chrony spec should now follow that. Thanks.
thanks, once the support lands in libseccomp, we (aka the secondary
arch team) will be going over the packages that use libseccomp in
buildroots and remove the exceptions
Dan
4:02 a.m.
On Mon, 2015-10-05 at 13:58 +0200, Miroslav Lichvar wrote:
In chrony 2.2-pre1 was added support for system call filtering with
the kernel seccomp facility. In chrony it's mainly useful to reduce
the damage from attackers who can execute arbitrary code, e.g.
prevent
gaining the root privileges through a kernel vulnerability.
The rawhide chrony package is now compiled with the seccomp support,
but the filtering is not enabled by default. The trouble is it has to
cover all system calls needed in all possible configurations of
chrony
and all libraries it depends on, which is difficult and it may even
change over time as the libraries are updated.
As Florian suggested it makes more sense to compartmentalize chrony so
that only a small controlled part of it needs to run with seccomp. My
recommendation, if you want to use libraries in the filtered code, make
their authors aware of that, so that they document any changes in the
used system calls, and if possible ask them to document the existing
system calls used (e.g., similarly to:
http://www.gnutls.org/manual/html_node/Running-in-a-sandbox.html )
regards,
Nikos
5:51 a.m.
On 01/18/2016 11:02 AM, Nikos Mavrogiannopoulos wrote:
As Florian suggested it makes more sense to compartmentalize chrony
so
that only a small controlled part of it needs to run with seccomp. My
recommendation, if you want to use libraries in the filtered code, make
their authors aware of that, so that they document any changes in the
used system calls, and if possible ask them to document the existing
system calls used (e.g., similarly to:
http://www.gnutls.org/manual/html_node/Running-in-a-sandbox.html )
Interesting. There is one huge caveat:
| As well as an calls needed for memory allocation to work.
glibc malloc can basically call *anything*. We don't know what the
future will bring. Currently, we use (off the top of my head, I haven't
checked):
* sbrk
* mmap
* mprotect
* munmap
* mremap
* madvise
* futex
* open
* read
* close
(In some cases, there is some sort of fallback, or errors are ignored
and the optimization does not happen.)
Future versions might reasonably use:
* sched_getcpu
* clone
* clock_gettime
* more open/read/close
* readlink
* whatever system calls are used for memory protection keys
* whatever system calls are used for restartable sequences
I appreciate what you are trying to do, but those seccomp filters
totally break encapsulation. I have no idea how to support this
properly, in a sustainable way. It appears very difficult to do this
for independently evolving libraries.
Florian
9:02 a.m.
On Mon, 2016-01-18 at 12:51 +0100, Florian Weimer wrote:
On 01/18/2016 11:02 AM, Nikos Mavrogiannopoulos wrote:
> As Florian suggested it makes more sense to compartmentalize chrony
> so
> that only a small controlled part of it needs to run with seccomp.
> My
> recommendation, if you want to use libraries in the filtered code,
> make
> their authors aware of that, so that they document any changes in
> the
> used system calls, and if possible ask them to document the
> existing
> system calls used (e.g., similarly to:
> http://www.gnutls.org/manual/html_node/Running-in-a-sandbox.html )
Interesting. There is one huge caveat:
> As well as an calls needed for memory allocation to work.
glibc malloc can basically call *anything*. We don't know what the
future will bring. Currently, we use (off the top of my head, I
haven't checked):
* sbrk
* mmap
* mprotect
* munmap
* mremap
* madvise
* futex
* open
* read
* close
(In some cases, there is some sort of fallback, or errors are ignored
and the optimization does not happen.)
Future versions might reasonably use:
* sched_getcpu
* clone
* clock_gettime
* more open/read/close
* readlink
* whatever system calls are used for memory protection keys
* whatever system calls are used for restartable sequences
I appreciate what you are trying to do, but those seccomp filters
totally break encapsulation. I have no idea how to support this
properly, in a sustainable way. It appears very difficult to do this
for independently evolving libraries.
Could that be handled by libseccomp provided some input from glibc
(e.g., with some coordination, or glibc keeping the system calls it
uses fixed across minor updates)? Otherwise the alternative is for
programs not using seccomp and enabling all system calls to code
handling untrusted input.
regards,
Nikos
9:51 a.m.
On Mon, 2016-01-18 at 12:51 +0100, Florian Weimer wrote:
glibc malloc can basically call *anything*. We don't know what
the
future will bring. Currently, we use (off the top of my head, I
haven't
checked):
* sbrk
* mmap
* mprotect
* munmap
* mremap
* madvise
* futex
* open
* read
* close
(In some cases, there is some sort of fallback, or errors are ignored
and the optimization does not happen.)
Future versions might reasonably use:
* sched_getcpu
* clone
* clock_gettime
* more open/read/close
* readlink
* whatever system calls are used for memory protection keys
* whatever system calls are used for restartable sequences
I appreciate what you are trying to do, but those seccomp filters
totally break encapsulation. I have no idea how to support this
properly, in a sustainable way. It appears very difficult to do this
for independently evolving libraries.
No matter what, any seccomp whitelist is doomed to break in the future
if your program uses shared libraries (including glibc). I think
seccomp filters can reasonably be used with a blacklist of syscalls,
but not with a whitelist.
An anecdote: in WebKit (which has a seccomp filter sandbox not compiled
by default, because it is unfinished and very fragile), the web process
receives SIGSYS from seccomp when it calls open() or a related
function, which it does not have permission to use; it then passes the
filename of the file it wants to open via IPC to a broker process,
which evaluates our filesystem policy, opens the file (if permissible),
and sends the fd to the web process via a UNIX socket. This all goes
awry if, in the web process's signal handler, malloc decides to call
open(), triggering an infinite loop of SIGSYS handlers. So we have to
open all files used by malloc (currently /proc/sys/vm/overcommit_memory
and /sys/devices/system/cpu/online) and cache the fds in the web
process before initializing seccomp filters. libseccomp could not help
with that, since there are so many different ways to use seccomp; it
doesn't know anything about our broker processs.
The lesson: seccomp is also unsuitable for restricting access to the
filesystem, and it's always going to be difficult to use in application
programs. The best way to use it is probably via a library that only
blacklists a few syscalls, and which can handle complicated problems
like malloc for applications.
Michael
3:16 a.m.
New subject: seccomp support [was: Testing chrony seccomp support]
On Mon, 2016-01-18 at 09:51 -0600, Michael Catanzaro wrote:
> I appreciate what you are trying to do, but those seccomp
filters
> totally break encapsulation. I have no idea how to support this
> properly, in a sustainable way. It appears very difficult to do
> this
> for independently evolving libraries.
No matter what, any seccomp whitelist is doomed to break in the
future
if your program uses shared libraries (including glibc). I think
seccomp filters can reasonably be used with a blacklist of syscalls,
but not with a whitelist.
The issue is that blacklists are terrible from a security standpoint.
That means that every new obscure system call added to the kernel will
be available by default in your program.
An anecdote: in WebKit (which has a seccomp filter sandbox not
compiled
by default, because it is unfinished and very fragile), the web
process
receives SIGSYS from seccomp when it calls open() or a related
function, which it does not have permission to use; it then passes
the
filename of the file it wants to open via IPC to a broker process,
which evaluates our filesystem policy, opens the file (if
permissible),
and sends the fd to the web process via a UNIX socket. This all goes
awry if, in the web process's signal handler, malloc decides to call
open(), triggering an infinite loop of SIGSYS handlers. So we have to
open all files used by malloc (currently
/proc/sys/vm/overcommit_memory
and /sys/devices/system/cpu/online) and cache the fds in the web
process before initializing seccomp filters. libseccomp could not
help
with that, since there are so many different ways to use seccomp; it
doesn't know anything about our broker processs.
That does sound like a very fragile usage of seccomp indeed. It could
be solved of course by using IPC to open a file rather than relying on
the signal. In any case seccomp certainly requires a program to be
restructured or designed in a way to have a limited to syscall
requirements component to have seccomp enabled (e.g., only to glibc).
If you cannot have that then seccomp is probably not the answer.
Then the question for programs wanting to use glibc and seccomp would
be, could libc keep the syscalls fixed for its wrapper of system calls,
or could we have filters which are applied to glibc's calls rather than
system calls? Otherwise the only remaining solution would be for
applications requiring seccomp to switch to thinner libc variants.
regards,
Nikos
9:41 a.m.
New subject: seccomp support [was: Testing chrony seccomp support]
On Tue, Jan 19, 2016, at 04:16 AM, Nikos Mavrogiannopoulos wrote:
The issue is that blacklists are terrible from a security
standpoint.
That means that every new obscure system call added to the kernel will
be available by default in your program.
https://github.com/seccomp/libseccomp/issues/11
10:08 a.m.
New subject: seccomp support [was: Testing chrony seccomp support]
On Jan 19, 2016 7:41 AM, "Colin Walters" <walters(a)verbum.org> wrote:
On Tue, Jan 19, 2016, at 04:16 AM, Nikos Mavrogiannopoulos wrote:
> The issue is that blacklists are terrible from a security standpoint.
> That means that every new obscure system call added to the kernel will
> be available by default in your program.
https://github.com/seccomp/libseccomp/issues/11
One of these days I need to tidy up Sandstorm's seccomp policy and factor
it into its own library. It's made a good showing for itself over the last
year or so, and it's highly compatible.
--Andy
10:22 a.m.
New subject: seccomp support [was: Testing chrony seccomp support]
On Tue, Jan 19, 2016, at 11:08 AM, Andrew Lutomirski wrote:
On Jan 19, 2016 7:41 AM, "Colin Walters" <walters(a)verbum.org>
wrote:
>
> On Tue, Jan 19, 2016, at 04:16 AM, Nikos Mavrogiannopoulos wrote:
>
> > The issue is that blacklists are terrible from a security
> > standpoint.
>
> > That means that every new obscure system call added to the
> > kernel will
>
> > be available by default in your program.
>
> https://github.com/seccomp/libseccomp/issues/11
One of these days I need to tidy up Sandstorm's seccomp policy
and
factor it into its own library. It's made a good showing for itself
over the last year or so, and it's highly compatible.
Yes,
https://git.gnome.org/browse/linux-user-chroot/commit/?id=8cee4ab7345f126...
11:43 a.m.
New subject: seccomp support [was: Testing chrony seccomp support]
On Tue, 2016-01-19 at 08:08 -0800, Andrew Lutomirski wrote:
One of these days I need to tidy up Sandstorm's seccomp policy
and
factor
it into its own library. It's made a good showing for itself over
the last
year or so, and it's highly compatible.
I would be quite interested in this!
Michael
11:43 a.m.
New subject: seccomp support [was: Testing chrony seccomp support]
On Tue, 2016-01-19 at 10:16 +0100, Nikos Mavrogiannopoulos wrote:
The issue is that blacklists are terrible from a security
standpoint.
That means that every new obscure system call added to the kernel
will
be available by default in your program.
Yes. This implies that seccomp should not be the primary enforcement
mechanism for a sandbox, unless you static link to your dependencies to
prevent the syscalls from unexpectedly changing. (This is what Chrome
does.)
It is useful regardless to blacklist a few syscalls that you know your
application really should not be using. kexec is probably the best
example.
That does sound like a very fragile usage of seccomp indeed.
It was a bad idea. :)
It could
be solved of course by using IPC to open a file rather than relying
on
the signal.
The kernel provides a couple options here: it can kill the process when
it calls open(), or it can send SIGSYS (in which case the only way for
the file to be opened is via IPC to a less-constrained process; this is
what we do), or it can notify another process via ptrace (which I have
not investigated).
Then the question for programs wanting to use glibc and seccomp
would
be, could libc keep the syscalls fixed for its wrapper of system
calls,
Even simply documenting the possible syscalls would be helpful to
programmers using seccomp, although apps are still going to break in
the future.
or could we have filters which are applied to glibc's calls
rather
than
system calls?
I don't think so. seccomp filters are per-process.
Michael
5:43 p.m.
On Mon, Jan 18, 2016 at 3:51 AM, Florian Weimer <fweimer(a)redhat.com> wrote:
On 01/18/2016 11:02 AM, Nikos Mavrogiannopoulos wrote:
> As Florian suggested it makes more sense to compartmentalize chrony so
> that only a small controlled part of it needs to run with seccomp. My
> recommendation, if you want to use libraries in the filtered code, make
> their authors aware of that, so that they document any changes in the
> used system calls, and if possible ask them to document the existing
> system calls used (e.g., similarly to:
> http://www.gnutls.org/manual/html_node/Running-in-a-sandbox.html )
Interesting. There is one huge caveat:
| As well as an calls needed for memory allocation to work.
glibc malloc can basically call *anything*. We don't know what the
future will bring. Currently, we use (off the top of my head, I haven't
checked):
* sbrk
* mmap
* mprotect
* munmap
* mremap
* madvise
* futex
* open
* read
* close
(In some cases, there is some sort of fallback, or errors are ignored
and the optimization does not happen.)
Future versions might reasonably use:
* sched_getcpu
* clone
* clock_gettime
* more open/read/close
* readlink
* whatever system calls are used for memory protection keys
* whatever system calls are used for restartable sequences
I appreciate what you are trying to do, but those seccomp filters
totally break encapsulation. I have no idea how to support this
properly, in a sustainable way. It appears very difficult to do this
for independently evolving libraries.
The sandstorm approach is striaghtforward: the disallowed things
return -ENOSYS. glibc can handle that quite nicely, as long as you
let existing stuff through.
--Andy
4:29 a.m.
On Mon, 2016-01-18 at 12:51 +0100, Florian Weimer wrote:
On 01/18/2016 11:02 AM, Nikos Mavrogiannopoulos wrote:
> As Florian suggested it makes more sense to compartmentalize chrony
> so
> that only a small controlled part of it needs to run with seccomp.
> My
> recommendation, if you want to use libraries in the filtered code,
> make
> their authors aware of that, so that they document any changes in
> the
> used system calls, and if possible ask them to document the
> existing
> system calls used (e.g., similarly to:
> http://www.gnutls.org/manual/html_node/Running-in-a-sandbox.html )
Interesting. There is one huge caveat:
> As well as an calls needed for memory allocation to work.
glibc malloc can basically call *anything*. We don't know what the
future will bring. Currently, we use (off the top of my head, I
haven't
checked):
I appreciate what you are trying to do, but those seccomp filters
totally break encapsulation. I have no idea how to support this
properly, in a sustainable way. It appears very difficult to do this
for independently evolving libraries
Well, ignoring the best sandboxing mechanism the linux kernel offers is not really a way
forward. What would be the alternative? Would something like pledge [0,1] be more suitable
more suitable to address your concerns?
regards,
Nikos
[0]. http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/pledge
.2?query=pledge
[1]. https://outflux.net/blog/archives/2015/11/11/evolution-of-seccomp/
7:15 a.m.
On Mon, Jan 18, 2016 at 11:02:44AM +0100, Nikos Mavrogiannopoulos wrote:
As Florian suggested it makes more sense to compartmentalize chrony
so
that only a small controlled part of it needs to run with seccomp. My
recommendation, if you want to use libraries in the filtered code, make
their authors aware of that, so that they document any changes in the
used system calls, and if possible ask them to document the existing
system calls used (e.g., similarly to:
http://www.gnutls.org/manual/html_node/Running-in-a-sandbox.html )
chronyd doesn't use libc for much more than that. There is memory
allocation, reading/writing system clock, reading/writing/moving
files, creating/connecting/binding sockets, receiving/sending
packets, and select(). Name resolving is now out of the filter. The
only other library that's currently used after the seccomp filter is
loaded is freebl3 from NSS.
I guess some of that could be moved to the helper process. If only the
most dangerous code (whatever that is) should run with seccomp, I'm
not sure if there is a layer where a clean small cut could be made. I
suspect the interface between the two processes would be huge and it
would bloat the code significantly.
--
Miroslav Lichvar
8:48 a.m.
On Mon, Jan 18, 2016 at 11:02:44AM +0100, Nikos Mavrogiannopoulos wrote:
As Florian suggested it makes more sense to compartmentalize chrony
so
that only a small controlled part of it needs to run with seccomp. My
recommendation, if you want to use libraries in the filtered code, make
their authors aware of that, so that they document any changes in the
used system calls, and if possible ask them to document the existing
system calls used (e.g., similarly to:
http://www.gnutls.org/manual/html_node/Running-in-a-sandbox.html )
chronyd doesn't use libc for much more than that. There is memory
allocation, reading/writing system clock, reading/writing/moving
files, creating/connecting/binding sockets, receiving/sending
packets, and select(). Name resolving is now out of the filter. The
only other library that's currently used after the seccomp filter is
loaded is freebl3 from NSS.
I guess some of that could be moved to the helper process. If only the
most dangerous code (whatever that is) should run with seccomp, I'm
not sure if there is a layer where a clean small cut could be made. I
suspect the interface between the two processes would be huge and it
would bloat the code significantly.
--
Miroslav Lichvar
--
devel mailing list
devel(a)lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
6:12 a.m.
On Mon, 2016-01-18 at 14:15 +0100, Miroslav Lichvar wrote:
On Mon, Jan 18, 2016 at 11:02:44AM +0100, Nikos Mavrogiannopoulos
wrote:
> As Florian suggested it makes more sense to compartmentalize chrony
> so
> that only a small controlled part of it needs to run with seccomp.
> My
> recommendation, if you want to use libraries in the filtered code,
> make
> their authors aware of that, so that they document any changes in
> the
> used system calls, and if possible ask them to document the
> existing
> system calls used (e.g., similarly to:
> http://www.gnutls.org/manual/html_node/Running-in-a-sandbox.html )
chronyd doesn't use libc for much more than that. There is memory
allocation, reading/writing system clock, reading/writing/moving
files, creating/connecting/binding sockets, receiving/sending
packets, and select(). Name resolving is now out of the filter. The
only other library that's currently used after the seccomp filter is
loaded is freebl3 from NSS.
I guess some of that could be moved to the helper process. If only
the most dangerous code (whatever that is) should run with seccomp,
I'm not sure if there is a layer where a clean small cut could be
made. I suspect the interface between the two processes would be huge
and it would bloat the code significantly.
If you have complex structures to be transfered you may want to rely on
something automated to serialize/deserialize requests. That will
increase the code, but reduce the complexity. I've used protocol
buffers over unix sockets for that exact reason and I'm pretty happy
with it.
regards,
Nikos
7:09 a.m.
On 01/20/2016 01:12 PM, Nikos Mavrogiannopoulos wrote:
If you have complex structures to be transfered you may want to rely
on
something automated to serialize/deserialize requests. That will
increase the code, but reduce the complexity. I've used protocol
buffers over unix sockets for that exact reason and I'm pretty happy
with it.
I wouldn't use protocol buffers across a security boundaries. The
serializers and serializers have integer overflows, and Google doesn't
want to fix them because their use case apparently provides implicit
message size constraints which make it impossible to trigger these issues.
https://github.com/google/protobuf/issues/760
https://github.com/google/protobuf/issues/761
Florian
4:23 a.m.
On Wed, 2016-01-20 at 14:09 +0100, Florian Weimer wrote:
On 01/20/2016 01:12 PM, Nikos Mavrogiannopoulos wrote:
> If you have complex structures to be transfered you may want to
> rely on
> something automated to serialize/deserialize requests. That will
> increase the code, but reduce the complexity. I've used protocol
> buffers over unix sockets for that exact reason and I'm pretty
> happy
> with it.
I wouldn't use protocol buffers across a security boundaries. The
serializers and serializers have integer overflows, and Google
doesn't
want to fix them because their use case apparently provides implicit
message size constraints which make it impossible to trigger these
issues.
https://github.com/google/protobuf/issues/760
https://github.com/google/protobuf/issues/761
In my case they don't have an effect either as the maximum message I
can transfer is 64kb. These issues could be indeed serious in certain
cases, but I still believe using protocol buffers is better than not.
I'd expect many more than these issues present in a custom parser.
regards,
Nikos
3011
days inactive
3120
days old
30 comments
8 participants
participants (8)
-
Andrew Lutomirski -
Colin Walters -
Dan Horák -
Florian Weimer -
Michael Catanzaro -
Miroslav Lichvar -
Nikos Mavrogiannopoulos -
Petr Pisar