Re: 2.6.6-mm1

[Andrea Arcangeli]

On Tue, May 11, 2004 at 07:23:29AM +0100, Christoph Hellwig wrote:
> On Mon, May 10, 2004 at 06:51:18PM -0700, Wim Coekaerts wrote:
> > > err, so why did I just merge the hugetlb_shm_group patch?
> > 
> > because of what you mentioned. it takes a long time before that goes
> > out, it's not even tested, and it doesn't apply to those 1000's of
> > existing systems taht will break on upgrade.   exactly what you said, it
> > makes it possible to get to a different way smoothly in time. my
> > comments were not "we can use it today".
> 
> So it's a hack for legacy oracle versions.  nice.  and for that we
> introduce completely alien concepts like magic groups into the kernel..

I don't see why we're trying to complicate the simple things.

I posted a disable_cap_mlock patch several weeks ago, that's the only
needed thing.

Even if there's an attacker on the machine with disable_cap_mlock == 1,
the attacker won't be able to exploit anything, it can only generate a
DoS. The cap-mlock is clearly not nearly as security-critical as most
other capabilities.

There's no reason to get the "hack" any smarter than the disable_cap_mlock
approch, any sysctl will be still an hack anyways. The group thing and
the differentiation between hugetlbfs users and mlock users (like
SHM_LOCK) is a mere attempt to make it more secure, but if you can
change the disable_cap_mlock sysctl from 0 to 1 you for sure can also
change the hugetlb_shm_group from 0 to 500 and the same for the
mlock_group too.  Plus I can want to give mlock to the whole system at
the same time, not just to a single group, and for that
disable_cap_mlock is appropriate.

I'm quite confortable to say that disable_cap_mlock can be dropped in
2.8, by that time a replacement solution will be implemented and I don't
expect any application learning about the disable_cap_mlock name, they
really shouldn't, only the bootup procedure of the OS will know about it
and only the login/su will learn about the future replacement.

So I believe the best "hack" is to use the simple disable_cap_mlock and
to concentrate all the efforts on a more flexible solution involving
userspace changes. The one suggested by Andrew by simply dropping the
capabilities in login and su sounded very appealing to me.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/