Hi Kyle I'm assuming that you are one of the pax team? I know it's already quite a maintenance effort, but would the grsec/pax folks be amenable to maintaining a more "partial" patch which would merge with the vserver stuff more easily? > When PaX is prepared for mainline the PaX team switches vanilla atomic > reference counters to unchecked variants when overflow is expected, > all others are checked. You need to know which counters from the > Vserver patchset are susceptible to intentional overflowing so they > are exempted from the refcount checks PaX preforms. It appears that this is the section I need to get a skills transfer from Rik on... I'm about to go away on a pretty serious work trip for 2 weeks, so would appreciate any help from anyone in the meantime? > As for the grsecurity patchset, I'd argue that there are a lot of > desirable features that do provide additional security to the > resulting kernel. Some examples: Agree - actually, my favourites were the larger entropy pools and the kernel logging. Just to play devils advocate on these items, can you please respond and knock me down? Note that I'm kind of ignoring the host and "assuming" it's secure and focusing on security coming entirely through vserver containers > 1. CONFIG_GRKERNSEC_KMEM > > This helps tamperproof kernel space by preventing known ways of > introducing code to the kernel /dev/kmem is not obviously accessible in a vserver guest - can you show a way of exploiting this in a vserver guest? > http://www.linuxjournal.com/magazine/anthony-lineberry-devmem-rootkits > http://lwn.net/Articles/328695/ > > 2. CONFIG_GRKERNSEC_MODHARDEN > > Having this setting would have prevented sock_sendpage and the more > recent rds kernel exploits from working correctly I just quickly tried to insert a module from a guest and got "Operation not permitted". Can you show a way to exploit? (Obviously it's an option which can be granted to a guest, but it's not the default) > 3. CONFIG_GRKERNSEC_HIDESYM I have a grsec kernel loaded so I can't check. Does the standard vserver kernel allow kernel symbols to be visible? > 4. CONFIG_GRKERNSEC_BRUTE > > This complements #3, without a measure to prevent brute forcing #3 > just slows attackers down. I see two opinions on this. On the one hand you can fork stuff pretty quickly so I guess you can bruteforce and hope the user doesn't notice the extra system load in time. On the other hand I guess most worms/automated attacks do not yet have a bruteforce option (?) and so you are resistant against the big class of automated trojans out in the wild - it could be argued that the determined attacker represents a smaller risk measure by number of attacks (obviously not necessarily smaller risk when measured by severity of attack) I think it's a desirable feature to have, but I could probably still sleep ok without it? > I know it takes a considerable amount of work to maintain this > patchset and I'm not suggesting that you should/shouldn't do a > pax+vserver only kernel, I'm simply highlighting some features in > grsecurity that I see as desirable. I think dismissing the grsecurity > portion simply as access control and chroot hardening is a gross > oversimplification (I'm not suggesting that this was necessarily your > intent). Agreed. I think the conclusion is that certain parts of grsec still look very useful, but there is a significant overlap with the vserver code. Note: If anyone else has some favourite bits of grsec that they think they can't live without then please shout? I have been refused by Spendor on several occasions, but I think it would be extremely useful if the grsec patches were available as a git repo or at least an archive made available in order to diff-the-diff? I have setup a once daily scrape of the pax patches for the time being (hope this is ok) so that I have my own archive of patches to diff against. The ideal situation would be a git repo with "feature branches" which is pulled into a master branch to generate the patch. This would make it significantly easier to chop and choose parts of the patch. Thanks for your thoughts - interested to hear your comments above? Ed W