On Sun, 2008-04-20 at 15:40 +0200, Ove Kaaven wrote:> Sylvain Petreolle skrev:> > Hmm.> > It means that a program looking specifically for that would be able to reenable it at any moment.> > 1° Detect Wine,> > 2° Reenable unixfs unconditionally,> > 3° Do weird things with lots of unix files (especially if the user runs it as root)> > Why does that worry you? For anything Wine-aware, there's a far simpler > way to get unlimited access to your Unix files.> > 1) Detect Wine> 2) Do direct Linux syscalls> 3) Profit> > Wine isn't a sandbox. There's no way you can prevent malicious software > from accessing $HOME under Wine.> > Perhaps in the future it might be possible, if someone wrote some > security module for Linux that only allowed syscalls from Wine builtin > dlls and not PE native dlls or something, protected the dlls from being > modified, and people otherwise tried to make Wine more secure. But for > the time being, there's no shortage of attack vectors against Wine.> > (And yeah, definitely never run Wine as root.)> If you are feeling particularly paranoid, you could run FreeBSD insteadof (I assume) Linux, run X in its own jail, run your Wine apps in theirown jail (fiddling DISPLAY and granting access to the X server). IMHO this is vastly more effort than the potential benefit. You couldprobably get as much security as you wish by chroot(8)'ing wine. Tom -------------- next part --------------A non-text attachment was scrubbed...Name: not availableType: application/pgp-signatureSize: 195 bytesDesc: This is a digitally signed message partUrl : http://www.winehq.org/pipermail/wine-users/attachments/20080421/e0ad2a37/attachment.pgp