Bug#675467: ITP: bilibop -- run Debian from external media
Le 2012-06-01 23:53, intrigeri a écrit :
Hi,
This looks pretty interesting and exciting to me!
Hence, a few inline questions follow.
bilibop project wrote (01 Jun 2012 13:10:51 GMT) :
One of its main goals is to fix security issues or harden standard
rules and policies to make the system more robust in this
particular situation.
This sounds awesome, but pretty vague, so I'm curious:
What security issues?
What hardening?
How more robust?
This is what i explain below...
bilibop-common: shell functions to find the drive hosting the root
filesystem (dm-crypt, LVM, loop devices, aufs and any combination of
them are supported)
This might be useful for Tails' implementation of "wipe memory on
shutdown".
I have Tails installed on a USB key; the "wipe memory on shutdown"
seems to work well,
without need of bilibop-common or whatever.
bilibop-rules: udev rules to fix the removable drive hosting the
running
system, and all its partitions, as members of the 'disk' group
(fixes bug
#645466).
I fail to understand how a drive can be a member of the 'disk' group.
Please enlighten me. (Being offline, I can't read the mentionned bug
right now, but still, the package description should make sense by
itself, without needing to access online resources.)
Boot on Debian, plug a USB/FireWire drive (key or HDD) on, and execute
'ls -l /dev/sd*':
You should see /dev/sda and its partitions as members of the 'disk'
group
(and maybe also /dev/sdb* if there is a second internal HDD). And you
should see the USB drives and their partitions as members of the
'floppy'
group. Now type, from your user account: 'groups'. If 'floppy' is in
the
list, it means you have low-level write access on devices of this
group.
You should not be member of the 'disk' group.
For example, you told me about Tails. So, boot on it (the LiveUSB, of
course)
find the drive which your system is running from (here, we say
/dev/sdb),
and, as the normal user, just type 'shred -vzn0 /dev/sdb'. Now your
'secured'
system is lost.
So, find the drive hosting the running system and protect it from user
mistakes is what I call 'fix a security issue' or 'make the system more
robust'.
Other optional features for the desktop environment (based on
Udisks).
Such as?
By setting:
UDISKS_SYSTEM_INTERNAL
UDISKS_PRESENTATION_HIDE
UDISKS_PRESENTATION_ICON_NAME
UDISKS_PRESENTATION_NAME
for devices listed in BILIBOP_RULES_* variables in
/etc/bilibop/bilibop.conf
(see udisks(7) for some details). As said above, this is optional, and
only
for convenience: hide partitions, or show them with icons and/or names
different than the defaults, or make the user able or not to mount them
from
the filemanager with or without su/sudo password.
As said in the documentation of the package, all this can be bypassed
with
pmount(1). This is not a security layer.
bilibop-lockfs: make a standard installation to behave like
a LiveUSB. Can be used as an alternative (and enhancement) of the
fsprotect package.
Interesting.
What makes it different from (or better than) fsprotect and
live-boot?
In comparison with fsprotect, bilibop-lockfs has the following
features:
1. whitelist based configuration: when bilibop-lockfs is enabled, all
local
fs are protected.
2. not only filesystems are set readonly, but also block devices
3. swap device management/policy (use it, don't use it, use it noauto,
or
use it only if encrypted)
4. notifications are send to the user at startup to say her if
temporary
or permanent changes are allowed or not, and where (mountpoints)
The section 2 is one of the features that hardens the standard rules
and
policies: it makes the system unbreakable (unless with a hammer?).
For live-boot, I don't know. I've not studied the question: can it be
used
on a standard system ? I use 'LiveUSB' comparison because the system is
running from a USB key/HDD, and nothing is written on the partition
containing
the system.
The main difference is that a standard system (I say 'standard' by
opposition
with 'live') is easier to maintain than a live system. For that, boot
in
'recovery mode' (this disables 'lockfs'), update your system or
reconfigure
such or such application, and reboot.
============================================================================
For more info about bilibop, please see
http://mentors.debian.net/package/bilibop
You can download the source with:
dget -x
http://mentors.debian.net/debian/pool/main/b/bilibop/bilibop_0.1.dsc
I have send a RFS: #675532
Cheers,
Regards,
quidame
Reply to: