Hi,
Wine is a great tool, especially for newbies like me that switched from windows to linux.
But there something, I really don't understand. When I configure Wine I can link pathes to "windows drives". I deleted "Z:", I deleted the links to desktop and so on. But every native windows application is able to see the hole linux path structure (which is naturally windows unlike). It's right - it's not possible to open any file, BUT I can rename or delete any file ...
If WINE is no Emulator but a compatibility layer - what is said against disabling access to any path / file structure out of the configured pathes ? It is even possible to deny access to different pathes in windows itself by catching the file access routines - more than ever it should be possible when writing wrappers / mappers to linux kernel functions, am I right ?
So long
LastCoder
[Wine 1.3] Access to "/" for Windows Applications
This is probably how the file selector is made. The thing is - Wine's file selector will be able to access these files, but your application wouldn't actually be able to see or use any of these.
Since you removed Z:, You shouldn't be able to select one of these files and then open or save it under that name. If you can, then we have a problem.
Since you removed Z:, You shouldn't be able to select one of these files and then open or save it under that name. If you can, then we have a problem.
Houston - you probably have a problem
yeah .. it's possible to RENAME or DELETE the files ! Just tested it with some Windows tools - the windows' open file dialog that is used by most applications natively supports a context menu for file operation like rename or delete .. and that works ! it is not as dangerous as reading the files but seen from this angle not much behind ...DaVince wrote:..
Since you removed Z:, You shouldn't be able to select one of these files and then open or save it under that name. If you can, then we have a problem.
IMHO it is okay if people want windows applications running with wine to see and handle their files but for reasons of security default wine configuration should deny every kind of file or directory access out of whatever is linked to windows drives like "C:" ...
So long
LastCoder
-
PleegWat
[Wine 1.3] Access to "/" for Windows Applications
On 08/18/2010 08:34 PM, Lastcoder wrote:
the functionality.
Deleting the 'Z:' symlink goes some way to preventing a windows app
accessing the rest of the drive, but it's not a certainty. Especially
malicious code can do everything a linux program with the same
permissions could do. Wine is not a sandbox.
PleegWat
That dialog is implemented by windows, and wine. So it is wine providingDaVince wrote:yeah .. it's possible to RENAME or DELETE the files ! Just tested it with some Windows tools - the windows' open file dialog that is used by most applications natively supports a context menu for file operation like rename or delete .. and that works ! it is not as dangerous as reading the files but seen from this angle not much behind .....
Since you removed Z:, You shouldn't be able to select one of these files and then open or save it under that name. If you can, then we have a problem.
IMHO it is okay if people want windows applications running with wine to see and handle their files but for reasons of security default wine configuration should deny every kind of file or directory access out of whatever is linked to windows drives like "C:" ...
So long
LastCoder
the functionality.
Deleting the 'Z:' symlink goes some way to preventing a windows app
accessing the rest of the drive, but it's not a certainty. Especially
malicious code can do everything a linux program with the same
permissions could do. Wine is not a sandbox.
PleegWat
..
.. it's okay if WINE is no sandbox, a sandbox is more than special file handling ..
.. but from the technical & practical point of view I just don't see any reason why WINE has to give windows applications access to pathes or file structures out of the configured Drives. In former DOS times you hooked INT 13h and INT 21h, in windows you have to gain control of win32 file functions (which is basic knowledge of every better-than-scripptkidies-malware author ..) ... you guys managed to map the whole absolutely ugly windows stuff to kernel functions and want to tell me that this impossible ???
So long
LastCoder
.. but from the technical & practical point of view I just don't see any reason why WINE has to give windows applications access to pathes or file structures out of the configured Drives. In former DOS times you hooked INT 13h and INT 21h, in windows you have to gain control of win32 file functions (which is basic knowledge of every better-than-scripptkidies-malware author ..) ... you guys managed to map the whole absolutely ugly windows stuff to kernel functions and want to tell me that this impossible ???
So long
LastCoder
-
Alexandre Julliard
[Wine 1.3] Access to "/" for Windows Applications
"DaVince" <[email protected]> writes:
the open dialog. cf. winetricks sandbox.
--
Alexandre Julliard
[email protected]
You have to disable the Unix shell folder too if you don't want it inThis is probably how the file selector is made. The thing is - Wine's
file selector will be able to access these files, but your application
wouldn't actually be able to see or use any of these.
Since you removed Z:, You shouldn't be able to select one of these
files and then open or save it under that name. If you can, then we
have a problem.
the open dialog. cf. winetricks sandbox.
--
Alexandre Julliard
[email protected]
-
James McKenzie
[Wine 1.3] Access to "/" for Windows Applications
Lastcoder wrote:
list. This does not sound like a bug, but you are free to research that
mailing list prior to posting any additional information/comments.
James McKenzie
This has been discussed, at length, in the Wine Development mailingDaVince wrote:
yeah .. it's possible to RENAME or DELETE the files ! Just tested it with some Windows tools - the windows' open file dialog that is used by most applications natively supports a context menu for file operation like rename or delete .. and that works ! it is not as dangerous as reading the files but seen from this angle not much behind .....
Since you removed Z:, You shouldn't be able to select one of these files and then open or save it under that name. If you can, then we have a problem.
IMHO it is okay if people want windows applications running with wine to see and handle their files but for reasons of security default wine configuration should deny every kind of file or directory access out of whatever is linked to windows drives like "C:" ...
list. This does not sound like a bug, but you are free to research that
mailing list prior to posting any additional information/comments.
James McKenzie
-
James McKenzie
[Wine 1.3] Access to "/" for Windows Applications
Lastcoder wrote:
get virtualbox and go and buy a copy of Windows. That is NOT what Wine
is supposed to be (BTW, I can see the entire contents of my C:\ drive on
a LOCKED DOWN system. I just cannot touch anything. )
If that is what you want, that is an effort in progress (mapping Windows
capabilities to the Extended Linux file permissions.)
James McKenzie
Ah, now I see what you want, a sandbox. If that is what you NEED, then.. it's okay if WINE is no sandbox, a sandbox is more than special file handling ..
.. but from the technical & practical point of view I just don't see any reason why WINE has to give windows applications access to pathes or file structures out of the configured Drives. In former DOS times you hooked INT 13h and INT 21h, in windows you have to gain control of win32 file functions (which is basic knowledge of every better-than-scripptkidies-malware author ..) ... you guys managed to map the whole absolutely ugly windows stuff to kernel functions and want to tell me that this impossible ???
get virtualbox and go and buy a copy of Windows. That is NOT what Wine
is supposed to be (BTW, I can see the entire contents of my C:\ drive on
a LOCKED DOWN system. I just cannot touch anything. )
If that is what you want, that is an effort in progress (mapping Windows
capabilities to the Extended Linux file permissions.)
James McKenzie
First off, "winetricks sandbox" almost does what you want,
except that "wineboot" (or installing ie6, or anything else that reboots
windows) will undo the sandboxing (there might be a wine bug there),
and that malicious code can very easily escape (e.g. by running native
linux code).
If you want a somewhat more secure sandbox, you could try to run wine
in a chroot jail. This is annoying but might be worth the trouble for a few
users. If you really want this right now, see
http://media.codeweavers.com/pub/crosso ... curity.pdf
which says CrossOver already supports this.
except that "wineboot" (or installing ie6, or anything else that reboots
windows) will undo the sandboxing (there might be a wine bug there),
and that malicious code can very easily escape (e.g. by running native
linux code).
If you want a somewhat more secure sandbox, you could try to run wine
in a chroot jail. This is annoying but might be worth the trouble for a few
users. If you really want this right now, see
http://media.codeweavers.com/pub/crosso ... curity.pdf
which says CrossOver already supports this.
...
Hi folks,
obviously we talk at cross purposes or I simply don't understand you. First thanks for the winetricks tip ...
I don't want Wine to be a sandbox .. a sandbox - in my understanding - not simply denies access to files but can undo changes to any part of a system like registry entries or file changes ..
What it does for me is simply the following:
If an application requests from the underlying API some drive or pathes listings it does it the way "getfilenames 'C:\*.*'" (sorry for the pseudocode, I don't have a readable win32 api reference here)
When WINE implements the windows api, why the hell do the - by wine itself implemented ! - file functions return the full listing of "/" instead of what is mapped to "C:" - and only this ! That means in that case the API file function implementation could and should only "return /home/user/.wine/somepath/*" if "C:\*" was requested. The same is for rename, open, read and so on. Of course - let Wine and the applications - and the user - do whatever they want to do to that files, but only with that files that are unlocked through the mapped drive .. and if I'd like to have access to "/" I could map it to "C:" ...
Nobody would suppose I would desire a Sandox if I Wine was a Webserver or a FTP Server that lists files outside the configured www-root or upload and download pathes ...
Maybe the behavior of Wine is a feature and not a bug - then I don't see any advantage of that .. I guess it is from the technical point of view much more complicated to deny read access to listed files of "/" like WINE does than to deny the listing ...
Hope my desire is now a little bit clearer ..
'So long
Lastcoder
obviously we talk at cross purposes or I simply don't understand you. First thanks for the winetricks tip ...
I don't want Wine to be a sandbox .. a sandbox - in my understanding - not simply denies access to files but can undo changes to any part of a system like registry entries or file changes ..
What it does for me is simply the following:
If an application requests from the underlying API some drive or pathes listings it does it the way "getfilenames 'C:\*.*'" (sorry for the pseudocode, I don't have a readable win32 api reference here)
When WINE implements the windows api, why the hell do the - by wine itself implemented ! - file functions return the full listing of "/" instead of what is mapped to "C:" - and only this ! That means in that case the API file function implementation could and should only "return /home/user/.wine/somepath/*" if "C:\*" was requested. The same is for rename, open, read and so on. Of course - let Wine and the applications - and the user - do whatever they want to do to that files, but only with that files that are unlocked through the mapped drive .. and if I'd like to have access to "/" I could map it to "C:" ...
Nobody would suppose I would desire a Sandox if I Wine was a Webserver or a FTP Server that lists files outside the configured www-root or upload and download pathes ...
Maybe the behavior of Wine is a feature and not a bug - then I don't see any advantage of that .. I guess it is from the technical point of view much more complicated to deny read access to listed files of "/" like WINE does than to deny the listing ...
Hope my desire is now a little bit clearer ..
'So long
Lastcoder
