From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- .../20120604/e81fe020/attachment-0001.html | 28 ++++++++++++++++++++++ .../attachments/20120604/e81fe020/attachment.html | 28 ++++++++++++++++++++++ 2 files changed, 56 insertions(+) create mode 100644 zarb-ml/mageia-dev/attachments/20120604/e81fe020/attachment-0001.html create mode 100644 zarb-ml/mageia-dev/attachments/20120604/e81fe020/attachment.html (limited to 'zarb-ml/mageia-dev/attachments/20120604/e81fe020') diff --git a/zarb-ml/mageia-dev/attachments/20120604/e81fe020/attachment-0001.html b/zarb-ml/mageia-dev/attachments/20120604/e81fe020/attachment-0001.html new file mode 100644 index 000000000..40c1994a5 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20120604/e81fe020/attachment-0001.html @@ -0,0 +1,28 @@ + + +

On Sunday, 3 June 2012 17:52:47 Colin Guthrie wrote:

+

> On the whole, this kind of "security" is basically bullshit anyway.

+


+

You can't make that assessment without understanding the rest of the security environment.

+


+

> It

+

> might make things a tiny bit harder, but if you can get into the

+

> bootloader to append a 1 on the command line,

+


+

Maybe you *can't* append anything you like to the command-line. Maybe the bootloader configuration has a 'boot single' option, which should require entry of the root password to access the system.

+


+

> you can also append

+

> init=/bin/bash too which totally bypasses everything too.

+


+

Not if the bootloader configuration is password protected (IOW, you can boot any configured option, but if you want to modify anything, you need to provide a password, different from the root password).

+


+

> So while it's

+

> maybe a nice idea, for all practical purposes, it's not any kind of real

+

> security anyway, so don't rely on it!

+


+

No security implementation relies on a single control being in place. A numebr of modern security best practices have thousands of controls, and the requirement for a password to be entered to boot single is almost always one of them, and a requirement for a bootloader password is usually another.

+


+

Regards,

+

Buchan

\ No newline at end of file diff --git a/zarb-ml/mageia-dev/attachments/20120604/e81fe020/attachment.html b/zarb-ml/mageia-dev/attachments/20120604/e81fe020/attachment.html new file mode 100644 index 000000000..40c1994a5 --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20120604/e81fe020/attachment.html @@ -0,0 +1,28 @@ + + +

On Sunday, 3 June 2012 17:52:47 Colin Guthrie wrote:

+

> On the whole, this kind of "security" is basically bullshit anyway.

+


+

You can't make that assessment without understanding the rest of the security environment.

+


+

> It

+

> might make things a tiny bit harder, but if you can get into the

+

> bootloader to append a 1 on the command line,

+


+

Maybe you *can't* append anything you like to the command-line. Maybe the bootloader configuration has a 'boot single' option, which should require entry of the root password to access the system.

+


+

> you can also append

+

> init=/bin/bash too which totally bypasses everything too.

+


+

Not if the bootloader configuration is password protected (IOW, you can boot any configured option, but if you want to modify anything, you need to provide a password, different from the root password).

+


+

> So while it's

+

> maybe a nice idea, for all practical purposes, it's not any kind of real

+

> security anyway, so don't rely on it!

+


+

No security implementation relies on a single control being in place. A numebr of modern security best practices have thousands of controls, and the requirement for a password to be entered to boot single is almost always one of them, and a requirement for a bootloader password is usually another.

+


+

Regards,

+

Buchan

\ No newline at end of file -- cgit v1.2.1