Re: pkgsrc and security: xpdf example

[tlaronde%polynum.com@localhost]

On Sun, Jul 28, 2019 at 11:36:01PM +0000, David Holland wrote:
> 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.

I thought so (that it was more effective to confine globally instead of
trying to ensure, program by program, there was no escaping route---simpler
to make things fail if they are attempted than trying to ensure that
nobody would try).

Nonetheless, for security, xpdf(1) is a good example. It could be argued
that there could be another mean to send a print job, taking into
account the problem of the vast variety of printing ways on different OSes (so that
xpdf would call one explicit program---a defined pathname script,
defined at installation time---with arguments instead of passing
whatever command to the shell), but, all in all, it's its function
to render PDF, on screen or on paper... (it's not critics: xpdf is
useful and one doesn't think at everything, particularily when trying to
provide some task; I personnally only wondered about the print command when I was
contemplating giving access to a remote user to just be able to
consult/see data, and never questionned it before.)

But this makes the "vulnerabilities" very relative. Are vulnerabilities
only related to ways giving a user an opportunity to escape from a
chroot or to gain access to a root account? or does it also include
possibility to send commands that were not intended to be sent?

Best,
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C