=== sarnold_ is now known as sarnold
=== xnox_ is now known as xnox
=== balloons is now known as Guest52943
=== rsalveti_ is now known as rsalveti
=== balloons_ is now known as balloons
=== balloons is now known as Guest93916
=== benonsoftware is now known as MerryChristmas
=== elky_ is now known as elky
=== fabo_ is now known as fabo
=== MerryChristmas is now known as benonsoftware
=== Nigel_ is now known as G
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== tarpman_ is now known as tarpman
=== mgedmin_ is now known as mgedmin
=== czchen_ is now known as czchen
[16:08] <hhorvath> cjwatson & others: could debootstrap work with a stricter chroot like http://en.wikipedia.org/wiki/Grsecurity#Chroot_restrictions ?
[16:10] <hhorvath> cjwatson & others: I have modified /usr/share/debootstrap/functions to mount stuff normally (meaning not "chroot mount" but "mount  ... $TARGET ...") , now it gets to unpack packages, before that it simply failed running "in_target mount -t proc /proc".
[16:12] <hhorvath> cjwatson & others: however, now it fails unpacking packages (which is not due to my changes), could it be that a double chroot is atempted by any of the packages that is being installed or could any package try to mount stuff outside the jail?
[16:19] <xnox> hhorvath: why do you want a stricter chroot inside debootstrap?
[16:20] <hhorvath> xnox: do you know the grsecurity linux kernel patch? assuming that is on the host system
[16:21] <hhorvath> xnox: i do not want that specifically for debootstrap, obviously it breaks things there. I wanted to know if it's possible in theory for debootstrap to operate under such conditiions
[16:21] <xnox> hhorvath: usually one secures things above debootstrap - e.g. run debootstrap in a VM, or lxc container. but it is not designed for arbitrary code execution..
[16:21] <hhorvath> xnox: I think you misunderstand me
[16:22] <xnox> hhorvath: debootstrap creates a chroot and packages are install and executing their postinst as root. Hence it's not that strict, and shouldn't be, given that one trusts and checks the archive signatures / packages one installs.
[16:23] <hhorvath> xnox: my question is not about securing debootstrap
[16:23] <hhorvath> xnox: assume I want to install ubuntu using debootstrap on my system. further assume that my system is running a patched kernel, with the stricter chroot criteria. would it be possible in theory to get debootstrap to work ?
[16:23] <xnox> hhorvath: then what do you mean "could debootstrap work with a stricter chroot" - debootstrap is only a command that used to create debian chroots, it's not used for anything else.
[16:24] <xnox> hhorvath: no idea, but debootstrap upstream is in Debian, not ubuntu.
[16:24] <xnox> hhorvath: in general it is kept very portable with minimal dependencies and can run on a wide variety of *NIX like systems.
[16:25] <hhorvath> xnox: yeah i'have seen that in the source
[16:25] <hhorvath> xnox: grsec kernels restrict the chroot, so that inside the jail, you can't mount stuff from outside, and inside you can't chroot again
[16:25] <xnox> hhorvath: debootstrap itself will probably work, however package installation will most likely fail.
[16:26] <hhorvath> xnox: I have modified debootstrap to mount before chrooting, but package unpacking fails for some reason (only on a grsec kernel, on a normal kernel, my modified version still works without problems)
[16:26] <cjwatson> hhorvath: Please don't highlight me about this; I'm not going to have time to look at things until after the holidays and in any case I don't really work on this stuff any more.
[16:27] <hhorvath> okay, sorry, thanks for your replies anyway
[16:27] <xnox> hhorvath: .... and you expect me to fix the bootstrap you broke? =) maybe you should debug it and/or report it to upstream.
[16:28] <hhorvath> no, I did not break anything. I was asking a theoretical quesiton, I never assumed you would fix it for me. I was more asking if under the conditions I have listed, debootstraping can even work in theory.
[16:29] <hhorvath> the fixing would be my part.
[16:30] <hhorvath> but I do not know the internals structures well enough to answer my question myself. maybe some packages need chroot for configuration? then it would be impossible to fix it
[16:36] <hhorvath> xnox: the exact question would be "inside chroot, does deboostrapping need another chroot?"
[16:37] <xnox> hhorvath: you can trivally read debootstrap source code, or inspect it imperically with strace.
[16:38] <xnox> hhorvath: as that's how people would approach to find out if a given syscall is required by a given process.
=== tlyu_ is now known as tlyu