[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sandboxing at runtime

From: Bernd Zeimetz
Subject: Re: Sandboxing at runtime
Date: Fri, 24 Jul 2020 00:50:27 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0


On 7/22/20 6:20 AM, Sanjeev Gupta wrote:
> (I am cc:ing both lists, as I think the groups overlap, and both have
> the seame concerns)
> A choice of either a dynamic library (with LD_PRELOAD) or running it
> under a "sandboxify" application.

while I think that investigating in seccomp and friends is a good idea,
I think some more basic work would be much more important, for example
enhancing the gpsd.service file by all the security features systemd
supports, starting with private temp directories and having a readonly
(or even read protected) rest of the system.
Then, using SystemCallFilter= might be a good start.
Implementing such filters in a systemd unit makes it much more easy to
test thing and allow syscall in case its needed. If you do the same in
the gpsd code, you'd have to use a compielr to fix issues.
Using LD_PRELOAD on the other hand is - imho - never a good idea.

There is an appamor profile, which handles these things, but that is
something less people are using, although it will be shipped and
activated in the next Debian and Ubuntu releases.

For Redhat based distros it might make sense to create a selinux policy
(in case there is none yet!?).


 Bernd Zeimetz                            Debian GNU/Linux Developer                      
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

reply via email to

[Prev in Thread] Current Thread [Next in Thread]