[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#605090: linux-2.6: [RFC] Add a grsec featureset to Debian kernels



On dim., 2010-11-28 at 10:44 +0100, Yves-Alexis Perez wrote:
> On sam., 2010-11-27 at 23:56 +0000, Ben Hutchings wrote:
> > 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.

I've started doing that, I've put it in collab-maint for now. At the
moment it installs the sysctl.conf file and configure the groups at
installation. At one point, adding some documentation on PaX and
grsecurity stuff will be a good idea too.
> > 
> > [...]
> > > === 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.

Ok, after talking a bit with Brad Spengler it's a bit hard to make the
-proc user runtime-configurable because it'd mean either chown()ing the
whole /proc tree after running the sysctl, or something like that. A
boot parameter could be used too, but all in all, there are no real nice
way to achieve that. So I've requested from base-passwd maintainers the
allocation of 5 gids in the 60000-64999 range, and I'm waiting for their
comment.

Regards,
-- 
Yves-Alexis Perez
ANSSI/ACE/LAM




Reply to: