Re: GNUstep.sh / env sanity patches

[Richard Frith-Macdonald]

On 20 Aug 2004, at 09:56, Jeff Teunissen wrote:

> Nicola Pero wrote:
>
> > > > ... I guess I don't see the trouble setting up /etc/profile (or
> > > > other similar methods) when a user logs in.  All distributions
> > > > handle this differently, but with the same end results.
> > >
> > > You're right, but he suggested modifying ld.so.conf, to include
> > > library paths for EVERY user. Using /etc/profile to set up
> > > LD_LIBRARY_PATH is fine, and the Right Way IMHO.
> >
> > You're of course aware that setuid executables ignore LD_LIBRARY_PATH
> > for security reasons so unless you add GNUstep library paths to
> > ld.so.conf, you will never be able to execute a setuid executable
> > compiled using GNUstep.
>
> I wouldn't allow a setuid executable using GNUstep libs to exist on my
> system, for the same reason GTK+ doesn't allow itself to run setuid.

While I agree with you about setuid root executables,  I have
seen people talking about wanting to run things as root.
I have also found it convenient to have executables setuid to an
unprivileged user account, where I want different people to be able
to work with a common group account. ... this has the same security
issues except that exploits run with that accounts access rather than 
root.

Given that people refuse to be sensible/cautious/paranoid (depending
on your viewpoint), I think we need to address the security issues 
rather
than just telling people not to do silly things.

While making it configurable where apps read/write defaults and load
resources (including code libraries and bundles) from obviously provides
increased scope for exploits via trojan code etc, I'm not sure that the
suggestion of making it possible to 'lock down' the configuration is a
good solution.

Nicola has suggested having a little function to turn on security ...
so an application wishing to be secure would call this function before
doing anything else, and the library would thereafter refuse to load
in bundles from the user domain.  That should deal with setuid root
exploits somewhat.

This sounds reasonable, but I'm still not happy ... I think perhaps
such a security measure should be implicit in anything running
as root.  I also worry that we should perhaps be looking at designing
a simple/clear/strict policy about accessing resources in general,
to minimise security problems.

Could we at least say that we will not load any defaults or resources
which could have been modified by anyone other than the current
user (effective user id) or the system manager?
I don't think we check that at present ...

The downside is that you might not be able to use applications
installed on your system by anyone other than yourself or root.
We could allow another trusted admin account to be used, but
that starts to get complex.