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

Bug#605090: Updated patch



On Wed, Jan 26, 2011 at 01:29:14PM +0100, Yves-Alexis Perez wrote:
> On mer., 2011-01-26 at 08:25 +0100, Bastian Blank wrote:
> > On Tue, Jan 18, 2011 at 06:32:50PM +0100, Yves-Alexis Perez wrote:
> > > +# Disable XEN for UDEREF support
> As the comment says, this is because UDEREF conflicts with XEN. The help
> for the Kconfig option says:

And why does it conflict with XEN? The documentation does not provide
any specific pointers. From my view it is easy, it have to run on my
test environments that features heavy virtualization of different types.

> > > +part-short-grsec: Grsecurity and PaX protection
> > This is already too long.
> What would be a good limit? Would “Grsecurity protection” work?

Should be okay.

> > > +depends: linux-grsec-base,, paxctl
> > Why is paxctl necessary? Also syntax error.
> It's not strictly a dependency so it can be demoted to Recommends (or
> moved to linux-grsec-base only) if you prefer. 

Okay.

> > > +++ debian/config/amd64/grsec/config	(revision 0)
> > Remove, no real settings here.
> What do you mean by “real” settings? PAX_PER_CPU_PGD is enabled by
> UDEREF and TASK_SIZE_MAX_SHIFT is set to 42 on amd64 because of how it
> has been implemented without segmentation.

Real settings can be modified by the user, this two can't.

> On mer., 2011-01-26 at 09:03 +0100, Bastian Blank wrote:
> On Tue, Jan 18, 2011 at 06:32:50PM +0100, Yves-Alexis Perez wrote:
> > > I've started working on 2.6.37 since Brad Sprengler recently
> released
> > > the grsecurity patch for that kernel.
> > Is there VCS or is this just a code drop without information about
> > changes? I was not even able to find older patches. Who does code
> > reviews without that information?
> No there is no VCS unfortunately.

You will need a git repository in the future. So please start with it.

> > The patch includes several modifications to selinux and random other
> > parts. Why are they not merged? Please show that they have been
> > submitted at least.
> As I already pointed out on the first mail, Brad Sprengler has already
> said he wasn't interested in upstreaming stuff.

What Brad wants or don't want is irrelevant here. While the patch policy
for the main kernel is rather strict, other featuresets can incorporate
more changes. However this is no free ticket to push anything into it.

>                                                 There is an upstreaming
> effort for some specific bits (like the
> https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Upstream
> Hardening I already gave).

Please explain how this is related to Grsecurity.

>                            The selinux-specific part are related to the
> effort to make function pointers structures read-only (or do you have
> other specific parts in mind?).

Everything that is not directly related to Grsecurity or PaX. And there
is a lot.

> > > http://git.debian.org/?p=collab-maint/linux-grsec-base.git;a=summary
> if
> > > needed.
> > Why is this not part of the patch below?
> The grsec.conf was attached to the initial bug report. As there is no
> easy way to ship an external file in the linux-image, I was told it'd be
> a better idea to make an external package and that helps because I can
> do the user creation there and add a README.

External _binary_ package, not source package.

> > > +CONFIG_DEBUG_STRICT_USER_COPY_CHECKS=y
> > Please show why this should not be enabled globaly.
> Good point, it should. I'll make a separated bug report.

No need for a bug.

> > > +CONFIG_DEBUG_RODATA=y
> Fixed.

The current patch even marks it as broken.

Bastian

-- 
Beam me up, Scotty, there's no intelligent life down here!



Reply to: