Re: USB key requirement.
Dan Serban wrote:
> On Wed, 12 Jan 2011 04:46:41 -0800 (PST)
> Emanoil Kotsev <deloptes@yahoo.com> wrote:
>
>>
>>
>> --- On Tue, 1/11/11, Dan Serban <dserban@lodgingcompany.com> wrote:
>>
>>
>> >
>> > I figured that after the root partition is mounted (nfs), I
>> > would have
>> > an init.d script that would work its magic.. if it's there,
>> > allow the
>> > continuation of the boot sequence (load gdm and other
>> > non-essential
>> > services). All I would require is to match against an
>> > encrypted key
>> > without user intervention.
>>
>> In fact if using PXE you don't really pay attention on security - I'm
>> wondering what good means the usb key in this case.
>
> Well, not exactly, PXE simply boots the system. I can understand your
> point if you're talking about the data that travels over the wire.
> Well that's fine, it needs to be physically accessed by a machine that
> is "allowed", if allowed, then the USB key also needs to check out to
> continue the boot sequence. Hence why I was asking to do such a
> thing. It's low security, but it requires my car keys to be at home
> with me to actually use this machine. USB key, plus a login sounds
> good enough. So if someone found out my username/password, they'd
> still need the key to be present and matched to a specific workstation.
well I would unplug the network cable and provide another bootfile to the
device to boot from. wan't be too hard.
>>
>> I would put a customized initrd file on the usb and boot from there
>>
>> >
>> > > Q: Do you have a keyboard and is it desirable to use
>> > it on boot time?
>> > > Or you want just to plugin and if the right usb is
>> > inside the boot
>> > > will go on. you can do this after the system has
>> > already booted and
>> > > you can access the usb from the diskless station.
>> >
>> > Second option, no keyboard interaction is required in my
>> > mind. If you
>> > miss having the usb stick inserted, then to move forward,
>> > hit the reset
>> > button.
>>
>> In your mind or in the specific case?
>>
>
> There is no specific case as I'm just inquiring about the possibility
> of doing such a thing.
there is a specific case, which is your case. I can not reveal specific
details, about my job, but in your case it does not make sense to use a usb
key for security in my opinion. there should be another safety mechanism to
prevent using the device.
>
>>
>> > > Q: have you heard of security
>> > > dongles
>> >
> "http://www.naturela-bg.com/index.php?categ=&page=itm&lang=en&id=45&pid=&p=";
>> > >
>> >
>> > I have heard of them, but I don't personally understand the
>> > actual
>> > difference of a specialized key, versus a usb block device
>> > with an
>> > encryption file on it.
>>
>> Well this is exactly what you are trying to do - the one link I
>> posted I was the first that popped up in google and supports linux.
>>
>> This is not a USB stick but a piece of hardware you plug in on the
>> usb slot. You can do much more (programs can be banned from starting
>> etc)
>>
>> anyway over PXE (TFTP) everything is open and security is pretty week
>> - I don't think a USB stick is really necessary to secure something.
>
> It's not to secure anything, it's to ensure I'm present, or the key
> actually is physically present. I don't want to modify _any_ data
> through the key at all.
but any one could boot the device with an ordinary live-usb linux, no?
>
>> What happens if the user plug ins instead your USB stick a normal
>> live USB ubuntu i.e. It will boot, the NFS shares can be mounted
>> (cause you authenticate on system level) and the sense of some
>> security is gone.
>
> Well, the key would be checked right after the block device is
> mounted. NFS or local is irrelevant no? How can you drop to a shell
> after the block device is mounted and the first S01 asks for the key to
> be inserted?
by booting with a live-usb or modifying your boot command line parameters
>
>> With PXE boot you have to use other security methods I think.
>>
>
> PXE is just the boot method. The only reason I mentioned it, is to
> draw the complete picture. The block device is irrelevant, the fact
> that I depend on a local DHCP/TFTP/NFS server to function means nothing
> regarding physical access. It's simply a physical limitation. The NFS
> share it's booting from is encrypted. If you know how to physically
> type in my username and password, you'd still need my key to do so.
> Otherwise I can't think of another way to add some semblance of
> security/obscurity.
Neither tftp nor nfs are secure. This is my point. I thought one can only
export directory in nfs. How is it encrypted?
the easy way in my opinion
I would use a live-usb and modify it so that it opens ssh tunnel to your
server. The you have 2 option either use local X or login to the server.
a better way in my opinion
I would use an open network from a DMZ to offer the bootfile (tftp with
readonly and no login) and vpn in a second network to mount the nfs. So I
would create a custom initrd with openvpn client inside and mount the root
from within the vpn network. Then ... if you like you can configure the usb
key to i.e. block the boot proccess. But I would just put this initd on the
usb and let the system boot form it. It would safe the dmz
regards
Reply to: