CrossOver Support - Community Forums

Hi,
I'm wondering, which links are necessary in the "dosdevices" to validate the license successfully as well as have the bottle status as "Ready" instead of "Scanning…"
It's quite worrying for me to leave my whole drive available for windows to explore, and I would like to curtail access to my file-system to an absolute minimum for anything running in the bottles.
I have tried replicating the ~/Library/Preferences/com.codeweavers.CrossOver* directory structure in a separate directory and linking to it as if this is the Y or Z drive. Meaning, I've created a link/alias to a folder, which had either the structure "Library/Preferences/" or "Users/<USERNAME>/Library/" (in the latter case with subdirectories "Preferences" containing the codeweavers plists and license files and "Application Support" containing a link to the Library/Application Support/CrossOver directory).
Unfortunately, my attempts, were in vain.

Is there a possibility to adjust your registration check to be central instead of per bottle (i.e. CrossOver checks for the license, not the bottle)?
Is there any workaround to this issue? What do I have to do to create a "fully" isolated bottle?

Should I open a support ticket for this as a feature request?

The bottle manager should stop scanning on its own without any specific "conditions". Fruther, the licence, for as far as I know, does not required any particular bottle configuration for validation. If any of the problem persist, I would open a support ticket with the staff to solve this.

That being said...

One point you have to understand, Windows is nowhere to be found in Crossover. Crossover doesn't borrow any Windows code, and it isn't an OS either. Further, since Crossover is not Windows, most of the malware out there which require very low level APIs, just don't work under Crossover. So the access is much less of a problem than with true Windows. Of course, it remains that you might not entirely trust the windows based software you're running, in which case, we are back at square one.

There is no harm in restricting acces though, as that is always the safer choice, in particular if you like it better like that. To simplify your life, you will find winecfg in the control panel tab of each bottle in the bottle manager, as you can see here. I won't show you a picture of Winecfg, as mine is in french and under Linux, so I don't know if it would look the same for you.

In winecfg, look for the "drives" tab, or some similar title as I'm tanslating from my french version. From there, you can add, substract or modify the symbolic links to your liking. I can't really tell you how to manually change the simlinks, since I don't have a Mac, and I'm usure where stuff is on a Mac. In any case, winecfg should help to simplify the job of giving access just the way you like it.

Thanks for your reply, J-P Simard!
Yeah, I guess you can call me paranoid, but, as we've all seen this year that doesn't mean they're not out to get us (all).
So, I'd rather control access than be sorry later.

The issue is that once the symlink to Z is deleted, CrossOver tells me that my bottle expired and hangs at scanning in the "Manage Bottles" window.

I know the feeling... I have been saying for years that governments were using the web to spy on their citizens, I just didn't have the means to prove it. I haven't been called paranoïd of late.

Anyway, I have pointed the z drive to a small unimportant folder in my home directory, and it hasn't affected my bottles or the validation of the licence. I have also tried to delete z, but I haven't been able to recreate the problem on my system. Everything is fine with or without the z drive, so I'm wondering if this is not something specific to the Mac version of Crossover.

Since I can't reproduce the problem, I'm afraid I can't really be of any more help. I just want to mention that under Linux, the registration files are in cxoffice/etc, and they are license.sig and license.txt. If you moved those files, as I think you might have, that's your main problem. If you place those files where they are expected, and remove the unwanted drives with winecfg, I would think all would be fine. Which also leads me to suggest to try registering Crossover again, as shown in the manual here.

Other than that, it might be time for a support ticket.

Yeah, that might be mac-specific. Haven't moved the license files, just made a copy. They're still in ~/Library/Preferences/ (basically, /etc/, just user-specific).
Will open a support ticket, I guess, and report back.

Note that deleting those symlinks won't get you anywhere security-wise. Wine is not a virtual machine. Any Windows application can just do Mac or Linux syscalls (e.g. int 0x80 on Linux) and access Unix functionality directly, bypassing any restrictions Wine might put up.

I get it, but if the dirves aren't listed, through the virtual links, how would the windows app know there is more storage elsewhere?

Hell, every now and then, Wine / Crossover won't even acces thumb drives without some help from the user.

A malicious app could so something like this
try
{
asm("int 0x80");
/ I'm on Linux /
fd = call_open_syscall("/etc/passwd");
call_read_syscall(fd, &data);
send_to_nsa(&data);
}
catch
{
/ I'm on Windows /
read_windows_password_store(&data);
send_to_nsa(&data);
}

No need to search through Windows drives.

That said, an application that is not aware of the existence of Wine/CrossOver wouldn't find the files without drive symlinks. But such a software probably wouldn't know what to do with those Unix files if it found. You can put up a few more roadblocks by disabling access to / and $HOME to make you sleep better, but in reality it adds zero extra security.

Also beware of the My Documents, etc. folders that point to $HOME. (At least they exist on Wine, CrossOver may have some more elaborate My Documents integration scheme that I'm not aware of.)

If you want to really improve security, use a separate Unix user to run suspicious applications, use additional hardening measures like chroot or SELinux, a virtual machine or an entirely separate computer.

Thanks for the pseudo-code, it brought it home for me.

I was thinking more along the line of just a vulnerability in some app. Obviously, I wasn't thinking about a purposly designed code to test for a Linux / Mac environment.

Thanks a lot for your reply Stefan!
syscall/sysenter makes a lot of sense for malware, which is aware of the environment it runs in. (Granted, probably most from recent years.)
If we're talking about simple things like traversing directories and deleting random stuff, however, removing the obvious "exit" to system files goes a long way towards preventing that (as well as stupid PEBKAC mistakes, especially on sleep deprivation).