Bug#504043: initramfs: bail to shell on error: insecure default - Debian

This is a discussion on Bug#504043: initramfs: bail to shell on error: insecure default - Debian ; Package: initramfs-tools Version: 0.92l Hello, initrams created by initramfs-tools default to opening shell access to the system on errors. This is an insecure default. Errors can be induced on otherwise secured systems in many ways, like plugging in USB sticks, ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Bug#504043: initramfs: bail to shell on error: insecure default

  1. Bug#504043: initramfs: bail to shell on error: insecure default

    Package: initramfs-tools
    Version: 0.92l

    Hello,

    initrams created by initramfs-tools default to opening shell access to
    the system on errors. This is an insecure default. Errors can be induced
    on otherwise secured systems in many ways, like plugging in USB sticks,
    eSATA devices, entering wrong passphrases, or whatever.
    The rest of the system tries to ensure not to give away unauthorized
    (root) shells by asking for passwords when entering maintenance or
    single user mode, etc.

    I know that initrams can be tweaked not to bail to a shell as a
    side-effect of setting the panic= kernel parameter. However, users have
    to explicitely choose this secure way. A cleaner approach w.r.t. secure
    defaults, IMHO, would be to let users choose the insecure way by
    setting a `bailtoshell' parameter or something like that (probably at
    the kernel commandline to allow emergency intervention).

    I'm not sure about the severity of this bug report, so I leave that up
    to you.


    regards
    Mario
    --
    > As Luke Leighton said once on samba-ntdom, "now, what was that about
    > rebooting? that was so long ago, i had to look it up with man -k."


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iQEVAwUBSQoFoBS+e2HeSPbpAQLqiAf+L+/bcw/7MjyGaiBPWKzeLCaeDSZKoNXu
    PxBU2M3XzK2r90PfDW79JjCCBQTNum+WtmOJECvVNdhan9Nn8E 4ioZRCrFrsCH3B
    fSAf4DjK6ruPZYiOD6A0eOqcPtNPkitK9I5dufNsQlvNCX4176 fUkYvD3VbizMJx
    bpiGKqmn7BJHh2Wm4eBA9MHOUxYg65aOMVeiInFyIkbVAkBLho QVDd+roWbP/EjI
    E1GUI94VLfjPU4NpEYhasQcwb5lMED4nJeTaCsu3bqDfMb3Wfb +a2jiX5GWlLnK1
    aIZxzqY8O57QctwHAnwX22jIpMnF0a0wPr6PtIZz/Ce7WKK9ULO+zA==
    =Y6B6
    -----END PGP SIGNATURE-----


  2. Re: Bug#504043: initramfs: bail to shell on error: insecure default

    Mario 'BitKoenig' Holbe wrote:

    > Package: initramfs-tools
    > Version: 0.92l
    >
    > Hello,
    >
    > initrams created by initramfs-tools default to opening shell access to
    > the system on errors. This is an insecure default. Errors can be induced
    > on otherwise secured systems in many ways, like plugging in USB sticks,
    > eSATA devices, entering wrong passphrases, or whatever.
    > The rest of the system tries to ensure not to give away unauthorized
    > (root) shells by asking for passwords when entering maintenance or
    > single user mode, etc.
    >
    > I know that initrams can be tweaked not to bail to a shell as a
    > side-effect of setting the panic= kernel parameter. However, users have
    > to explicitely choose this secure way. A cleaner approach w.r.t. secure
    > defaults, IMHO, would be to let users choose the insecure way by
    > setting a `bailtoshell' parameter or something like that (probably at
    > the kernel commandline to allow emergency intervention).
    >
    > I'm not sure about the severity of this bug report, so I leave that up
    > to you.
    >
    >
    > regards
    > Mario


    When this happens no service is running, that can enable remote login on the
    system

    If someone has physical access to the system the described procedure (live
    usb/cd/dvd) could not be prevented.

    I prefer there for encrypting all including the root fs too.

    Last experience with initramfs and 2.6.26-1 is impressing me, I don't see
    such a problem with it. initrd was created with dm-crypt module and the
    boot process (/init script) asked for password.

    The only problem I see is when you have more than one encrypted root
    attached. It takes always the first one.

    regards


    --
    To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

+ Reply to Thread