1368236295 Q * distemper Ping timeout: 480 seconds
1368236533 Q * Aiken Quit: Leaving
1368236551 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f
1368237610 Q * hparker Quit: I've fallen off the 'net and can't get up
1368237632 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647
1368237886 Q * ensc|w Remote host closed the connection
1368237972 Q * BlackPanx Remote host closed the connection
1368237994 J * BlackPanx ~alen@31.15.133.178
1368238139 J * michal_ ~michal@168.63.70.79
1368238139 Q * michal Read error: Connection reset by peer
1368238149 N * michal_ michal
1368238510 Q * Aiken Quit: Leaving
1368241326 N * Bertl_zZ Bertl
1368241329 M * Bertl morning folks!
1368244539 Q * hparker Quit: I've fallen off the 'net and can't get up
1368246247 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647
1368247876 J * distemper ~user@2001:470:50b6:0:90d2:f5b9:8124:4f57
1368248876 Q * marcel__ Ping timeout: 480 seconds
1368249449 J * marcel__ ~marcel@pd95c7474.dip0.t-ipconnect.de
1368253713 N * l0kit Guest4972
1368253718 J * l0kit ~1oxT@0001b54e.user.oftc.net
1368254118 Q * Guest4972 Ping timeout: 480 seconds
1368255612 M * Arach jrklein, I got distracted and then went to sleep, sorry. Yes, Bertl is right, it's about Grsecurity. Vserver patch by itself doesn't, afaik, try to prevent exploitation of any vulnerability classes in the kernel, which provides a very wide attack surface. Vserver "just" isolates userland processes from each other, with the assumption (?) that the the attacker for some reason won't be able to exploit kerne
1368255613 M * Arach l vulnerabilities to escape the isolated environment. But this assumption is moslty false these days, even in case of averagely skilled attacker, since the kernel is full of vulnerabilities, and many of them are exploitable without much effort. There are many PoC exploits and even some exploit frameworks to make the task of linux kernel exploitation even more trivial. So the kernel itself have to be prote
1368255613 M * Arach cted somehow, and that's what Grsecurity does (and SELinux does not, btw), albeit not perfectly, so the risks still remain, yet in a considerably mitigated form. I'd recommend you to give the vserver+grsec patches a try, and I hope the fact they are available for 3.2.x kernels only won't stop you. :)
1368255690 M * Arach https://grsecurity.net/~spender/vserver/ <- here.
1368255727 M * Bertl well, if you can show a kernel exploit which works in a properly configured Linux-VServer guest, I'd gladly fix it :)
1368255869 M * Arach Bertl, and if I can't show such exploit right now, what conclusions would you make? ;)
1368255902 M * Bertl I'm not the one jumping to conclusions here :)
1368255950 M * Bertl fact is, there has been a single kernel exploit which affected Linux-VServer over the last 10 years, and that one basically affected every Linux system at that time
1368255976 M * Bertl and of course, it was fixed upstream a few days later
1368256009 M * Bertl note: I'm not saying that the kernel isn't full of bugs, otherwise no kernel updates would be required
1368256057 M * Bertl but also note that it usually is not possible to use the typical exploits inside a guest, because of the limited capabilities and hardware access
1368256327 M * Arach But vserver isn't a common target, while most of the PoC exploits were targeting the mainline kernel. So it's unclear, to say the least, whether or not vserver kernels could be actually "affected by exploits" (I'd prefer "contained exploitable vulnerabilities" instead, and it's *not* the same). Speaking of capabilities, they are enforced by the kernel and can't usually prevent its exploitation, unless the
1368256327 M * Arach  vulnerable code path is unavailable for not-capable processes.
1368256562 M * Arach But I agree (though I didn't check) that "typical" exploits wouldn't likely work on vserver kernels, at least not without modifications. The question is: it it really difficult to make such modifications or even to make a private exploit which would target vserver kernels specifically.
1368256571 M * Bertl okay, let's say there is an exploit, which doesn't require priviledges/capabilities to work, and let's further assume, the exploit causes something evil to happen
1368256581 M * Bertl how would grsec help?
1368256924 M * Arach Let's say, we have a userland pointer dereference (the superclass of null ptr deref) vulnerability, which exploitation, obviously, requires that userland address space should be available for the kernel access (read, or execute if our payload is in userspace memory). Grsecurity (and PaX in particular) tries to prevent such access other than at the copy_from_user call sites and some other similar cases. De
1368256924 M * Arach pending on platform, such prevention may work partially (x86_64) or totally (x86), but the exploitation (privesc or code execution) becomes a not trivial task anyway, if possible at all.
1368257092 M * Arach It's described, albeit briefly, in the documentation (kconfig help mostly, plus some pieces online) and the wikibook: https://en.wikibooks.org/wiki/Grsecurity
1368257236 M * Arach I suggest the kconfig help for a start, since it's more up to date and not less detailed than the wikibook.
1368257322 M * Bertl so, why should the kernel execute (in kernel space) code from userland?
1368257357 M * Bertl there are no known points in the kernel where userspace is directly 'transported
1368257364 M * Bertl ' into kernel space
1368257432 M * Arach It could dereference an overwritten function pointer, for example.
1368257445 M * Bertl what would override it?
1368257456 M * Bertl *overwrite
1368257456 M * Arach The vulnerability. ;)
1368257494 M * Bertl okay, any example (actual or made up) how that happens?
1368257495 M * Arach It's when an attacker is able to trick the kernel to write some value, which he controls, to some particular location in the kernel memory.
1368257537 M * Arach https://grsecurity.net/~spender/exploits/ - quick link.
1368257563 M * Bertl and did you try them in a Linux-VServer guest?
1368257687 M * Bertl the problem is, all those exploits assume access to functions and/or capabilities/missing limits which are simply not there in a guest
1368257693 M * Arach nou, I didn't, and as I said, they'll more likely fail. But not because of some vserver magic, but because of the fact they are written for another target, which is different in details only (structure members and their exact locations in the memory).
1368257728 M * Bertl I'd say, you won't be able to make any of those exploits work in a properly configured Linux-VServer guest
1368257782 M * Arach Well, let's redirect your claim to spender and pipacs and see if they have something to say or rather show. :)
1368257787 M * Bertl think about it like that: you know you have a lock-pick which works on a Linux kernel (specific one), but in Linux-VServer, you simply do not have the lock to pick in the first place
1368257842 M * Arach That's not true for most of vulnerabilities, since they are *not* - and that's a fact - use any unavailable "functions and/or capabilities/missing limits".
1368257861 M * Arach s/use/using/
1368257870 M * Bertl okay, so again, pick one as example
1368257902 M * Arach Example of vulnerability or particular exploit which will work on some vserver kernel?
1368257920 M * Bertl which would work if adapted
1368257976 M * Arach OK, let me find some in-depth description of one.
1368258174 M * Arach I was thinking about the vmsplice bug as an example of arbitrary write (a little bit too arbitrary, so I'm not even sure grsec prevented it ;), but isn't that one is the bug you were talking about: "there has been a single kernel exploit which affected Linux-VServer over the last 10 years"? 
1368258205 M * Arach Bertl, ping.
1368258928 M * Bertl well, vmsplice was fixed, so no go there, and as you said, that wouldn't have been prevented by grsec stuff either but more importantly, that was a local root exploit, which wouldn't help too much in gaining host root
1368259013 M * Bertl the problem is, 99% of all exploits either use a kernel interface to somehow inject code into the kernel or utilize already existing kernel malfunctions to change task priviledges
1368259042 Q * nkukard Remote host closed the connection
1368259065 J * nkukard ~nkukard@197.87.148.190
1368259065 M * Bertl in a properly configured Linux-VServer guest, basically none of the critical kernel interfaces are available (like module loading, kernel memory access, etc)
1368259122 M * Bertl also, altering task priviledges usually requires communication with some root process or similar, which will again be restricted to processes inside the guest
1368259158 M * Arach Now I don't even sure where to start. :)
1368259181 M * Bertl I'm not saying that there is no chance to escape and I'm not saying that grsec might not help to prevent such attacks (e.g. on the host) and if configured properly, it can help a lot inside guests as well
1368259233 M * Bertl but stating that anything without grsec is per definition insecure is just narrow minded IMHO
1368259303 M * Arach But you're wrong in so many things... First of all, any public vulnerability is fixed at the moment, except some not "very" public cases maybe. But it doesn't change the fact that such vulnerabilities existed, and so their existence was affecting vserver's security. Why should we ignore the history? That's the way to repeat the mistakes of the past, usually.
1368259349 M * Arach I didn't state that. Not even I stated that anything with grsec is secure.
1368259497 M * Arach What grsec implements is some poor choices we have today, not even to fix the deficiencies, but just lower the harm in case they are exploited by someone.
1368259523 M * Bertl so we can agree that every linux kernel is insecure, with or without grsec, and we also can agree that both Linux-VServer and grsec makes it a little bit more resilient against known/typical exploits
1368259698 M * Arach nou, we don't agree. Details do matter. Everything is not perfect, but it doesn't change the fact there are better or worse things, right or wrong ones, even though not absolutely right or wrong. So I don't buy this. And a little bit more resilient? In case of vserver - yes it's "a little bit", but in case of grsecurity - no, it's considerably more resilient. And there are objective reasons for that diffe
1368259699 M * Arach rence, not just someone's matters of preference.
1368259699 M * Bertl but I suggest that you do not comment with phrases like 'If security isn't among your primary concerns' if somebody states that he wants to use Linux-VServer for something (e.g. hosting)
1368259728 M * Arach stupid hexchat replaces the "no". :)
1368259797 M * Arach Well, the poor security of vserver isn't its devs' fault.
1368259799 M * Bertl as I said, haven't seen an exploit which worked on Linux-VServer but would have failed on grsec
1368259810 M * Arach But that's a fact. Should I be silent about facts?
1368259859 M * Bertl what facts?
1368259884 M * Bertl all you do is hand waving
1368259898 M * Arach OK, maybe, just maybe you'll see such exploit in the future. If spender or pipacs or anyone else would like to spend their time to prove this for good. I'm not exploit writer myself, unfortunately.
1368259997 M * Arach Bertl, are you one of the vserver devs?
1368260022 M * Bertl yes, I'm doing the kernel side since 12 years
1368260043 M * Arach Good. It may be important.
1368260148 M * Arach Bertl, may I pastebin our conversation? To let people decide if they want to participate as PoC writers, for example.
1368260200 M * Bertl the channel is logged, so you can simply refer/point to the logs
1368260287 M * Bertl and I'm glad about any Linux-VServer exploit which is reported (to us)
1368261131 M * Bertl off for a nap .. bbl
1368261136 N * Bertl Bertl_zZ
1368261245 M * jrayhawk what a strange conversation
1368262357 M * Arach I find it rather sad.
1368262379 M * Arach If not frustrating.
1368262500 J * bonbons ~bonbons@2001:a18:20a:9d01:344a:4b7e:c76b:93fa
1368264130 J * Ghislain ~aqueos@adsl1.aqueos.com
1368265720 Q * eyck Remote host closed the connection
1368266042 J * eyck ~eyck@nat08.nowanet.pl
1368270570 Q * ircuser-1 Ping timeout: 480 seconds
1368271708 Q * morrigan Quit: leaving
1368274058 J * ircuser-1 ~ircuser-1@35.222-62-69.ftth.swbr.surewest.net
1368275147 M * Ghislain hello there, 3.4.44 does not patch with 3.4.42 one, sevral hunk failed FYI :)
1368275227 M * Ghislain pohoh
1368275230 M * Ghislain no i failed
1368275236 M * Ghislain i use 3.2.42 lol
1368275313 M * Ghislain it patches with some hunk  but that patched, sorry for the noise
1368277702 N * Bertl_zZ Bertl_oO
1368281904 Q * Ghislain Quit: Leaving.
1368281915 J * Ghislain ~aqueos@adsl1.aqueos.com
1368286739 Q * nox Ping timeout: 480 seconds
1368291603 J * quasisan1 ~sanep@c-24-218-184-186.hsd1.nh.comcast.net
1368291729 Q * glen resistance.oftc.net oxygen.oftc.net
1368291729 Q * quasisane resistance.oftc.net oxygen.oftc.net
1368291729 Q * fosco resistance.oftc.net oxygen.oftc.net
1368291745 J * glen ~glen@scratchy.delfi.ee
1368291749 J * fosco ~fosco@91.208.40.1
1368293520 J * nox ~bnc@2a01:4f8:140:40a2:6667::952
1368294757 M * Bertl_oO off for a nap ... bbl
1368294761 N * Bertl_oO Bertl_zZ
1368295660 J * clopez_ ~tau@neutrino.es
1368295790 J * s1aden ~paul@starsky.19inch.net
1368295803 Q * sladen Read error: Connection reset by peer
1368295806 N * clopez Guest5016
1368295806 N * clopez_ clopez
1368295812 Q * ivan` Ping timeout: 480 seconds
1368295851 Q * wmp Quit: ZNC - http://znc.in
1368295876 J * brambles_ lechuck@s0.barwen.ch
1368295890 J * wmp ~wmp@2001:41d0:1:8616::1
1368295896 J * daniel_hozac_ ~daniel@h149n2-spaa-a12.ias.bredband.telia.com
1368296065 J * ivan` ~ivan`@000130ca.user.oftc.net
1368296179 J * [Guy] ~korn@elan.rulez.org
1368296202 Q * wmp Quit: ZNC - http://znc.in
1368296227 Q * l0kit synthon.oftc.net larich.oftc.net
1368296227 Q * pexapor synthon.oftc.net larich.oftc.net
1368296227 Q * ccxCZ synthon.oftc.net larich.oftc.net
1368296227 Q * Guest5016 synthon.oftc.net larich.oftc.net
1368296227 Q * brambles synthon.oftc.net larich.oftc.net
1368296227 Q * kshannon synthon.oftc.net larich.oftc.net
1368296227 Q * Guy- synthon.oftc.net larich.oftc.net
1368296227 Q * daniel_hozac synthon.oftc.net larich.oftc.net
1368296243 J * pexapor ~rj@tdream.lly.earlham.edu
1368296246 J * wmp ~wmp@2001:41d0:1:8616::1
1368296273 Q * wmp 
1368296281 J * l0kit ~1oxT@0001b54e.user.oftc.net
1368296281 J * ccxCZ ~ccxCZ@156.200.broadband11.iol.cz
1368296281 J * Guy- ~korn@elan.rulez.org
1368296284 J * kshannon ~kris@kris.shannon.id.au
1368296302 J * l0kit_ ~1oxT@ARennes-653-1-218-97.w92-139.abo.wanadoo.fr
1368296306 J * wmp ~wmp@2001:41d0:1:8616::1
1368296310 N * l0kit Guest5040
1368296310 N * l0kit_ l0kit
1368296311 Q * wmp 
1368296322 Q * Guy- Ping timeout: 480 seconds
1368296343 J * wmp ~wmp@2001:41d0:1:8616::1
1368296457 Q * Guest5040 Ping timeout: 480 seconds
1368296781 Q * marcel__ Ping timeout: 480 seconds
1368297308 J * marcel__ ~marcel@pd95c7474.dip0.t-ipconnect.de
1368297956 N * Bertl_zZ Bertl
1368297959 M * Bertl back now ...
1368302512 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f
1368304444 J * orzel ~orzel@000127e2.user.oftc.net
1368304504 M * orzel hello. For the last 6 months, i have the following problem : the computer stops to answer to http/ssh requests, but things like network masquerading keeps on working. It usually happens every ~30 days but can fluctuate between 10 and 60days.
1368304535 M * orzel i was convinced the problem was some bad ram, but i did some thoroughful tests (*erm*) and the ram seems ok
1368304555 M * orzel now i start to think the pb is vserver. But i dont know how to test this.
1368304580 M * orzel i'm currently using 3.7.10-vs2.3.5.6 (since march 6th) and was previously using 3.5.7-vs2.3.4.3
1368304632 M * orzel once rebooted, i can't find anything interesting in /var/log/messages. I'm using munin and it doesn't display anything special before the crash (ram/cpu/harddisk/network...)
1368304707 M * orzel Versions of util-vserver were  0.30.216_pre3038 and before this 0.30.216_pre3025
1368304913 M * Bertl stops answering like the interface/ip was removed?
1368305002 M * Bertl do you have a serial or remote console to the host?
1368305291 M * orzel i have access to the normal console if i connect a screen
1368305320 M * orzel stops answering like if packets raeched the host but no answer were given
1368305390 M * orzel (i'm switching to 3.6.11-vs2.3.4.6, following the topic "stable" statement)
1368305799 M * Bertl but the interfaces/ips are still up, yes?
1368305838 M * Bertl or do you mean, you access the console via net, and that stops working as well?
1368305922 M * Bertl IMHO the key question is, does the host work fine (when you are not depending on network traffic/connections) maybe because the interface lost the host/guest/all IPs, or does the host stop responding (even to e.g. serial console input) as well
1368306252 M * orzel i hadn't had the opportunity to access the physical console (had to put back in production quickly -> reboot)
1368306261 M * orzel i'll try to next time, if ever
1368306280 M * orzel as said, masquerading was still working. So the network was not as bad
1368306293 M * orzel (masquerading as in "i can ping and http to host behind the server")
1368306305 M * Bertl good, because if the IPs are lost, the problem might be that a primary goes down and takes all the secondaries with it
1368306324 M * Bertl (which might even be the host IP itself in certain circumstances)
1368306333 M * orzel once i had an ssh session open, was still working
1368306333 M * Bertl s/in/under/
1368306362 M * Bertl should be easy to diagnose via serial console or real physical logon
1368306369 M * orzel i could not open another one. And thinks like "dmesg" or entering the vserver would hang
1368306389 M * Bertl that sounds more like something stuck in 'D' state
1368306398 M * orzel was more like "kernel got corrupted somehow" than anything related to network
1368306408 M * Bertl also easy to diagnose via serial/real console and magic sysrq
1368306412 M * orzel "d state" ... ?
1368306440 M * Bertl 'D' means device I/O which basically means that some data transaction is ongoing
1368306459 M * orzel ok, so what need i check next time once accessing the real console ? Supposing i manage to connect
1368306467 M * orzel i never used sysrq, only heard about it
1368306989 Q * cuba33ci Read error: Connection reset by peer
1368307088 J * cuba33ci ~cuba33ci@114-25-198-70.dynamic.hinet.net
1368307468 M * Bertl well, read up on magic sysrq, try it out while everything works (commands like magic-sysrq-h are harmless)
1368307534 M * Bertl and once the issue shows up, collect the output from various sysrq commands (like hung tasks and cpu traces), check if the interfaces and IPs are all there and let us know
1368307562 M * Bertl if it is just the IPs that are gone, then restarting networking and the guests should get everything back to normal
1368307579 M * Bertl I'm off to bed now ... have to get up early tomorrow ...
1368307594 M * Bertl have a good one everyone!
1368307599 N * Bertl Bertl_zZ
1368307612 M * orzel Bertl_zZ: ok, thx and good night
1368308179 J * Rockj rockj@rockj.net
1368308694 J * jrklein_ ~osx@proxy.dnihost.net
1368308879 Q * jrklein Ping timeout: 480 seconds
1368313013 Q * marcel__ Ping timeout: 480 seconds
1368313324 J * michal_ ~michal@168.63.70.79
1368313391 J * treaki_ 504f231e82@p4FF4A89B.dip0.t-ipconnect.de
1368313394 J * sid4windr luser@bastard-operator.from-hell.be
1368313422 Q * Rockj charon.oftc.net solenoid.oftc.net
1368313422 Q * daniel_hozac_ charon.oftc.net solenoid.oftc.net
1368313422 Q * glen charon.oftc.net solenoid.oftc.net
1368313422 Q * michal charon.oftc.net solenoid.oftc.net
1368313422 Q * imachine charon.oftc.net solenoid.oftc.net
1368313422 Q * sid3windr charon.oftc.net solenoid.oftc.net
1368313422 N * michal_ michal
1368313473 J * glen ~glen@scratchy.delfi.ee
1368313502 J * Rockj rockj@hodge.geekrevolution.net
1368313628 J * daniel_hozac_ ~daniel@h149n2-spaa-a12.ias.bredband.telia.com
1368313628 J * imachine ~imachine@robot.greenhost24.pl
1368313680 Q * bonbons Quit: Leaving
1368313786 J * marcel__ ~marcel@pd95c7474.dip0.t-ipconnect.de
1368314480 Q * Ghislain Quit: Leaving.
1368315704 P * orzel Konversation terminated!
1368316700 Q * Kabaka Remote host closed the connection