# Copy protection.

## jpp_

Hello, good afternoon.

I have a question, surely someone here will answer.

There a way to "protect" an installation?

From being duplicated.

If I, for example give someone a computer with gentoo installed, that person is not able to "duplicate" this installation? and have another computer running my installation / software?

Something like protect the system from being duplicated.

Sorry for the bad english, and thanks.,

Juan Pablo

----------

## Mad Merlin

Yes, you can. Will it be trivial to work around? Yes.

----------

## mr.sande

You could always encrypt your disk with cryptsetup / LUKS, that should be a sizable obstacle for duplicating your setup.

----------

## jpp_

 *Quote:*   

> You could always encrypt your disk with cryptsetup / LUKS, that should be a sizable obstacle for duplicating your setup.

 

that affect performance in any way?

Thanks.

----------

## Hu

Yes, performance will be affected.  However, for a modern system, the degradation is not sufficient to impact normal desktop usage.

To clarify, you do not expect the other party to have any use of the protected system, correct?  You seek only to be sure that they can be left alone with it and that they cannot usefully duplicate it?  I believe Mad Merlin's post answered with the assumption that you wanted the other user to have basic login access on the machine, but not the ability to copy the machine.

----------

## jpp_

 *Quote:*   

> To clarify, you do not expect the other party to have any use of the protected system, correct? You seek only to be sure that they can be left alone with it and that they cannot usefully duplicate it? I believe Mad Merlin's post answered with the assumption that you wanted the other user to have basic login access on the machine, but not the ability to copy the machine.

 

at first the idea was that, without any access.

But, i can create an account to give them acces without compromise the protection?

thanks,

Juan Pablo.

----------

## rh1

 *Quote:*   

> But, i can create an account to give them acces without compromise the protection? 
> 
> 

 

You could set it up so they wouldn't have access to alot of the system but working around that would still be pretty easy for them if they know what their doing.

And of course they could always boot a livecd/usb.....

----------

## jpp_

Understood. Thanks.

But, for example, if they "clone" the disk and put it in another computer.

This new machine ,,, works?

----------

## rh1

 *Quote:*   

> But, for example, if they "clone" the disk and put it in another computer. 
> 
> This new machine ,,, works?

 

Encrypting the hard drive would take care of this issue, even if they clone it, would just be garbage without key/passphrase to unencrypt

----------

## m0p

What exactly don't you want them to copy and how will they have access to the machine? If you just want to keep your home directory safe, you could make a partition or loop file for that, encrypt it with your login password and use pam_mount so that it's decrypted when you log in. However, if they have the ability to boot the machine themselves, they could quite easily boot a livecd, install a rootkit with a keylogger and just grab your password.

The only way to keep the machine completely safe (other than a hardware keylogger or a cold boot attack) would be to keep your bootloader on a USB drive that they don't have access to, encrypt the whole disk and lock everything down (turn off all non-vital suid/sgid bits, 660 all configurations that don't need to be read by user applications, run a hardened toolchain/kernel to make it harder to exploit any potential privilege escalations, etc), but they won't be able to boot the thing without your assistance.

----------

## jpp_

Im only care by the fact: they remove the hard drive, make a copy (clone) and put that cloned hd in another machine. That computer is going to work.

How i can prevent that specific situation.

Thanks.

----------

## rh1

 *Quote:*   

> Im only care by the fact: they remove the hard drive, make a copy (clone) and put that cloned hd in another machine. That computer is going to work. 
> 
> How i can prevent that specific situation. 
> 
> 

 

Encrypting the harddrive should be sufficient in this case then.

----------

## jpp_

ok then. How i do this?

Any specific method with any advantage?

Thanks.

----------

## rh1

http://en.gentoo-wiki.com/wiki/SECURITY_System_Encryption_DM-Crypt_with_LUKS

I use dm-crypt with LUKS on my laptop, also have root on lvm but that's for convience , not necessary.

The wiki article above and some googling will get you plenty of information.

----------

## jpp_

Ok, thanks you-

----------

## jpp_

Reading, interesting,

Just for curiosity, there is any way to "link" the boot process or something with some hardware id, the serial number of the disk, for example.

so if the number matchs boot, if not don't boot?

A simple-"crackeable" way.

Thanks.

----------

## ToeiRei

I remember something like the root-plug stuff in the kernel - you could 'bind' root permissions to a device. Not sure if a recent kernel still got that stuff in it anymore; Maybe something that could work for you in a slightly modified way.

BUG_ON() if you don't see the device and you get a wonderful kernel panic  :Smile: 

----------

## m0p

You could derive the key for the disk from the motherboard serial (/sys/class/dmi/id/board_serial, if it's not blank for you like it is for me anyway, check first) or something, maybe use an openssl-encrypted keyfile with the serial as the salt? I don't think it would be very cryptographically sound though. 

Or you could create a LUKS-encrypted loop filesystem containing a second linuxrc (and the board_serial-salted key) that actually does the unlocking (then of course unmount the loop device later on)? That way they'd have trouble finding out how you made the key. I'm not sure how cryptographically sound that is either though, but they'd have to go through a lot more effort to crack it.

There's lots of convoluted things you could do that involve tying the LUKS credentials or the process of entering them to serial numbers, but all you'll really be doing is disguising where your LUKS credentials came from, basically security through obscurity, which can't be good.

Maybe there's any security experts who could critique my idea?

Of course all of that is meaningless if you don't disable any SCSI/SATA/IDE ports that aren't in use (how many HDDs do you have? if you only have one, that would be the safest way), only have one bootable disk in the system, disable booting from CDs/USB drives, and then password the BIOS so they can't undo those settings and boot into another OS (which is basically like giving them root despite having an encrypted disk because they'd have access to /boot which is enough to plant something nasty in the kernel or initrd).

----------

## jpp_

 *ToeiRei wrote:*   

> I remember something like the root-plug stuff in the kernel - you could 'bind' root permissions to a device. Not sure if a recent kernel still got that stuff in it anymore; Maybe something that could work for you in a slightly modified way.
> 
> BUG_ON() if you don't see the device and you get a wonderful kernel panic 

 

That would be a good idea, but i cannot find that option in the kernel.

Still searching for a simple (really simple) way to link the installation to a device.

Thanks for the inputs.

If anyone have another idea please post.

Thanks.

----------

## ToeiRei

remember: anything simple is most likely found pretty soon.

smartctrl stuff checking for the disks health can read its serial number. You could abuse that in your init scripts. If disk serial doesn't match, don't start the service. Simple, but easily detected.

----------

## jpp_

 *ToeiRei wrote:*   

> remember: anything simple is most likely found pretty soon.

 

Is not a problem, im not going to sell or anything, so its fine.

 *ToeiRei wrote:*   

> smartctrl stuff checking for the disks health can read its serial number. You could abuse that in your init scripts. If disk serial doesn't match, don't start the service.

 

Interesting, how can i do that?

 *ToeiRei wrote:*   

> Simple, but easily detected.

 

Really, it's not a problem.

Thanks for your answer.

----------

## ToeiRei

emerge smartmontools and dig into the manpages. grep might come in handy too.

----------

## jpp_

Ok, thanks you.

Really apreciated.

Tomorrow im goin to read that man pages.

Thanks, Juan pablo.

----------

