13

We're installing a digital media system at the college radio station I work at. We're trying to give programmers (read; DJs, not coders) access to the music, without allowing them to copy any of it to their flash drives or transfer it across the Internet.

We're running on Windows systems (Windows XP for the client machines, and Windows Server 2008 for the media server). My idea is this.

  • Create a user (ProgramUser) that has no access at all to the digital media.
  • Create a user (MediaUser) that has read-only access to the digital media that programmers know nothing about and do not know the password to.
  • Have users log in to Windows as ProgramUser, giving them no access at all to the media.
  • Run our playback application (Traktor) as the MediaUser, allowing the programmer to play back media but not copy or modify it.

This seems like the perfect solution, but there's one gotcha. If the playback application or machine crashes, the programmer is the only person who will be able to get it running again in a reasonable amount of time (we're a 15 kW FM radio station, so downtime is a big deal). Hence my dilemma...

How can I give the programmer the ability to start our playback application as a user they do not know the password to?

Mark Henderson
  • 68,316
  • 31
  • 175
  • 255

6 Answers6

32

sudo.bat

@echo off
runas /user:Administrator /savecred %1

surprisingly it won't ask password again even after reboot or power failure

  • 2
    +1 for the correct answer. My god is that a security hole – Dave Cheney May 17 '09 at 13:16
  • seriously how is this not known to be a security hole? Why is this open?! – Marm0t Nov 02 '10 at 18:36
  • 2
    I'm fairly sure this only works if the password for the account has been saved in the Credentials Manager, so it's not really a security hole any more than it is on OSX or any other system where credentials can be saved and re-used. – Mark Henderson Nov 30 '11 at 03:12
  • You still need to know the password the 1st time around, and this will stop to work if it changes. – ivan_pozdeev Jan 26 '16 at 14:23
1

...without allowing them to copy any of it to their flash drives or transfer it across the Internet

Disable USB flash drives, Internet access, etc. on these machines.

Peter Mortensen
  • 2,319
  • 5
  • 23
  • 24
Duncan Smart
  • 330
  • 2
  • 8
0

There are a couple ways I can think of off hand to maybe get around this problem. First (and more difficult) would be to write a small windows service that launches Traktor. Thus, the ProgramUser can ask the service for a new Traktor instance, and the service is running as MediaUser so Traktor is launched as MediaUser.

Another possibility, and much easier, is to have a startup shortcut set up that launches Traktor on every log in - Windows shortcuts allow you to set the credentials of the appropriate user in the shortcut properties. If the computer ever crashes, the programmers just need to log in, and they have a new Traktor running as MediaUser!

Hopefully one of these solutions will work for you!

  • Myself and the other admin are Software Engineers so this won't be a problem. We also run another service that monitors our mixing board for GPIO input, so it's something we're already doing. This is an excellent idea, thank you! –  May 12 '09 at 16:18
0

You can make a program that starts the MediaUser's process for the DJ. This can be done so that it will run as ProgramUser.

The password/credentials for MediaUser would need to be compiled into the program, so that it knew the password, but the end user would never need to be aware of this. They'd just have a button or program that says "Restart Tracktor", and it can do all of the work.

Here is a C# example of the process. The only change would be hard-coding the credentials so the DJ doesn't see them.

  • This is basically what I was going to suggest but with the caveat that it is security through obscurity. If the end users can find and run a copy of procmon or procexp, they'll be able to get the password no problem. – Ryan Bolger May 12 '09 at 16:13
  • @Ryan: How do you get the password from procmon or procexp in this situation? You can get the user name that a process is running under, but I didn't think you could get the credentials. I understand that rev. engineering the executable with the hard-coded password would do it, but other than that, how would you get this info? –  May 12 '09 at 18:08
0

The ideal situation would be for you to modify Traktor to run as a service, with a separate GUI. This gives you the best security options - Traktor would then be running as the user with the correct credentials, and no one needs know what they are, or needs to type in the password to restart it. In fact, you can make it restart itself if it crashes in the services snapin.

Your GUI to drive Traktor then gets written as its own application that the user runs as herself, it sends messages to the Traktor service (via TCP/IP, RPC, shared memory, or any other form of IPC) to make it do what the user wants. If you made the GUI work using a cross-network protocol (for example, TCP/IP) then the user can log into her workstation and the traktor service can run on a more reliable server, possibly locked away to prevent "accidental" reboots. If you're good, you could write a web application to drive Traktor instead (that is, the web server would send the messages to the service) and your user could run the station from home!

The traktor service would be started with the server, without needing to be logged in.

Peter Mortensen
  • 2,319
  • 5
  • 23
  • 24
  • Interesting idea, but Traktor is very proprietary and doesn't really have an API. The only integration points are MIDI, Send Keys, and VST Plugins. Though the idea of Traktor as a serviced based playback engine with a custom UI is appealing as we look into a more robust custom UIs that handling things such as charting and playlist creation. –  May 12 '09 at 16:50
0

Take a look at Steel RunAs. I've used it for several scripts in my SysAdmin career when no other alternatives were plausible. It's definitely handy. It generates an executable file, in which it encrypts stored credentials. Linkage

Nick Jacques
  • 61
  • 3