Control: reopen 932762 Control: severity 932762 important Control: retitle 932762 Needs a sane solution for running under LD_PRELOAD like fakeroot
[ Taking Niels into the loop. I'm sorry the first approach didn't work out. ]
With the problem preliminary fixed, the whole story needs some
consideration. Aside, I noticed too late fakeroot-tcp is still broken,
so another upload will follow soon-ish.
Situation unchanged: When running under fakeroot, the file binary does
(via libfakeroot) additional syscalls that are not whitelisted in the
seccomp filter, hence breaking operation. This might happen in other
LD_PRELOAD mechanisms as well.
Helmut Grohne wrote...
> The blocked syscall is 68 aka msgget. It is an IPC call used by
> fakeroot to communicate the faked permissions. I think allowing more
> syscalls in the sandbox is a bad idea.
>
> * You're whitelisting amd64 syscalls now. Other architectures use
> different numbers and hunting them down for each and every
> architecture is painful.
JFTTR, whitelisting is done by a symbolic name - so this should work on
all archs.
> * fakeroot uses msgget when used with faked-sysv. For use with
> faked-tcp, you will need socket and connect and stuff.
> * Blocking IPC or network was exactly the job of seccomp. If you allow
> these calls, you are significantly weakening the sandbox.
Yes, figured that in the meantime, consider the whitelisting approach
dead for that reason.
> * Have you tried faketime, fakechroot, eatmydata, ...?
faketime and eatmydata yes - but I assume there exist several more
packages using LD_PRELOAD during build.
> Let me propose a much simpler option: Check for the presence of
> LD_PRELOAD and imply -S when it is non-empty.
This however is very broad and and has a risk risc of silently
disabling this security feature in a production system, so, no.
What I am looking for now is to disable seccomp in a build environment
only. For the moment I can think of two ways to handle this:
* Have a second file package without seccomp support
A second file package without seccomp, "Package: file-buildd",
"Provides: file", and the toolchain/debhelper has an explicit
dependency on that one. This would require all buildsystems have
an explicit dependency on that packages, debhelper to start with.
My only concern is users will start using this, "because the other one
just creates trouble". Hence the somewhat obscure name. Feel free to
propose another one.
* Have a build system detection in file(1)
The programs using LD_PRELOAD often leave specific data in the
environment, file(1) could use that one, in theory. However, pseudo(1)
does not, and as that detection should be generic, I fail to see this
road leads anywhere.
So the final solution I can think of is a distinct environment variable
set by debhelper I could depend on.
In either way, this requires some coordination with debhelper, and
theoretically other build systems as well. And since the first one seems
way saner to me, I am willing to take the additional efforts required
(packaging, NEW) upon me as they are one-time only.
Christoph
signature.asc
Description: PGP signature
