[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: security vs. usability
From:       Marcus Meissner <Marcus.Meissner () caldera ! de>
Date:       2001-02-06 10:11:44
[Download RAW message or body]

In article <Pine.LNX.4.30.0102052215240.6395-100000@bochum.redhat.de> you wrote:
> I've just noticed the change in kdecore/kapp.cpp (yes, I know, it's been
> there for quite a while now) that disallows setuid/setgid KDE
> applications.

This change was suggested by me.

> While this is definitely a good thing for security, it also prevents
> people who don't care about local security (i.e. most home users) from
> making things like kppp or kisdndock setuid or setgid to allow anyone
> access to dialout links and similar stuff.

This should be done differently. Also you can still do:

$ su -p
# kisdn &

kppp still works, since it drops all privileges before getting a KApplication
instance.

As for dialout, we at Caldera have a modem/serial device framework which
no longer requires setgid programs (it uses a small helperprogram).
Check out our 'isp' set of packages and the tty_* functions.

> I guess the error should be replaced by a warning - since a user can't
> just make his own programs setuid, it's really just a way to tell the
> admin not to do this if he cares about local security. If someone wants to
> open leaks, let them...

I beg to disagree.

The problem is that the KDE libraries are inherently unsafe in regards to
setuid programs. And not just the KDE libraries, the X libraries also 
contain code which is not safe. This are just 20 million lines of non-setuid
safe code running.

There are several places where you just cannot guarantee safe handling of
opened files and which are, if default shipped, a nightmare.

I think it is more wise to just abort() and hit the programmer in the face
that he should think of a better way on how to solve your problem instead
of allowing such extremely dangerous features.

(And there are several good ways to solve those. See kppp, see the ksaferppp
 we are shipping, etc.)

And as for the local admin wanting to do it and we be giving him the
possibility to shoot himself into his own foot...

I think we should skip that concept this time.

Ciao, Marcus

[prev in list] [next in list] [prev in thread] [next in thread]