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

List:       kde-core-devel
Subject:    Re: security vs. usability
From:       Michael Jarrett <yoamwmvs () umail ! corel ! com>
Date:       2001-02-06 14:16:29
[Download RAW message or body]

DEFINATELY not!
suid is evil. EVIL! If I had a dime for each time a programmer here told
me that it was necessary for the app to have suid for usability
purposes, I'd be a rich man. Not from the dimes, but from people paying
me to fix all the root exploits in their systems - and I've YET to see a
suid root app that has not been at some point exploited, most of which
with trivial root exploits. while suid itself is as dangerous (but still
so), suid root IS, and I figure that most people wish to use it for
exactly that.

kisdn and kppp form network connections. These are administrative tasks,
NOT user tasks, and Windows may have made you all a bit soft on this
regard. If a user should be able to do this, a root process which
manages this in a secure manner should be loaded at startup. Think, the
mere process of forming a network connection of ANY sort gives the user
power over domain name resolution, IP address, routing, can bypass
(some) firewalls, and expose an insecure network to the public eye.

cd burning is an ugly hack and always has been. It should be fixed, not
kdelibs.

This just forces KDE code to be written cleanly. You can still exec
subprocesses with suid if you are really that crazy, right?

Mike



Bernhard Rosenkraenzer 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.
> 
> 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.
> 
> 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...
> 
> Any better ideas?
> 
> LLaP
> bero
-- 
The address in the headers is not the poster's real email address.  Do not send
private mail to the poster using your mailer's "reply" feature.  CC's of mail 
to mailing lists are OK.  Problem reports to "postmaster@umail.corel.com".  
The poster's email address is "michaelj@corel.com".

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