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 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
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!
On Tue, Jan 19, 2016, at 11:08 AM, Andrew Lutomirski wrote:
>
>
On Jan 19, 2016 7:41 AM, "Colin Walters" 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 tha
On Jan 19, 2016 7:41 AM, "Colin Walters" 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 defau
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/iss
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 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
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
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 n
31 matches
Mail list logo
