On Sat, Jul 27, 2019 at 03:55:36AM +0200, Christoph Biedl wrote:
> LD_PRELOAD ruins your day. From the kernel's point of view there is no
> difference between a syscall coming from the actual application and one
> coming from the code hooked into it. And while the syscalls done by the
> first
On Sat, 27 Jul 2019 at 10:01:41 +0200, Vincent Bernat wrote:
> Just a quick note: seccomp filters may need adaptations from one libc to
> another (and from one kernel to another as the libc may adapt to the
> current kernel). For example, with the introduction of "openat" syscall,
> the libc has
Philipp Kern wrote...
> On 2019-07-27 10:01, Vincent Bernat wrote:
> > I am upstream for a project using seccomp since a long time and I have
> > never been comfortable to enable it in Debian for this reason. However,
> > they enable it in Gentoo and I get the occasional patches to update the
> >
❦ 28 juillet 2019 12:11 +02, Philipp Kern :
>> Just a quick note: seccomp filters may need adaptations from one libc
>> to another (and from one kernel to another as the libc may adapt to
>> the current kernel). For example, with the introduction of "openat"
>> syscall, the libc has started to
On 2019-07-27 10:01, Vincent Bernat wrote:
Just a quick note: seccomp filters may need adaptations from one libc
to
another (and from one kernel to another as the libc may adapt to the
current kernel). For example, with the introduction of "openat"
syscall,
the libc has started to use it for
Philipp Kern wrote...
> That being said: It feels like if you face this situation, you could also
> fork off a binary with a clean environment (i.e. without LD_PRELOAD) and
> minimal dependencies and only protect that with seccomp. Of course you lose
> the integration point of LD_PRELOAD that
❦ 19 juillet 2019 17:18 +02, Christoph Biedl :
> Upstream of the file package added seccomp support a while ago, and
> probably everyone with even a small concern about security will agree
> the file program, often being used on dubious or even doubtless
> malicious input, should use seccomp to
* Christoph Biedl , 2019-07-27, 03:55:
The file program should[citation needed] not write to any file
...except when using the -C option.
--
Jakub Wilk
On 2019-07-27 04:55, Christoph Biedl wrote:
Eventually fakeroot-tcp, wishes to open sockets, something
I certainly would not want to whitelist.
In AppArmor case, "non-standard" use cases can be dealt with by editing
`/etc/apparmor.d/local/usr.bin.foo`, adding any necessary rules (like
On 2019-07-27 03:55, Christoph Biedl wrote:
Vincas Dargis wrote...
On 2019-07-26 18:59, Christoph Biedl wrote:
> > tl;dr: The file program in unstable is now built with seccomp support
> > enabled, expect breakage in some rather uncommon use cases.
Interesting, what are these uncommon use
Vincas Dargis wrote...
> On 2019-07-26 18:59, Christoph Biedl wrote:
> > > tl;dr: The file program in unstable is now built with seccomp support
> > > enabled, expect breakage in some rather uncommon use cases.
>
> Interesting, what are these uncommon use cases? Maybe we could confine it
> with
On 2019-07-26 18:59, Christoph Biedl wrote:
tl;dr: The file program in unstable is now built with seccomp support
enabled, expect breakage in some rather uncommon use cases.
Interesting, what are these uncommon use cases? Maybe we could confine it with AppArmor instead,
since we have it enabled
Christoph Biedl wrote...
> tl;dr: The file program in unstable is now built with seccomp support
> enabled, expect breakage in some rather uncommon use cases.
Several issues popped up in the last days as a result of that change,
and in spite of some band-aiding to current implementation of
[Adding rb-gene...@lists.reproducible-builds.org to CC]
Hi Christoph,
> Overall, I'm just asking to keep an eye on possible breakage, also
> check the kernel log.
I noticed that there were a number of recent regressions in previously
reproducible Java packages being tested by the Reproducible
Christoph Biedl writes ("file(1) now with seccomp support enabled"):
> tl;dr: The file program in unstable is now built with seccomp support
> enabled, expect breakage in some rather uncommon use cases.
Thanks for this work and for the heads-up.
PS: Did you really mean to send
On Sat, 20 Jul 2019 at 00:21:10 +0200, Christoph Biedl wrote:
> The build system of the file package uses autoconf to check for
> presence of the seccomp library and will just disable that feature if
> support is missing. But just adding "libseccomp-dev" will break the
> build on e.g. alpha for an
On Jul 20, Christoph Biedl wrote:
> * Centralize the list of supported archs in the seccomp packages. By
> either creating an empty libseccomp-dev for the archs where seccomp
> is not supported, or by creating a "libseccomp-dev-dummy" for these.
> In the latter case package maintainers
Russ Allbery wrote...
> Christoph Biedl writes:
>
> > tl;dr: The file program in unstable is now built with seccomp support
> > enabled, expect breakage in some rather uncommon use cases.
>
> Thank you very much for doing this! Here's hoping this sets a trend. It
> will provide so much defense
Paul Gevers wrote...
> Hi Christoph,
>
> On 19-07-2019 17:18, Christoph Biedl wrote:
> > tl;dr: The file program in unstable is now built with seccomp support
> > enabled, expect breakage in some rather uncommon use cases.
>
> This probably warrants an entry in the bullseye release-notes.
Hi Christoph,
On 19-07-2019 17:18, Christoph Biedl wrote:
> tl;dr: The file program in unstable is now built with seccomp support
> enabled, expect breakage in some rather uncommon use cases.
This probably warrants an entry in the bullseye release-notes. Should we
already forward your original
Christoph Biedl writes:
> tl;dr: The file program in unstable is now built with seccomp support
> enabled, expect breakage in some rather uncommon use cases.
Thank you very much for doing this! Here's hoping this sets a trend. It
will provide so much defense in depth against malicious files.
tl;dr: The file program in unstable is now built with seccomp support
enabled, expect breakage in some rather uncommon use cases.
Hello,
Upstream of the file package added seccomp support a while ago, and
probably everyone with even a small concern about security will agree
the file program,
22 matches
Mail list logo
