Re: [vserver] Vserver + grsec thoughts

From: Ed W <lists_at_wildgooses.com>
Date: Tue 09 Nov 2010 - 13:35:25 GMT
Message-ID: <4CD94E1D.4090806@wildgooses.com>

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
Received on Tue Nov 9 15:11:25 2010

[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Tue 09 Nov 2010 - 15:11:25 GMT by hypermail 2.1.8