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 yo
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
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 tha
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
> > re
On Mon, Jan 18, 2016 at 3:51 AM, 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
On Tue, 2016-01-19 at 09:18 +, Petr Pisar wrote:
> This is doomed even without seccomp because malloc(3) is not
> async-signal-safe ;)
It sems to work reliably for us, but yeah, to do it safely, we need
to preallocate all the memory.
--
devel mailing list
devel@lists.fedoraproject.org
http
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
On 2016-01-18, Michael Catanzaro wrote:
> This all goes awry if, in the web process's signal handler, malloc
> decides to call open(),
This is doomed even without seccomp because malloc(3) is not
async-signal-safe ;)
-- Petr
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedora
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
> * o
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 yo
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
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
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 privil
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 getad
On Wed, 7 Oct 2015 14:13:36 +0200
Miroslav Lichvar 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 wrote:
> >
> > > In chrony 2.2-pre1 was added support for system call filtering
> > > with the kernel seccomp facilit
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 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
On Mon, 5 Oct 2015 13:58:26 +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 privile
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
On Mon, Oct 5, 2015 at 8:25 AM, Michael Catanzaro 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 exp
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 ho
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 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
On Oct 5, 2015 6:23 AM, "Michael Catanzaro" 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
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
24 matches
Mail list logo
