Bug#675467: ITP: bilibop -- run Debian from external media
Hi, quid...@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. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85mx4ge8y0@boum.org
Bug#675467: ITP: bilibop -- run Debian from external media
Hi, Le 2012-06-03 00:59, intrigeri a écrit : Nice to hear. However, we're generally happy to replace custom code with some generic code maintained by others than us, who seem to be experts in the specific area this code is about -- especially when our own quick hack quickly shows its limits in unusual installations of Tails. We try to cap our instance of the NIH syndrom to the bare minimum. The wipe memory on shutdown is a good feature, but seems to be very hard to implement. About bilibop-common functions, you have to remember that they apply only on (physical or virtual) block devices. Specific functions have been written for aufs, but only for the case the readonly branch is the mountpoint of a block device. This means such functions are unusable if you run Tails entirely into RAM (I believe with the 'toram' boot parameter, or something like that). Ah, you mean *owned* by the disk vs. floppy group. Now (and now that I've read the referenced bug) it's perfectly clear :) I don't think it's correct and clear to tell a drive is a member of a group. Yes. Annoying for me... I have to rewrite a part of the documentation. I should begin tonight. (fixes bug #645466). I think s/fixes/is a way to workaround/ would be more correct. Unfortunately, #645466 is likely to remain unfixed even once bilibop is in Debian :( *workaround*, why not. I say 'fix' to not say 'close'. 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. Right. I'm glad we've learnt of this security issue. Thank you. I've added it to our bug tracker: https://tails.boum.org/bugs/writable_system_disk:_belongs_to_floppy_group/ Do you want to be credited for this discovery? (even if, formally speaking, you did not report it to us: had I not read debian-devel, I would probably not have learnt about it that soon, would I?) mmmh... maybe this could give additional audience to my package :) More seriously, I don't know. Why not? But I'm not alone. The author of the bugreport #645466 could be credited too. 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. This will be available in my next 'dput' on mentors.debian.net. If you really want to try it now, do as follows: 1. Boot Tails and open a session with password enabled 2. Get bilibop_0.1.tar.gz, unpack it and copy the relevant files: /lib/bilibop/rules.sh /lib/udev/bilibop_disk /lib/udev/rules.d/60-loopback.rules /lib/udev/rules.d/66-bilibop.rules 3. Copy the attachment of this message in /lib/bilibop/common.sh 4. If necessary, don't forget to change permissions of the files 5. Restart udev (this is mandatory) and trigger uevents $ sudo invoke-rc.d udev restart $ sudo udevadm trigger --action=add $ sudo udevadm trigger --action=change 6. Verify the result: $ ls -l /dev/sd* $ ls -l /dev/bilibop 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. Please note that I did not mean to suggest bilibop does not fix security issues or does not makes a system more robust: I was merely pointing out that 1. the description was not explaining why and how clearly enough to my taste; 2. I was interested and I wanted to know more. Your reply looks like a good source of inspiration to make the package description more thorough and precise. I agree. Other optional features for the desktop environment (based on Udisks). [...] Looks like this could be useful for Tails persistence feature :) Yes, this could be useful, but this could be useless too, if not correctly configured: the user could be unable to access such or such partition from Nautilus. Just remember that a feature as 'hide partitions' is either disabled or whitelist based (show all, or hide all unless what is listed by: UUID, LABEL, TYPE or USAGE). 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). I have send a RFS: #675532 I'll consider sponsoring this package. I expect my decision to be mostly a function of whether there is some bilibop feature we can use as is in Tails. How much do you care about seeing bilibop shipped in Wheezy? (I presume not much, else
Bug#675467: ITP: bilibop -- run Debian from external media
Hi, quid...@poivron.org wrote (02 Jun 2012 13:05:42 GMT) : 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. Nice to hear. However, we're generally happy to replace custom code with some generic code maintained by others than us, who seem to be experts in the specific area this code is about -- especially when our own quick hack quickly shows its limits in unusual installations of Tails. We try to cap our instance of the NIH syndrom to the bare minimum. bilibop-rules: udev rules to fix the removable drive hosting the running system, and all its partitions, as members of the 'disk' group 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). Ah, you mean *owned* by the disk vs. floppy group. Now (and now that I've read the referenced bug) it's perfectly clear :) I don't think it's correct and clear to tell a drive is a member of a group. (fixes bug #645466). I think s/fixes/is a way to workaround/ would be more correct. Unfortunately, #645466 is likely to remain unfixed even once bilibop is in Debian :( 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. Right. I'm glad we've learnt of this security issue. Thank you. I've added it to our bug tracker: https://tails.boum.org/bugs/writable_system_disk:_belongs_to_floppy_group/ Do you want to be credited for this discovery? (even if, formally speaking, you did not report it to us: had I not read debian-devel, I would probably not have learnt about it that soon, would I?) 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? Please note that I did not mean to suggest bilibop does not fix security issues or does not makes a system more robust: I was merely pointing out that 1. the description was not explaining why and how clearly enough to my taste; 2. I was interested and I wanted to know more. Your reply looks like a good source of inspiration to make the package description more thorough and precise. Other optional features for the desktop environment (based on Udisks). Such as? By setting: [...] 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. Looks like this could be useful for Tails persistence feature :) You can download the source with: dget -x http://mentors.debian.net/debian/pool/main/b/bilibop/bilibop_0.1.dsc I'll have a look, hopefully in a few days. Don't hesitate pinging me in two weeks if needed. I have send a RFS: #675532 I'll consider sponsoring this package. I expect my decision to be mostly a function of whether there is some bilibop feature we can use as is in Tails. How much do you care about seeing bilibop shipped in Wheezy? (I presume not much, else you would have posted this ITP quite sooner, but who knows, I myself have not uploaded yet all new packages I want to see in Wheezy -- the difference being I won't have to argue with myself about packaging style and tools ;) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85txytqq14@boum.org
Bug#675467: ITP: bilibop -- run Debian from external media
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? 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. 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.) Other optional features for the desktop environment (based on Udisks). Such as? 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? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85bol266mz@boum.org
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 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/7d48d1778d856f42bfd75168dc699...@poivron.org
Bug#675467: ITP: bilibop -- run Debian from external media
Package: wnpp Severity: wishlist Owner: bilibop project quid...@poivron.org * Package name: bilibop Version : 0.1 Upstream Author : bilibop project quid...@poivron.org * URL : https://poivron.org/~quidame/bilibop_project/ * License : GPL-3.0+ Programming Lang: Shell Description : run Debian from external media Bilibop is a collection of scripts using or used by other programs (initramfs- tools, udev, aufs, mount, GRUB2) to help admins to maintain a Debian GNU/Linux operating system installed on a removable and writable media. 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. The bilibop source package builds the following binaries: bilibop: metapackage 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) 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). Other optional features for the desktop environment (based on Udisks). bilibop-lockfs: make a standard installation to behave like a LiveUSB. Can be used as an alternative (and enhancement) of the fsprotect package. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120601131051.5723.72626.reportbug@xporter
