2

What assets am I trying to protect?

An unofficial pre-alpha software prototype provided as a reproducible example for evaluation during the scientific peer-review process. The software will be officially released under an MIT/BSD style license after it has been peer reviewed. The VM has been distributed through a ftp site and as a DVD.

The stakes are low: My gut feeling is that I don't want the unofficial version circulating in the future. I want the official version, with the capacity to update and cleaned of misc. artefacts to be used and not be confused with existing copies of the old version.

Even if I extend trust to peer-reviewers and colleagues, I would like to be able to share the software more informally without having to request that the file be deleted after the official version is released.

who uses the asset you're trying to protect, and who you think might want to abuse it (and why)?

Other scientists / potential employers / unwitting recipients who have not read the disclaimer could either scoop or falsely trust the draft version of our incredible and revolutionary software. The VM itself depends on code that is still under development and not intended for the first release of the software.

what steps you've already taken to protect that asset?

  1. I have a cron job set for July 1st, 2012 to run a script cleanvm.sh to remove files. I have used the tag because this seems to provide functionality I normally associate with viruses.
  2. Using the VM requires a password.

what risks do you think you still need to mitigate?

I would like to a) prohibit transfer of files outside of the VM and b) ensure that there is no simple workaround to disable the cron-job (changing system time comes to mind). Ideally I could set up a remote kill command that I could send prior to the official release , but that might be 'overkill' for the present context.

Abe
  • 255
  • 1
  • 5
  • 1
    Because you're not worried about the IP, a time-based lockout may not be warranted. Have you considered covering it in 'Pre-Alpha' labels and disclaimers - e.g. at log on, with references to the official site where users can obtain the latest versions? – lew Apr 19 '12 at 00:38
  • why is "a) prohibit transfer of files outside of the VM" important? – lew Apr 19 '12 at 00:38
  • @lew I had not considered a simple disclaimer for the same reason that I want to prevent transfer of files outside of the VM - I don't want draft versions of code circulating. The official release is highly refactored and completely incompatable with the draft code. I don't actually know what labels and disclamers are, but inserting intermittent pre-alpha disclaimers as comments in the code would make me feel much better. – Abe Apr 19 '12 at 00:44
  • I think there are two areas to be concerned with: 1) Host-VM Security; Who has access to the VM image? Is this locked down? 2) Guest-OS Security: Strong Password Policy; Strong ACL's – Justin Andrusk Apr 19 '12 at 03:32
  • @Justin the VM image will be provided to reviewers by an anonymous password-protected ftp hosted by the publisher. It will be provided to others directly from my server. Now that you mention this, I could provide access to a VM hosted on my server to everyone except the reviewers. That would cut down the number of potential leaks. – Abe Apr 19 '12 at 14:51

2 Answers2

4

Have a good read of this question on how effective DRM controls are.

The summary is that no - if you give the code to the user, you can't control it effectively. So one option is to never give them your code:

Can you use a terminal/Citrix type solution to just allow them the experience of using your code? If so, that is the route I would recommend in your circumstances.

Of course, a possible drawback is poor user experience if they do not have sufficient bandwidth.

Community
  • 1
Rory Alsop
  • 61,474
  • 12
  • 117
  • 321
2

I think your cleanvm.sh idea is a clever one. I'd simply suggest that you have that cron run as root, and that you make sure not to distribute the root password for the VM. As long as your users aren't able to sudo or su root, they shouldn't be able to disable it.

Also, obviously, make sure that the cleanvm.sh itself is owned by root, and that permissions on that file are set to 500 or so.

Chris Allen Lane
  • 1,037
  • 1
  • 10
  • 13