physical security and data encryption - Security

This is a discussion on physical security and data encryption - Security ; If anyone can pretty much boot in single user mode and change the root password, that opens up the system and all data to anyone who has stolen my machine. I know that if physical security is comprosmised, all bets ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: physical security and data encryption

  1. physical security and data encryption

    If anyone can pretty much boot in single user mode and change the root
    password, that opens up the system and all data to anyone who has
    stolen my machine. I know that if physical security is comprosmised,
    all bets are off on any OS, but seriously, this is way to easy to break
    into. Isn;t there any mechanism to protect the data natively within
    Linux distros (specifically Debian/Ubuntu)? Other than installing file
    system encryptoin? Thanks.


  2. Re: physical security and data encryption

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: RIPEMD160

    yusuf wrote:

    > If anyone can pretty much boot in single user mode and change the root
    > password, that opens up the system and all data to anyone who has
    > stolen my machine. I know that if physical security is comprosmised,
    > all bets are off on any OS, but seriously, this is way to easy to break
    > into. Isn;t there any mechanism to protect the data natively within
    > Linux distros (specifically Debian/Ubuntu)? Other than installing file
    > system encryptoin? Thanks.



    AFAIK you need to know the root password to log in to single user mode. But
    anyway that doesn't matter. If someone stole your computer he would just get
    the harddisk out of it and mount it into his one computer. AFAIK the only
    way
    to protect the data on the harddisk from being stolen there is encryption.
    You might just want to encrypt some single files with GnuPG though. But I
    think the easiest way is to keep your PC safe. If it is just a workstation
    you could just remove the hard disk before leaving. There are special hard
    disk cases that allow you to easily install and remove the hard disk.
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.1 (GNU/Linux)

    iQIVAwUBRFkRMtqtd8S+cgRiAQMGdA/9HdM+rWaQWcu/hTVJmlrHKnZKuIO8BG9Z
    UVBkObU/z54t97ZZDCenxSnQQUQiFLPQgozbQx0X3mIBuuKH1yQ6oYUsgq W1U32p
    ZZBQp9rI21LbqT2nmbjee7qB6qZ+EGjjVUf7+j9DOjUGLDbSRm p+pK0y3oeIzwcP
    /xnlibAS65e4+8fymZ8tgKRAVuBZI4AmSu5UHLWKbRgG/zxR+6Z98hZoJxOw0Rkr
    3SLuDuTAS7AVB2S6GmrHrpf+Jy8a/LAl4c+KY+H7CfH7H+6gFqkh4nfmkmtoWYQM
    tEN607GR5IZubG3l5JGvcQBnvDW7fgdqfYBK33Ht4oeA6qALRl sWUi2/AMFpi8By
    vsndghggvga/7aAESZQAIvn08oPHOL692DrMa3hUNjfHlVQ9fxXTFt7VK3W0Xn A2
    LMJ1/1LdU0L9bwcNT6aJhGqPi6z49biMOxElbMhIzeEF5317uMjRDSn U/SAwQlIc
    JmCCkhvGuzVQ1uz+kv0PLuQv5aNIEXAcb4M/nqbo4kdkLrdyrGZeWcVJ1/9LZOrG
    ShpLuKj3SQS8geKiyxShunmQ7L+jaJnkh3BB9RgM4mEf9XkZY/5iIze9mbj/gyUH
    DSvG2JqWqkmwaDZSQo24S3TQhMy9Fv8bhmtRa9+I0/XejE2GCl6TqnbDNVBtLwhu
    qIkx4w7yuXY=
    =OhOR
    -----END PGP SIGNATURE-----

  3. Re: physical security and data encryption

    Matthias Kirchhart wrote:
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: RIPEMD160
    >
    > yusuf wrote:
    >
    >> If anyone can pretty much boot in single user mode and change the root
    >> password, that opens up the system and all data to anyone who has
    >> stolen my machine. I know that if physical security is comprosmised,
    >> all bets are off on any OS, but seriously, this is way to easy to break
    >> into. Isn;t there any mechanism to protect the data natively within
    >> Linux distros (specifically Debian/Ubuntu)? Other than installing file
    >> system encryptoin? Thanks.

    >
    >
    > AFAIK you need to know the root password to log in to single user mode. But
    > anyway that doesn't matter. If someone stole your computer he would just get
    > the harddisk out of it and mount it into his one computer. AFAIK the only
    > way
    > to protect the data on the harddisk from being stolen there is encryption.
    > You might just want to encrypt some single files with GnuPG though. But I
    > think the easiest way is to keep your PC safe. If it is just a workstation
    > you could just remove the hard disk before leaving. There are special hard
    > disk cases that allow you to easily install and remove the hard disk.


    One of the best ways to do this transparently, is to set up encrypted
    partitions so that the reading and writing of encrypted data is done
    without user intervention. At boot, you can set up a script to prompt
    you for the pass phrase to "unlock" the encrypted partitions for R/W.

    There are multiple ways to do this under Linux, but one that is becoming
    increasingly popular and is supported in most mainstream distros with
    2.6 series kernels is dm-crypt with LUKS support.

    More information is here:

    http://www.saout.de/misc/dm-crypt/
    http://luks.endorphin.org/

    and there is a wiki here:

    http://www.saout.de/tikiwiki/tiki-index.php

    This is what I use under FC4 on a laptop and it is natively supported in
    recent versions of Debian/Ubuntu as well. I have set up /home, /tmp and
    /var as encrypted partitions using this approach, as well as encrypted
    swap space for which there is a slightly different (session specific)
    approach.

    The overhead in terms of disk I/O is minimal on my system which is a 3.2
    Ghz P4 with 2GB of RAM and a 7200 RPM 60 Gb HD. This is using 256 bit AES.

    I would give serious consideration to this approach. If you decide to go
    this route, be sure to read through the documentation and wiki to get a
    sense for set up procedures (like pre-writing random data to the HD) and
    other operational characteristics.

    This way, somebody may get your root password, but if they don't know
    the passphrase to your encrypted partitions, they can't read the data.
    Same thing if they get physical access to the drive itself.

    HTH,

    Marc Schwartz

  4. Re: physical security and data encryption

    On Wed, 03 May 2006 23:09:11 +0000, Marc Schwartz wrote:


    >
    > One of the best ways to do this transparently, is to set up encrypted
    > partitions so that the reading and writing of encrypted data is done
    > without user intervention. At boot, you can set up a script to prompt
    > you for the pass phrase to "unlock" the encrypted partitions for R/W.
    >
    > There are multiple ways to do this under Linux, but one that is becoming
    > increasingly popular and is supported in most mainstream distros with
    > 2.6 series kernels is dm-crypt with LUKS support.
    >
    > More information is here:
    >
    > http://www.saout.de/misc/dm-crypt/
    > http://luks.endorphin.org/
    >
    > and there is a wiki here:
    >
    > http://www.saout.de/tikiwiki/tiki-index.php
    >
    > This is what I use under FC4 on a laptop and it is natively supported in
    > recent versions of Debian/Ubuntu as well. I have set up /home, /tmp and
    > /var as encrypted partitions using this approach, as well as encrypted
    > swap space for which there is a slightly different (session specific)
    > approach.
    >
    > The overhead in terms of disk I/O is minimal on my system which is a 3.2
    > Ghz P4 with 2GB of RAM and a 7200 RPM 60 Gb HD. This is using 256 bit AES.
    >
    > I would give serious consideration to this approach. If you decide to go
    > this route, be sure to read through the documentation and wiki to get a
    > sense for set up procedures (like pre-writing random data to the HD) and
    > other operational characteristics.
    >
    > This way, somebody may get your root password, but if they don't know
    > the passphrase to your encrypted partitions, they can't read the data.
    > Same thing if they get physical access to the drive itself.
    >
    > HTH,
    >
    > Marc Schwartz


    I start my machine using grub, which accesses a menu.lst file in
    /boot/grub. Currently I only have one partition for the whole filesystem.
    Do I understand correctly that at least the /boot directory would have to
    be on a partition separate from the encrypted ones? Where is the
    password to unlock the encryption stored? How does it get into memory to
    verify the password that you enter?

    Thanks for your post. This should interest a lot of people.

  5. Re: physical security and data encryption

    John wrote:
    >
    > I start my machine using grub, which accesses a menu.lst file in
    > /boot/grub. Currently I only have one partition for the whole filesystem.
    > Do I understand correctly that at least the /boot directory would have to
    > be on a partition separate from the encrypted ones? Where is the
    > password to unlock the encryption stored? How does it get into memory to
    > verify the password that you enter?
    >
    > Thanks for your post. This should interest a lot of people.


    I do not have / set up as an encrypted partition, as for me, there is no
    need. There is nothing there that I need to protect. To encrypt /
    requires some additional fiddling with disk boot images and so on. More
    pain than it is worth for me.

    Yes, the /boot directory would need to be on an unencrypted partition,
    possibly unless you would boot the computer with an external drive or a
    larger USB memory stick, which I know that some folks do. That will be
    dependent upon BIOS support for booting using external devices.

    The passwords are stored encrypted in each partition header, where there
    are multiple slots for passphrases. This allows you to add new or change
    the passphrase without having to re-encrypt the whole partition. You
    might want to review the spec document that is available at the LUKS
    site above. That will describe the basic process of opening and closing
    LUKS partitions and the lower level interactions that take place.

    My partitioning approach was based upon:

    /home has of course confidential data files, documents, etc. Having
    /home separate also means that I can redo other partitions (or distro
    version upgrades) as may be required without messing around with my user
    specific stuff.

    /tmp can have various temporary files created by programs as needed and
    these _may_ contain confidential information at some point.

    /var contains a multitude of things, but for me most importantly, I use
    fetchmail/postfix/procmail for my inbound e-mail, which means that they
    go into /var/spool/mail/*, so that needs to be protected.

    swap is protected for obvious reasons.


    I have a script set up in /etc/rc.d/rc.local, which is a modification of
    the luks-open script on the wiki above. This prompts me at boot for the
    passphrases.

    There are some distro specific idiosyncrasies relative to
    configurations, so my experience on FC may (and will likely) differ than
    those on other distros (notably Debian and Gentoo). The wiki I reference
    has some good resources for general approaches. Note that the wiki
    contains information on dm-crypt plus or minus LUKS as well as setting
    up loopback devices and using LVM, so beware the potential for confusion.

    One of the coming future enhancements to this whole process will be
    tighter integration between dm-crypt/LUKS and HAL (for device mapping),
    which should help to make some of these steps more transparent.
    Preliminary enhancements have been made in GNOME's mount application
    under FC5, but that is just a first step in automating the mounting and
    unmounting of LUKS encrypted partitions.

    Spend some time reviewing the available documents and the wiki and that
    should provide some greater insight.

    There is also an e-mail list, which is accessible via Gmane's NNTP
    interface at:

    http://news.gmane.org/gmane.linux.ke...apper.dm-crypt


    HTH,

    Marc

  6. Re: physical security and data encryption

    Thanks! I will read the documentation fully.


  7. Re: physical security and data encryption

    Matthias Kirchhart wrote:

    > AFAIK you need to know the root password to log in to single user mode.


    I don't understand why no-one has nit picked on this rather grave
    misinformation -- you *do not* need to know the root password to
    login as root in single user mode (at least in the default configuration
    for all the RedHat flavours I've seen -- including up to FC4)

    > But
    > anyway that doesn't matter.


    Aaaahh, that's why no-one nit picked on it!! :-)

    > If someone stole your computer he would just get
    > the harddisk out of it and mount it into his one computer.


    There are situations where it would be good to prevent the single-
    user password-less login -- in a semi-public area, such as a lab
    in a College, the machines are physically protected against being
    opened (they have locks and stuff that would force the students
    to physically break the case to get it open -- but they would not
    do that, as it is clear for anyone that we're talking about
    vandalism, an unambiguously criminal act). So, getting physical
    access to the hard drive or to resetting the BIOS is not an
    option.

    If the BIOS setup is password-protected so that they can not
    get the computer to boot from a floppy or a CD-ROM, and they
    can not get the hard drive, then they really can't do anything
    (provided that we assume that they're not willing to physically
    violate the machine, given the near-certainty of getting in
    serious trouble and possibly face criminal charges).

    It would help, and it wouldn't be pointless to prevent single-
    user login the way it can be done.

    Carlos
    --

  8. Re: physical security and data encryption

    Marc Schwartz wrote in
    news:0Wb6g.36$WP5.27@tornado.rdc-kc.rr.com:

    > John wrote:
    >>
    >> I start my machine using grub, which accesses a menu.lst file in
    >> /boot/grub. Currently I only have one partition for the whole
    >> filesystem.
    >> Do I understand correctly that at least the /boot directory would have
    >> to be on a partition separate from the encrypted ones? Where is the
    >> password to unlock the encryption stored? How does it get into memory
    >> to verify the password that you enter?
    >>
    >> Thanks for your post. This should interest a lot of people.

    >
    > I do not have / set up as an encrypted partition, as for me, there is no
    > need. There is nothing there that I need to protect. To encrypt /
    > requires some additional fiddling with disk boot images and so on. More
    > pain than it is worth for me.
    >
    > Yes, the /boot directory would need to be on an unencrypted partition,
    > possibly unless you would boot the computer with an external drive or a
    > larger USB memory stick, which I know that some folks do. That will be
    > dependent upon BIOS support for booting using external devices.
    >
    > The passwords are stored encrypted in each partition header, where there
    > are multiple slots for passphrases. This allows you to add new or change
    > the passphrase without having to re-encrypt the whole partition. You
    > might want to review the spec document that is available at the LUKS
    > site above. That will describe the basic process of opening and closing
    > LUKS partitions and the lower level interactions that take place.
    >
    > My partitioning approach was based upon:
    >
    > /home has of course confidential data files, documents, etc. Having
    > /home separate also means that I can redo other partitions (or distro
    > version upgrades) as may be required without messing around with my user
    > specific stuff.
    >
    > /tmp can have various temporary files created by programs as needed and
    > these _may_ contain confidential information at some point.
    >
    > /var contains a multitude of things, but for me most importantly, I use
    > fetchmail/postfix/procmail for my inbound e-mail, which means that they
    > go into /var/spool/mail/*, so that needs to be protected.
    >
    > swap is protected for obvious reasons.
    >
    >
    > I have a script set up in /etc/rc.d/rc.local, which is a modification of
    > the luks-open script on the wiki above. This prompts me at boot for the
    > passphrases.


    I'm curious about this. If you enter the passphrases they are held in ram.
    Do they consider the possibility that the passphrases could be written to
    the swap partition in the clear? Or does swap get encrypted too?

    Klazmon.



  9. Re: physical security and data encryption

    Llanzlan Klazmon wrote:
    > Marc Schwartz wrote in
    > news:0Wb6g.36$WP5.27@tornado.rdc-kc.rr.com:
    >
    >> John wrote:
    >>> I start my machine using grub, which accesses a menu.lst file in
    >>> /boot/grub. Currently I only have one partition for the whole
    >>> filesystem.
    >>> Do I understand correctly that at least the /boot directory would have
    >>> to be on a partition separate from the encrypted ones? Where is the
    >>> password to unlock the encryption stored? How does it get into memory
    >>> to verify the password that you enter?
    >>>
    >>> Thanks for your post. This should interest a lot of people.

    >> I do not have / set up as an encrypted partition, as for me, there is no
    >> need. There is nothing there that I need to protect. To encrypt /
    >> requires some additional fiddling with disk boot images and so on. More
    >> pain than it is worth for me.
    >>
    >> Yes, the /boot directory would need to be on an unencrypted partition,
    >> possibly unless you would boot the computer with an external drive or a
    >> larger USB memory stick, which I know that some folks do. That will be
    >> dependent upon BIOS support for booting using external devices.
    >>
    >> The passwords are stored encrypted in each partition header, where there
    >> are multiple slots for passphrases. This allows you to add new or change
    >> the passphrase without having to re-encrypt the whole partition. You
    >> might want to review the spec document that is available at the LUKS
    >> site above. That will describe the basic process of opening and closing
    >> LUKS partitions and the lower level interactions that take place.
    >>
    >> My partitioning approach was based upon:
    >>
    >> /home has of course confidential data files, documents, etc. Having
    >> /home separate also means that I can redo other partitions (or distro
    >> version upgrades) as may be required without messing around with my user
    >> specific stuff.
    >>
    >> /tmp can have various temporary files created by programs as needed and
    >> these _may_ contain confidential information at some point.
    >>
    >> /var contains a multitude of things, but for me most importantly, I use
    >> fetchmail/postfix/procmail for my inbound e-mail, which means that they
    >> go into /var/spool/mail/*, so that needs to be protected.
    >>
    >> swap is protected for obvious reasons.
    >>
    >>
    >> I have a script set up in /etc/rc.d/rc.local, which is a modification of
    >> the luks-open script on the wiki above. This prompts me at boot for the
    >> passphrases.

    >
    > I'm curious about this. If you enter the passphrases they are held in ram.
    > Do they consider the possibility that the passphrases could be written to
    > the swap partition in the clear? Or does swap get encrypted too?
    >
    > Klazmon.


    As I noted above and in my first reply, swap is also encrypted, though
    using a session specific key generated in /etc/rc.d/rc.local. Thus,
    there is no prompt for a password/phrase at boot for swap. I don't need
    to know what it is and it is generated randomly at that time.

    There is a page on the aforementioned wiki that discusses this:

    http://www.saout.de/tikiwiki/tiki-in...=EncryptedSwap

    The one difference for me is that I am using:

    cryptsetup -c aes-cbc-essiv:sha256 -s 256 ...

    versus the 64 bit Blowfish configuration that they have listed there.

    HTH,

    Marc Schwartz

+ Reply to Thread