On Tuesday 19 November 2002 11:03, Alex Daniloff wrote:
Hello SuSE folkz, I'm going to setup a secure file server. If somebody tries to mount secure filesystem without permission all attempts should fail.
This is a kind of "correct me if I'm wrong, but..." response: if /etc/fstab doesn't have "user" in the options, only "root" will be able to mount said partition (secure or otherwise) this is also an "all or nothing" response -- offhand I'm not sure how to specify a particular NON-root account can "mount" the partition (i.e., once you specify "user", then ALL users can mount it)
In the situation then hard drive is taken from the server all attempts to mirror the hard drive with secure filesystem should fail as well or at least nobody can reach and read that replicated data.
This is quite a bit harder -- the other response I saw so far (encrypt w/loopback) will probably be your best bet -- the reason for this is that there are hardware-based disk duplicators that don't care one bit about what is actually ON the drive: basically, it is an IDE controller (or several) and a very simple CPU that sends physical "read" commands to the master and "write" commands to all the copies -- this is totally OS and format independant. In the early days of personal computing, there were attempts to "copy protect" floppies by using hacked drivers that wrote "weak bits" or "slightly-off-center" tracks [this was mostly on the Apple computer] For every "protection" scheme devised, there were half a dozen "super copy" programs that would break said protection I even came accross one scheme that used a laser to physically burn a hole in a specific track & sector of the disk -- executable files were then encrypted and a header was added that tried to write & verify that sector -- if the data was readable, the file wasn't on one of these "special" disks. I had to break (*) this because the computer I was using this in had "80-track" drives instead of "40-track" drives -- the software was set to read "track x", but this wasn't in the same place on the 80-track hardware... Tom (*) breaking it was far too trivial: the "encryption" method consisted of XOR'ing a single byte across the rest of the executable; since the byte to be XOR'ed was always in the same place in the "header", and the header was always the same length, it was trivial to write a program that read the byte in question and "decrypt" the part you were interested in.