Subject: Re: [linux-audio-dev] sound/gui interaction
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Sat Jul 22 2000 - 01:03:10 EEST
On Fri, 21 Jul 2000, David Olofson wrote:
>
> > Besides, when you give the application proper permissions during
> > installation, the user is not required to become root to run the
> > application.
>
> Yep, but...
>
> > If you are really concerned about security, you can have your
> > processing stuff running in a seperate application, and have
> > your gui application running as normal user. (like jMax for
> > example)
>
> ...if the application runs plugins (in particular, closed source
> pplugins), you're in trouble. Basically, Win9x + Internet Explorer
> reinvented. (For those who luckily escaped it; web pages could make
> it download and execute binary applets without the user even seeing
> what's going on. And Win9x doesn't have any kernel level
> security...)
>
> This *HAS* to be fixed, and at kernel level AFAIK.
I am constantly stressing this point:
what we need is not full root acces, but only the permission
to set SCHED_FIFO and use mlock()/mlockall() calls.
period.
We can run as a regular user without disadvantages.
The thing is called capabilities , and I am not sure if
kernel 2.4 supports it yet but it is planned since it increases security
in many areas (see network daemons).
As for running binary-only plugins:
place them in a restricted folder where the user needs the permission
of the admin (or the root passoword) to install them.
But it does not solve the problem completely, since you could download
a free closed sourced plugin (which got infected by a virus), and while
testdriving it, it would infect your box with nice stuff.
Or someday a good exploit cooker will homebrew a special
"EVO-instument" which after it gets loaded
drops you to a r00t shell
:-)))))))
The process capabilities will solve all the above problems since untrusted
code will not be able to do any harm to the system.
>
> > But than ofcourse you loose the threading, and have
> > to think of some communication between gui and processing.
>
> What's the big deal? This is pretty much required anyway... (Shared
> memory still works, of course, if you want a simple "shared structs"
> kind of interface.)
attention: normal writing to shared structs in a threaded / multiple
processes model is FORBIDDEN if you want that your code will
run on SMP SPARCS. (it does not even provide 32bit read/write
atomicity)
I guess 99.9% of the SMP code around is not safe in this respect.
But fortunately we work mainly on x86 and PPCs.
:-)
Benno.
This archive was generated by hypermail 2b28 : Sat Jul 22 2000 - 00:46:02 EEST