[10:10] loger joined #vserver. [10:54] kestrel_ (~athomas@dialup51.optus.net.au) left irc: Ping timeout: 480 seconds [11:24] mhepp (~mhepp@213.211.38.19) joined #vserver. [11:30] kloo (~kloo@213.84.79.23) joined #vserver. [11:30] hi. [12:16] re [12:16] finished reading the log files ;) [12:50] mhepp (~mhepp@213.211.38.19) left irc: Remote host closed the connection [14:19] serving (~serving@213.186.190.41) left irc: Ping timeout: 493 seconds [14:36] infowolfe (~infowolfe@68.33.215.209) left irc: Read error: Connection reset by peer [14:36] kestrel_ (~athomas@192.65.90.115) joined #vserver. [14:51] pflanze (~chris@80.218.18.160) left irc: Ping timeout: 493 seconds [15:01] infowolfe (infowolfe@pcp04891550pcs.frnkmd01.md.comcast.net) joined #vserver. [16:11] serving (~serving@213.186.189.120) joined #vserver. [16:33] pflanze (~chris@129.132.19.124) joined #vserver. [17:26] serving: ping [17:27] Nick change: Bertl_zZ -> Bertl [17:27] hi all! [17:27] hi bertl! [17:27] hi bertl [17:27] this weekend has *not* been a good one *wink* [17:27] i was just reading your reply about root and mode 0 directories. [17:28] i expect the new gentoo stuff to be ready sometime this week [17:28] @infowolfe why? [17:28] @kloo and? [17:28] playing with the capabilities doesn't allow me to change into a directory that is mode 0. [17:28] @bertl, 2 servers blew up at work [17:28] Action: infowolfe is away [17:28] @kloo as expected, wasn't it ? [17:28] phone [17:29] in your test, you don't have a mode 0 directory? [17:29] no bertl, outside a vserver, it does work. [17:29] you mean a 000 directory? [17:29] right. [17:29] mkdir a; chmod 0 a; cd a [17:29] well, that is the 000 barrier vserver introduced somewhere in ctx-10 or so ... [17:29] inside a vserver it is disallowed, and amanda (or rather gnu tar) chokes on it. [17:30] wasn't that changed to a safe chroot? [17:30] we probably get around this with the chsaferoot() [17:30] but that isn't in vserver yet ... [17:30] i didn't consider that this was the old trick to secure vserver.. [17:30] always was, ever has been ;) [17:31] it causes collateral damage as you can see.. [17:31] well, it's a little different, ... [17:31] no vserver 'user' can create a 000 root.root dir, can he? [17:32] it doesn't have to be root.root, it can be anything. [17:32] as long as it's mode 0, root can't enter it. [17:32] (or more precisely lacking x bit, of course) [17:33] or, no! [17:33] root can enter a mode 400 directory. [17:33] that's.. unexpected. [17:33] only 000 is special ... but you are right, it should not trigger on non root dirs ... have to check that ,,, [17:34] is a change from this mode 0 check to chsaferoot() planned? [17:35] i can live with it, of course, will just have to shoot users who frustrate amanda in this fashion. :) [17:35] yes, as soon as I looked through the options we have regarding chroot() we'll drop the 000 barrier .. (probably in a few weeks or month) [17:35] great. [17:36] Nick change: unriel -> riel [17:36] it has other ramifications too, now that i consider it. [17:36] it's quite common to have a cron job (like daily) to hunt for illegitimate setuid root shells or whatever. [17:37] a user can hide those now. [17:38] (from unsuspecting programs, at least.) [17:38] well, at least same behaviour in c17 ... [17:39] that's odd, i didn't encounter this before the upgrade. [17:40] from what to what did you upgrade? [17:40] from ctx17 to vs1.00. [17:40] but it could be a coincidence that it didn't happen before, i guess. [17:41] i attributed it to the upgrade without factual basis, sorry. [17:41] hmm, well let's check with ctx17 then ... [17:41] you have all versions running, bertl? [17:42] I can compile and emulate them ... yes this is required ... [17:46] Bertl, uml? [17:47] Action: infowolfe is waiting on an email regarding a client from his boss before he goes to bed [17:47] nope QEMU ... [17:48] okay, as expected ctx-17 doesn't compile at all ... [17:49] qemu, bochs-like? [17:49] or more efficient? [17:49] much more efficient ,) [17:49] how close to realmode? [17:50] there are benchmarks, on the qemu website. [17:50] http://fabrice.bellard.free.fr/qemu/benchmarks.html [17:50] i got it [17:50] thanks [17:57] okay, ctx-17 on 2.4.21 behaves exactly the same ... [17:58] Action: kloo stands corrected. [18:00] guess we'll have to live with that for the time being ... [18:01] enrico, we should talk about chroot() options soon ... [18:01] do you think you'll make the check mode 000 and ownership root:root, before transitioning to chsaferoot(), or go for chsaferoot() directly? [18:02] my first impulse was that this would be the expected behaviour, but I'm not sure that this is a good idea ... guess we have to think about it ... [18:03] if we go for 0.0, 000 there is an issue, if you set this in a vserver ... [18:03] you cannot be allowed to change this back to something else ;) [18:03] it's still not correct, but less bad and an easy mitigating fix? [18:04] i happily leave it to your judgment. [18:04] must.. have.. tea. :) [18:04] Action: kloo will return in due course. [18:10] kloo (~kloo@213.84.79.23) left irc: Read error: Connection reset by peer [18:12] kloo_ (~kloo@213.84.79.23) joined #vserver. [18:45] Nick change: Bertl -> Bertl_oO [19:09] BobR (~georg@149.148.77.157) joined #vserver. [19:58] BobR (~georg@149.148.77.157) left irc: Quit: leaving [20:07] BobR (~georg@oglgogl.BMTP.akh-wien.ac.at) joined #vserver. [20:16] Nick change: Bertl_oO -> Bertl [20:30] Nick change: BobR -> BoBR_oO [20:34] kloo_ (~kloo@213.84.79.23) left irc: Ping timeout: 493 seconds [20:39] ensc (~ircensc@134.109.116.202) joined #vserver. [20:40] hi enrico! [20:40] hello [20:40] ready to get some work done? [20:40] the sig2context? [20:40] hmm, well actually that is done, just needs user space implementation ;) [20:41] and I'm sure you will do an excellent interface ;) [20:41] I was more thinking about the chrootsafe() and similar solutions ... [20:42] chrootsafe should be independent of vserver [20:43] yes, the question is what do we need, and how do we implement it ... [20:43] do you know any 'safe' chroot() patch for the kernel? [20:44] the problem with chroot(2) is that 'rtd' is not stackable [20:44] Nick change: BoBR_oO -> BoBR [20:44] 'rtd'? [20:44] the current root-directory [20:44] (shown by lsof in this way) [20:45] Jacques idea sounds reasonably [20:45] okay, please give me a short chroot() lecture ... [20:47] within an already existing chroot you can do 'fd=open("."); chroot("foo");' --> rtd becomes /foo [20:48] when you go to 'fchdir(fd)', you can do 'chdir("..")' there and kernel will never see that '/foo' will be traversed [20:48] since was lost by the 'chroot("foo")', can by bypassed also [20:50] Jacques idea of forbidding open directories at chrootsafe() will make this attack impossible [20:54] okay let me take a look at the code ... brb ... [21:01] mhepp (~mhepp@213.211.38.19) joined #vserver. [21:08] okay jack's chrootsafe() does the following ... [21:09] - check if there are any directory open [21:11] - set_fssafe_root(current->fs) [21:12] which actually replaces the 'saferoot' of the task/fs with the inode specified ... [21:13] in vfs_permission, this is checked for existance and on match blocked ... [21:25] Bertl (~herbert@MAIL.13thfloor.at) left irc: Quit: leaving [21:25] Bertl (~herbert@212.16.62.51) joined #vserver. [21:27] Bertl (~herbert@212.16.62.51) left irc: Client Quit [21:30] Bertl (~herbert@MAIL.13thfloor.at) joined #vserver. [21:30] kloo_ (~kloo@213.84.79.23) joined #vserver. [21:32] okay, so basically chrootsafe() records the inode of the parent directory and checks against that on vfs_permission() ... [21:32] is this the perfect solution? [21:37] hmm, can anybody read me? [21:41] the inode and the device? [21:42] it actually keeps a reference to the inode ... so inode and device, yes ... [21:43] does anybody know any attempts to make chroot() safe? [21:43] because if this is it .. I do not understand, why it isn't done for 2.4/2.6 yet ... [21:46] i recall linus once saying that securing chroot() against root is infeasible, but that was years ago. [21:47] Bertl: CLONE_NEWNS [21:47] so what do we gain from a chroot() that seems safe, but isn't ... [21:47] @Rik that was my original suggestion .. remember? [21:49] "Essentially chroot is not meant to be root-secure", Linus Torvalds, 1998-09-20. [21:49] did linux have capabilities then? [21:49] and Linus is right [21:50] I guess by that point the basic capabilities were in, but it wasn't complete yet [21:50] enrico, what is the usability status of CLONE_NEWNS? [21:50] riel: CLONE_NEWNS is not a chroot() replacement at the moment [21:50] as long as you don't allow root inside a chroot to call chroot(2) it's safe [21:50] main problem is that 'mount /vservers/' does not have an effect with CLONE_NEWNS ;) [21:51] ensc: hehe [21:51] okay, maybe we should check some things step by step ... [21:51] a) is chroot with 000 for vserver safe? [21:51] riel, chroot() security depends on other things too, doesn't it? [21:52] Bertl: yes [21:52] like not being able to ptrace() a process outside the vserver, not having the capability for mknod, not being able to play devious /proc games? [21:52] b) would a chrootsafe() for general purpose be safe? (not for vserver) [21:52] Bertl: yes [21:53] BoBR (~georg@oglgogl.BMTP.akh-wien.ac.at) left irc: Quit: leaving [21:53] c) why isn't it in the kernel, instead or beside chroot()? [21:53] dunno [21:53] (c) is easy ... nobody ever went through the trouble of convincing Linus and Al Viro that such code would be needed [21:53] okay, can be proove that such a chrootsafe() would be safe? [21:54] no, but it can be proven that it's unsafe ;) [21:54] BobR (~georg@149.148.77.157) joined #vserver. [21:54] since root could still mount random block devices under the chroot [21:54] right, chrootsafe() is only the crucial aspect in the context of vserver. [21:54] riel: can be avoided with linux capabilities [21:55] ensc: at which point root can no longer mount anything [21:55] in the broader picture it is one avenue of many and Linus has declared chroot() not to be root-secure.. [21:55] riel: e.g. 'capset -CAP_ADMIN chrootsafe /mnt/foobar' [21:56] spawned shell will not have capabilties to create character devices or mount such ones [21:56] okay, let me put another question into this discussion: would a 'stronger' chroot() instead of chrootsafe() break anything? [21:56] BobR (~georg@149.148.77.157) left irc: Client Quit [21:56] yes [21:56] what and how? [21:57] would you be able to implement such a stronger chroot() using an LSM module and just the normal chroot syscall ? [21:57] all applications which are using open directories fds with chroot. 'rpm' is such an app [21:58] okay, it wouldn't be necessary to to the open dir check stuff, right? [21:58] if the 'chrootsafe' userspace tool, makes sure no such open dirs exists ... [21:58] Bertl: in Jacques implemention you NEED this check [21:59] why do you need it? [21:59] +/* First we check if there are any directory open */ [21:59] because you could bypass the dead-zone fd in the same way [21:59] then is the check ... and if everything is okay .. [21:59] then the advanced chroot() [22:00] okay, how would you do that, once chrootsafe() was done, correctly ... [22:01] what would I do? [22:01] BobR (~georg@149.148.77.157) joined #vserver. [22:01] okay, let us assume that there are 2 syscalls ... [22:02] the first checks the directory stuff ... [22:02] another option might by to register all chroot() directories in a list and go through this list at every chdir() [22:02] the second does the enhanced chroot() ... [22:02] chrootsafe() now is the execution of the first, check if okay, and execution of the second, right? [22:02] bypass: syscall_check(); fd=open("."); syscall_chroot("bar"); chdir(".."); [22:03] okay, does this help you when you are _inside_ a 'correctly' done chrootsafe()? [22:03] you must make sure that at 'chroot()': a) cwd is (or below), and b) that no directories are open [22:04] yes, but the userspace can make sure that this is so, right? [22:04] chrootsafe() relies on _one_ dead-zone [22:04] each chrootsafe() syscall assigns this dead-zone to a new value and overrides the old one [22:05] for one task, yes ... [22:05] when this task could go "before" this new dead-zone, it can bypass the old one also [22:06] hmm okay, understood ... [22:06] what about a 'root' dir/inode for a vserver context? [22:07] it is too vserver specific... [22:07] is not having a descriptor at the time of chrootsafe() enough? [22:07] one could have two processes, one opens a directory, the other performs chrootsafe() then gets a copy of process one's descriptor by a unix domain socket. [22:08] process one then has a directory descriptor below its (new) chroot point? [22:08] kloo_: true... [22:08] okay, well I don't see use for a chrootsafe() which will _only_ be used by vserver ... [22:08] (especially if we can do the same with less efford) [22:11] less effort meaning an enhanced version of the current check, Bertl? [22:11] Jacques' chrootsafe() should be checked for this unix domain socket attack; probably it works there and I do not see a way to prevent it :( [22:13] so there stays only the option to make chroot-information stackable [22:14] how does that work, ensc? [22:14] kloo_: putting the dead-zones into a list and checking each element of it at every chdir(),... [22:15] right.. [22:16] this would be done in vfs_permission()? [22:18] less efford meaning to define a / for each vserver [22:18] BobR (~georg@149.148.77.157) left irc: Quit: leaving [22:19] BobR (~georg@oglgogl.BMTP.akh-wien.ac.at) joined #vserver. [22:19] Bertl: what will you do when there are two vservers sharing the same filesystem? [22:19] Bertl: there you could do the unix socket trick also [22:19] which exactly is? [22:21] e.g. assume, they share /var/data/ with socket 's' there; vserver A opens '/vservers/A' directory fd, sends this with SCM_RIGHTS through 's' to B. B does 'fchdir(sock)', is in /vservers/A and could bypass its root [22:22] what if /dev/hda is there and accessible, he could 'xxd' the hard disk and rewrite everything ... [22:22] well you have to make sure that there isn't some socket and shared data dir ... [22:23] /dev/hda would never be there, but /home is very possible [22:23] i have /home shared between vservers, very useful. [22:23] mount --bind /shared/home/vs1 /vserver/vs1/home [22:23] should solve that ... [22:24] how so, Bertl? [22:24] how could you possibly create a socket from one server to the other? [22:25] oh, you are suggesting to not in fact have shared home directories? [22:25] sockaddr_un a={..., .sun_path="/home/foo/s"}; s=socket(AF_UNIX, ...}; bind(s, &a, sizeof a) [22:26] there is also the scenario of an attacker having an unprivileged account on the 'root' server, and root in a vserver and leveraging both to elevate privilege to root outside the vserver. [22:27] this too is an actual situation with my use of vserver. [22:27] would it be a hack to forbid directory-fds between vservers on SCM_RIGHTS? [22:27] ensc, not too bad a hack i'd say. [22:28] it's local to a machine anyway, and vservers pretend to be separate machines? [22:30] mmh, for long term CLONE_NEWNS + pivot_root seems to be the only way to do this in a reliable way [22:31] Action: kloo_ is not familiar with new-fangled stuff like that. :) [22:31] why don't we do that right now? [22:33] I have no problem to add the chrootsafe() code to the next devel release ... but why should we add it, if it gives no security, and can be done better? [22:35] BobR (~georg@oglgogl.BMTP.akh-wien.ac.at) left irc: Quit: leaving [22:35] CLONE_NEWNS is missing a merge/migrate; pivot_root is a little bit mystical for me: man-page says a lot of strange things (kernel threads will be relocated), does it work outside of mnt-points also, what will be the effects in combination with CLONE_NEWS? [22:35] chrootsafe() does not seem to offer security [22:36] well, you probably don't need pivotroot [22:36] you should be able to use recbind instead [22:36] BobR (~georg@149.148.77.157) joined #vserver. [22:36] riel: what is recbind? An atomic recursive bind? [22:37] yeah [22:37] recursive bind mount [22:38] so you could bindmount some subdirectory on / [22:39] BobR (~georg@149.148.77.157) left irc: Client Quit [22:39] and then use a new namespace to show that mount and not certain others? [22:39] okay, what of all this stuff can/will/should we use? [22:39] (sorry, just reading about NEWNS.) [22:40] yeah [22:40] riel: does not seem to work [22:40] (mounting /) [22:40] hrmmm [22:40] better ask Al Viro [22:40] switching the namespace on-the-fly seems no big deal to me ... [22:41] so basically a enter-namespace of task x/y is possible .. [22:44] is it proper that my up-to-date gentoo's mount doesn't understand --recbind? [22:48] ensc (~ircensc@134.109.116.202) left irc: Ping timeout: 493 seconds [22:48] no, there is no such thing in mount ... [22:52] BobR (~georg@149.148.77.157) joined #vserver. [22:59] is it an option to have a pivot_root() variant affect only processes in a context? [23:00] BobR (~georg@149.148.77.157) left irc: Quit: leaving [23:01] from the context perspective, I would suggest to 'setup' a namespace (however this will be done) as apropriate, and then just 'enter' that namespace ... [23:01] it seems it won't do as is, with things like "/* make sure we can reach put_old from new_root */" [23:02] so basically any namespace 'hack' or modification which gives the required security, would work ... [23:03] if this is privot_root() or something completely different, doesn't matter, if the namespace is safe ... [23:05] ick, i've been here too long. [23:06] see you Bertl, riel. [23:08] ensc (~ircensc@134.109.116.202) joined #vserver. [23:09] okay cu kloo ... [23:09] enrico, what about creating a new namespace from a directory, as in --bind and take just that for the new namespace? [23:10] sorry, local network problems :( [23:10] (BNC ethernet) [23:12] enrico, what about creating a new namespace from a directory, as in --bind and take just that for the namespace, would that be sufficient? [23:13] my comments which I wrote before my blackout: [23:13] 21:08 < ensc> [20:41] 'mount -rbind' is recbind, isn't it? [23:13] 21:08 < ensc> [20:42] mount("/vservers/ftp-sample", "/", "none", 0xc0ed5000, 0) = 0 [23:13] 21:08 < ensc> [20:42] but I still see the old / [23:13] 21:08 < ensc> [20:42] but perhaps this is an effect of the broken CLONE_NEWNS in my 2.4.22 [23:14] hmm, okay was this 'fixed' in 2.4.23rc3? [23:14] yes, but I have not tested it [23:15] does qemu 5.0 compile on your system? [23:15] IIRC you had issues with earlier versions ... [23:16] yes; what is the fastest way to setup the root filesystem? [23:16] fill a large file with zero [23:16] setup a loop device ... [23:16] sformat that ... [23:17] losetup with offset of the partition ... [23:17] mke2fs second loop ... [23:17] mount/copy ... do you need scripts for that? [23:18] what is 'offset of the partition'? [23:18] sfdisk --dump /dev/loop/0 | gawk ' [23:19] /^\/dev\/loop/ [23:19] $4 * 512 ist offset ... [23:22] ok, perhaps later. I have the feeling that this opens a new can of worms which I do not want to handle at the moment [23:22] hmm, you can have all the scripts, just make sure it compiles ... [23:23] I do not want to use anything which I do not understand completely [23:24] well, guess you will understand two scripts, 20 lines each, right? [00:00] --- Tue Nov 25 2003