artswrapper defanged

[Rik Hemsley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

#if Neil Stevens
> On Tuesday July 16, 2002 02:39, Rik Hemsley wrote:
> > Security should be enabled by default, not disabled.
>
> But you didn't just change defaults, you destructively removed
> features without giving an option to turn them back on!  With the job
> only half-done, leaving features removed in this state, your changes
> are just going to get reverted unless you finish the job.

I didn't remove feature_s_. Please don't try to sensationalise the fact
that I disabled one 'feature' which opens a local denial of service hole.

> > How many people need artsd to provide them with 'realtime' sound ?
> > It looks like it's only Brahms users.
>
> I do.  And who are you to question what features are needed in
> Stefan's code anyway?  Is this about security, or about you imposing
> your will on aRts?

This is about security. Again, please don't accuse me of things which
I have patently not done.

> > How about we enable realtime scheduling only when someone is using
> > an app which requires artsd to have such privileges ? Quite easy to
> > do in a pretty way. kdesu can prompt the user and you can show a
> > dialog warning about the possibilities for bad things happening.
>
> Reasonable idea.  Try it.

Is this to be a posturing exercise, or shall we discuss this quite
serious issue ?

> > Note that even without a DoS from another local user, you can have
> > your system hang due to a bug in artsd. Last time I installed
> > artswrapper suid, the system hung solid when I started artsd.
>
> Now you're reaching.  Realtime was never on by default in kcontrol. 
> The only people who will turn it on are those who were already having
> trouble without it.

* artswrapper is installed suid root by default and currently has
  a local denial of service vulnerability.

* If the install is unable to make artswrapper suid, it asks the user
  to, without warning them of the consequences.

* If the user enables real-time scheduling in the aRts kcontrol module,
  they are not warned of the consequences, either those relating to
  possible security holes or the fact that if artsd hangs, it may
  hang the whole machine.

These are the problems. IMO KDE should not be released with such problems. I
wonder if you and Cornelius are the only ones who disagree with me here.

> > And no sane sysadmin will install KDE for her users, because KDE
> > doesn't care about security. It installs useless (to users on such
> > a system) programs suid, requiring her to go and fix the holes.
>
> What do you know about security?

I don't know how to answer that, as it seems to be a rhetorical question.

> You're attempting to apply a blanket security model to all KDE users!
>
> Stop treating security like some magical marketing word that makes
> everyone jump, and think in terms of actual users of KDE.  You've
> already gotten support for making the suid install configurable. 
> *That* serves the users needs.  Why isn't that enough?

I didn't know until now that I had support. I saw an offhand remark
which translated as that I should implement the suggestion I made
myself.

I don't have the time to get into the details of large bodies of code
such as aRts. The most important thing was to have the hole properly
plugged for now, so the correct fix can be made later. I am not sure
why you wish to paint me as a marketing-driven security-ignorant fool.

Rik

- -- 
http://rikkus.info
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9NDGl6rehpl6X9l0RAklpAKCFNtub5efGbnVivt5jmX5BbaKCmgCbB1EF
dF9ncZPBn8ODmeclvVV3OlE=
=gfSI
-----END PGP SIGNATURE-----