artswrapper defanged

Rik Hemsley rik at kde.org
Fri Jul 19 10:30:28 BST 2002


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

#if Stefan Westerfeld

> Well, you don't seem to understand the nature of the "exploit".

I do. I wouldn't have acted if I didn't.

> There is another chain of argumentation which says: if it is
> potentially dangerous, it should not be the default. I think what
> /could/ be done is to get rid of a suid artswrapper in the default
> install. Instead, if a user chooses realtime in kcontrol, ask him for
> the root password if artswrapper is not SUID root yet, and make it
> SUID root, then.

This is exactly what I am hoping you will do.

> This fix would be not too user friendly, in the end, as lots of users
> would be bothered with thinking about the details of what realtime
> priority is, and how it works, or, if they don't think about it,
> would have broken and scratchy sound. Contrary to popular belief,
> starting artsd realtime is default right now, so that in fact no user
> right now needs to even think about what a sound server is to get
> dropout free sound. It works great by default because it always gets
> realtime rights.
>
> But well, if consensus is that security is more important in sane
> defaults than usability or user friendliness, then I think that
> making this step a lot more explicit would be the only way to go. It
> will lead to bug reports "can't get my sound right" and to frustrated
> users who don't write bug reports, and never find the problem, but if
> security against local denial of service attacks is the topmost goal,
> then thats the way to go.

I vote for security over user friendliness, but please note that I would
have no objection to a dialog box popping up at KDE startup (with the
'don't show this dialog again' option, of course), asking if artsd should
be run with realtime priority. The only tricky bit is to make the wording
understandable by users.

> Note that I think this is overreacting. You can bring down almost any
> system with a
>
>    for(;;) { malloc(4096); fork(); }
>
> program. Why bother if artswrapper can be used to achieve the same,
> then?

Standard practice on a multiuser machine is to set per-user limits
on memory use and process count, so that program won't work as intended.

Rik

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

iD8DBQE9N9w16rehpl6X9l0RAk/oAJoDc73br9WVWe/cpAs3oTByxPdoKwCeKHu/
4cJZL0bN72OCEuLpfNqH8Ss=
=+ib1
-----END PGP SIGNATURE-----





More information about the kde-core-devel mailing list