Re: GNUstep.sh / env sanity patches

[Nicola Pero]

> 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.

These things are really thorny :-)

But no, I don't think it should be implicit in anything running as root. 

Setuid programs are extremely special.  The operating system / system
tools know they are extremely special, for example it is essential that
when you run a setuid program, LD_LIBRARY_PATH is ignored by the linker.  
LD_LIBRARY_PATH is available for root programs -- only setuid programs
ignore it.  The reason they ignore it is that setuid programs have the
implicit assumption that you are allowed to execute some code as eg root
because you can't change the code in any way - it's a fixed bit of code
and what it does is strictly controlled.

But root can use LD_LIBRARY_PATH in all other respects -- only setuid
programs ignore it.

What we really want to do is do the same with our configuration variables.  
Our config variables - the one to locate the GNUsteprc file - has exactly 
the same function of LD_LIBRARY_PATH -- it is used to locate resources and 
code which is used by the running executable.

We'd like to ignore those config variables for setuid executables where
the code to execute must be strictly fixed, but I don't see why we should
ignore them for root programs.  After all, LD_LIBRARY_PATH is not ignored
for root programs.

In fact, if I'm writing a trojan, no matter if gnustep-base, when running
as root, ignores or not the GNUstep configuration variables, I have plenty
of space for modifying the way the program works by using LD_LIBRARY_PATH
to just replace gnustep-base with my own library.  Or even better, use
LD_PRELOAD to only replace the bits I want to hack in gnustep-base with my
own.

In other words, if I am me and I am running a non-setuid program, I have
total control over what code I execute; I've got plenty of support from
the operating system (LD_LIBRARY_PATH and LD_PRELOAD are nice examples) to
work around no matter what fascist restriction you put in gnustep-base.  
It looks like the issue of configuration variables is irrelevant here in
terms of security, given the support from the os.  I'm myself, I can
decide what code I want to execute as myself, in particular I can replace
gnustep-base entirely with something else. :-)

The security locking of resource lockups only makes sense when the
executable is a setuid executable; then it makes a terrific amount of
sense.  the only problem is that the executable must have been marked as
requiring resource locking in the source code as that seems like the only
safe way of preventing the config variables from being read.  the o/s
tools are helping us here, in fact setuid executables have harmful/useful
variables disabled or ignored, we are just trying to extend this to our
own variables.

In all the other cases, well even if gnustep-base is built with security
locked in, you can always use LD_LIBRARY_PATH to load your own modified
gnustep-base instead of the system one, or use LD_PRELOAD to only change
little bits, and that works around any security you have in gnustep-base.  



> 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 ...

But that is something completely different and it sounds like a more
interesting idea.

Probably we could emit a warning if the user defaults are writable by
someone else.  I don't think we should check resources we load.

Checking resource permissions is somewhat tricky, eg if an application
loads an image should we check permissions or not ?  If it's an image
editing application, then you don't really want to check permissions else
the application might become unusable if you're sharing images.  If it's
an image in the application bundle, if you want to be paranoid, it might
have been tampered with, so you might want to check.

On the other hand, if I'm trojanizing your resources and I know
gnustep-base has got checks for permissions, I would probably trojanize
them, then try to drop the permissions for me and leave only yours so that
gnustep-base thinks that the resource is safe and loads it happily.

Hmmm ... I don't think it generally makes sense to have a general policy
of checking resource permissions during loading.

It looks like it's the distribution / sysamin / user that have to try to
make sure their resources are safe.

We can help, of course :-)

I suppose it is very important that when we install bundles, resources or
packages in general we get the permissions right.  It is also very
important that when we create defaults or modify them, we get the
permissions right.  And sure, it is very important that we create the user
root with a strict set of permissions, only allowing the user to work on
it (not sure that that is the case at the moment).

Maybe we could check once the permissions on the user root dir at startup,
and generate a warning if they seem too permissive.

I would keep it very basic, getting into too many details is hard because
we can't really implement a unix security auditing package inside
gnustep-base. :-)

A couple of very simple and localized checks at the beginning for the user
root and user defaults, with a simple warning, might be good though.  I
like that idea.  I think more than that it becomes overkill and will not
help much.

Anyway, thanks for your comments