Wine securityflaw: Protect against root

[Francois Gouget]

On Sun, 27 Oct 2002, David D. Hagood wrote:

> P. Christeas wrote:
>
> >
> > Write a segment of code that will abort wine, if it is run as root
> > (that is,
> > just before wine starts anything). This piece of code should only be
> > explicitly disabled in the 'configure' script. That way, only a
>
> I slightly disagree - I think the thing to do would be to have wine not
> run if UID == 0, UNLESS the commandline parameter --i-know-i-am-root is
> set, AND THEN pop up a dialog box that requires confirmation before
> continuing.

I don't think this is necessary.

Either the user is already logged in as root, as in 'I typed root when
XDM asked me my login' (or the system logged me in as root like in
Lindows), and then he has more important things to worry about.

Or he logged in as a regular user and su-ed as root and is now running a
Wine application. If he took the pain to su as root (and adjust $DISPLAY
and permissions appropriately), then I would trust him to know what he
is doing. Windows users don't su as root (they use the KDE/Mandrake/etc
menu entries that automatically ask for the root password).

Anyway, this idea is so trivial to implement in the Wine wrapper (a
shell script) that it is really not an issue, and can be left to
packagers (to add or remove).


> I would ALSO suggest that wine check the execute bit on the application
> being run - the recent incident with Klez running under Wine would not
> have happened (I think) if wine would not run that which is not marked
> with the -X bit (unless, again, a command line parameter is supplied,
> and a warning dialog is confirmed).

As someone else pointed out this would break a lot of programs.

But there is an interesting aspect that I did not see mentioned before.
The user reporting this says he was using KMail. I did some tests with
KMail and whenever you open an attachement you get a warning that it may
compromise your security. This may sound good but this happens for every
single attachement: for text attachements, diff files, gifs, jpgs,
everything. And this is a rule of security: if security measures get in
the way they will be ignored. Here I'm sure KMail users just get the
reflex of systematically clicking on Open don't even read the message
after the first couple of times. To improve security KMail should issue
warnings in a more discriminate manner (have a (user-configurable) list
of known safe MIME types for instance).


[...]
> And as for making "/" available as a Wine drive - how about creating a
> tool that would allow you to add or remove drive mappings at run time?
> So that if I find that I really do need /usr/foo/bar/baz available to
> Wine, I can run a program that tells wineserver to add that as drive Q:
> for now.

Again many people said Wine should not be configured to have access to
your home directory or to /. But this would be a big usability problem
and make Wine useless for all people using Wine in an office
environment. In such an environment people need to open Word documents
sent as attachement by collegues (/tmp/...), located on a file server
(/mnt/server/....), or documents they work on ($HOME/...). Remove the
drives that let them access these documents and Wine becomes so
cumbersome to use that it is unusable.

In fact, arguing for the removal of these drives is a bit similar to
arguing that Emacs should be run in a chroot-ed environment to protect
you from malicious Lisp programs. Of course it means that you would have
to copy files back and forth to edit them and thus no one is advocating
that.


-- 
Francois Gouget         fgouget at free.fr        http://fgouget.free.fr/
     Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.