Bug#605090: linux-2.6: [RFC] Add a grsec featureset to Debian kernels
On sam., 2010-11-27 at 23:56 +0000, Ben Hutchings wrote:
> On Sat, 2010-11-27 at 23:34 +0100, Yves-Alexis Perez wrote:
> [...]
> > == Configuration
> >
> > The KConfig is the one I use, which is open to discussion (like
> > everything else anyway). I've tried to be fairly secure, so some
> > features might not work for some people.
> >
> > When possible, options are configurable at runtime using sysctl.
> > Attached is a tentative grsec.conf file to be put in /etc/sysctl.d so
> > people can fine-tune their installation. I didn't find a way to ship it
> > cleanly in a linux-image package so if anyone has an idea please say so.
>
> I suggest you put it in a separate package e.g. linux-grsec-base and
> have the image packages depend on or recommend it.
Good point, especially if there's some work to do for adding groups, it
might be better to do that in a linux-grsec-base package than in the
linux-image one.
>
> [...]
> > === Trusted Path Execution
> >
> > Trusted Path Execution (TPE) is a way to restrict code execution.
> > Basically, binaries execution is forbidden from paths not owned by root.
> > It's configured using a GID (which I chose to be 500, once again it can
> > and should be discussed), it and can be opt-in (users belonging to the
> > group are prevented to execute “untrusted” binaries) or opt-out (only
> > people belonging to the group can execute “untrusted” binaries). I chose
> > the latter, to have a “secure by default” system.
> >
> > === Socket restrictions
> >
> > The same kind of restrictions exist on socket, gid-based again: when you
> > add users to the relevant group, you deny them the right to create
> > sockets. I've chosen gids 501, 502 and 503 for respectively “all”
> > sockets, “client” sockets and “server” sockets. Once again, this is
> > configurable using sysctls.
>
> These gids are in the 'dynamically assigned' range and must not be
> configured into the kernel; see Debian policy §9.2.
On this, I'm not sure (but will ask base-passwd maintainers for advice).
The gids are configured in KConfig, but can be changed dynamically using
sysctl (though that means before procpcs is run the gid is still the
static one). It'd be nice to have the same gids on every system, but I'm
not sure it's really indispensable.
>
> [...]
> > == Conclusion
> >
> > So, what do you think? Does it look like a good idea, are there some
> > blockers, some implementation details to discuss? Any comment is
> > welcome.
>
> Ideally I'd like to see the worthwhile bits merged upstream in some
> form, with the most paranoid stuff in an LSM. But I'm not going to
> spend time on that myself. If you're prepared to maintain this and
> accept that it might not be kept for more than one release then I have
> no objection.
Yeah, agreed about the upstreaming part (and I'll try to give some help
there too). And yes, ideally it shouldn't be kept too long before
reaching upstream.
I'll do some tests on a linux-grsec-base package and see about the gid
stuff and report back later.
Regards,
--
Yves-Alexis Perez
ANSSI/ACE/LAM
Reply to: