Re: pkgsrc and security: xpdf example

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Sun, Jul 21, 2019 at 04:34:58PM +0200, tlaronde%polynum.com@localhost wrote:
 > Supposing one wants just to provide an user with a mean to display PDF
 > files, trying to limit the commands used by the user to just what is
 > explicitely defined. The ability to send arbitrary
 > commands is a problem.

Providing restricted environments (or restricted shells, which is the
same thing) without an explicit chroot or VM is a well-known hard
problem. You're creating a security perimeter where none previously
existed, so at a minimum you have to audit every program carefully for
things like shell escapes. But really you also need to look for things
like calls to system() and popen(), things that can set environment
variables, ways to trigger unexpected signals... basically every piece
of paranoia needed in a setuid program needs to be applied to _every_
program. Which includes things in various libraries that check
issetugid() to decide whether to be paranoid, which is now wrong. And
on top of that formerly uninteresting (for security) bugs that let
users exploit programs to run arbitrary code as themselves become real
problems.

Furthermore, what might be ok or even necessary for one person (e.g.
being able to send out print jobs) might be a problem for the next
person coming along with similar goals. So without some ability to
express policy, it's not much use.

The consensus among security folks used to be that this is futile and
you should either not bother or use other more comprehensive methods
(e.g. chroot). I'm not sure if this has changed in the presence of
newer frameworks; but I don't think e.g. pledge is expressive enough
to get what you want.

Which is a long-winded way of saying:

 > So is there an option to generally disable this kind of features in
 > packages (supposing they are identified/known)?

There is not, they are not, and it's likely tilting at windmills to
try.

-- 
David A. Holland
dholland%netbsd.org@localhost