Bug#675467: ITP: bilibop -- run Debian from external media
Hi,
quidame@poivron.org wrote (04 Jun 2012 13:16:52 GMT) :
> This means such functions are unusable if you run Tails entirely
> into RAM (I believe with the 'toram' boot parameter, or something
> like that).
In this mode, we don't need to arm the emergency shutdown watchdog, so
we don't need to determine the underlying physical device, so we don't
need bilibop. Bilibop might be useful in every other case.
>>> 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'.
>>
>> Sure. I can't wait using it in Tails. Are there any difficulties you
>> think we may encounter in the process?
> I have tried today with the last release of Tails. It works fine but
> needs to modify two lines in the bilibop-common functions.
Great. So the hard part will rather be to integrate this with
existing, working features that *need* to modify the devices Tails
runs from (such as: setup a persistence volume).
> But commands provided by bilibop-common (drivemap) and bilibop-rules
> (lsbilibop) work partially. This is due to important changes in
> base-files and udev packages. drivemap and lsbilibop could be easily
> backported to Squeeze but in the other hand I think they are not so
> important in the Tails context. Say me what you think about.
My take on it is don't bother with these :)
> For Tails context/design, you should see in
> /usr/share/doc/bilibop-rules/examples/90-internal-drives.rules the
> rules titled A or C (forbid access to internal drives, even by
> root).
Thank you.
> But what seems so good for me, maybe is not so good for the community?
I've sent my comments, with my potential sponsor hat on, to the
RFS bug.
Reply to: