[Patch] kexec_load: check CAP_SYS_MODULE

[Patch] kexec_load: check CAP_SYS_MODULE

[Amerigo Wang]

Eric pointed out that kexec_load() actually allows you to
run any code you want in ring0, this is more like CAP_SYS_MODULE.

Reported-by: Eric Paris <eparis@redhat.com>
Signed-off-by: WANG Cong <amwang@redhat.com>

---
diff --git a/kernel/kexec.c b/kernel/kexec.c
index b55045b..c30d613 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -945,7 +945,7 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
 	int result;
 
 	/* We only trust the superuser with rebooting the system. */
-	if (!capable(CAP_SYS_BOOT))
+	if (!capable(CAP_SYS_BOOT) || !capable(CAP_SYS_MODULE))
 		return -EPERM;
 
 	/*

[Patch] kexec_load: check CAP_SYS_MODULE

[Amerigo Wang]

Eric pointed out that kexec_load() actually allows you to
run any code you want in ring0, this is more like CAP_SYS_MODULE.

Reported-by: Eric Paris <eparis@redhat.com>
Signed-off-by: WANG Cong <amwang@redhat.com>

---
diff --git a/kernel/kexec.c b/kernel/kexec.c
index b55045b..c30d613 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -945,7 +945,7 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
 	int result;
 
 	/* We only trust the superuser with rebooting the system. */
-	if (!capable(CAP_SYS_BOOT))
+	if (!capable(CAP_SYS_BOOT) || !capable(CAP_SYS_MODULE))
 		return -EPERM;
 
 	/*

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [Patch] kexec_load: check CAP_SYS_MODULE

[Cong Wang]

(Forgot Cc'ing Eric Paris, adding.)

> Eric pointed out that kexec_load() actually allows you to
> run any code you want in ring0, this is more like CAP_SYS_MODULE.
>
> Reported-by: Eric Paris<eparis@redhat.com>
> Signed-off-by: WANG Cong<amwang@redhat.com>
>
> ---
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index b55045b..c30d613 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -945,7 +945,7 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
>   	int result;
>
>   	/* We only trust the superuser with rebooting the system. */
> -	if (!capable(CAP_SYS_BOOT))
> +	if (!capable(CAP_SYS_BOOT) || !capable(CAP_SYS_MODULE))
>   		return -EPERM;
>
>   	/*

Re: [Patch] kexec_load: check CAP_SYS_MODULE

[Cong Wang]

(Forgot Cc'ing Eric Paris, adding.)

> Eric pointed out that kexec_load() actually allows you to
> run any code you want in ring0, this is more like CAP_SYS_MODULE.
>
> Reported-by: Eric Paris<eparis@redhat.com>
> Signed-off-by: WANG Cong<amwang@redhat.com>
>
> ---
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index b55045b..c30d613 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -945,7 +945,7 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
>   	int result;
>
>   	/* We only trust the superuser with rebooting the system. */
> -	if (!capable(CAP_SYS_BOOT))
> +	if (!capable(CAP_SYS_BOOT) || !capable(CAP_SYS_MODULE))
>   		return -EPERM;
>
>   	/*


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [Patch] kexec_load: check CAP_SYS_MODULE

[Eric W. Biederman]

Amerigo Wang <amwang@redhat.com> writes:

> Eric pointed out that kexec_load() actually allows you to
> run any code you want in ring0, this is more like CAP_SYS_MODULE.

Let me get this straight you want to make the permission checks
less stringent by allowing either CAP_SYS_MODULE or CAP_SYS_BOOT?

CAP_SYS_BOOT is the correct capability.  Sure you can run any
code but only after rebooting.  I don't see how this differs
from any other reboot scenario.

Eric


> Reported-by: Eric Paris <eparis@redhat.com>
> Signed-off-by: WANG Cong <amwang@redhat.com>
>
> ---
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index b55045b..c30d613 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -945,7 +945,7 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
>  	int result;
>  
>  	/* We only trust the superuser with rebooting the system. */
> -	if (!capable(CAP_SYS_BOOT))
> +	if (!capable(CAP_SYS_BOOT) || !capable(CAP_SYS_MODULE))
>  		return -EPERM;
>  
>  	/*

Re: [Patch] kexec_load: check CAP_SYS_MODULE

[Eric W. Biederman]

Amerigo Wang <amwang@redhat.com> writes:

> Eric pointed out that kexec_load() actually allows you to
> run any code you want in ring0, this is more like CAP_SYS_MODULE.

Let me get this straight you want to make the permission checks
less stringent by allowing either CAP_SYS_MODULE or CAP_SYS_BOOT?

CAP_SYS_BOOT is the correct capability.  Sure you can run any
code but only after rebooting.  I don't see how this differs
from any other reboot scenario.

Eric


> Reported-by: Eric Paris <eparis@redhat.com>
> Signed-off-by: WANG Cong <amwang@redhat.com>
>
> ---
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index b55045b..c30d613 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -945,7 +945,7 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
>  	int result;
>  
>  	/* We only trust the superuser with rebooting the system. */
> -	if (!capable(CAP_SYS_BOOT))
> +	if (!capable(CAP_SYS_BOOT) || !capable(CAP_SYS_MODULE))
>  		return -EPERM;
>  
>  	/*

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [Patch] kexec_load: check CAP_SYS_MODULE

[Eric Paris]

On Thu, Jan 6, 2011 at 3:47 AM, Eric W. Biederman <ebiederm@xmission.com> wrote:
> Amerigo Wang <amwang@redhat.com> writes:
>
>> Eric pointed out that kexec_load() actually allows you to
>> run any code you want in ring0, this is more like CAP_SYS_MODULE.
>
> Let me get this straight you want to make the permission checks
> less stringent by allowing either CAP_SYS_MODULE or CAP_SYS_BOOT?

Nope, read my patch again.  It actually requires BOTH of them.

> CAP_SYS_BOOT is the correct capability.  Sure you can run any
> code but only after rebooting.  I don't see how this differs
> from any other reboot scenario.

The difference is that after a reboot the bootloader and the system
control what code is run.  kexec_load() immediately runs the new
kernel which is not controlled by the bootloader or by the system.
Imagine a situation where the bootloader and the /boot directory are
RO (enforced by hardware).   kexec_load() would let you run any kernel
code you want on the box whereas reboot would not.

>> Reported-by: Eric Paris <eparis@redhat.com>
>> Signed-off-by: WANG Cong <amwang@redhat.com>
>>
>> ---
>> diff --git a/kernel/kexec.c b/kernel/kexec.c
>> index b55045b..c30d613 100644
>> --- a/kernel/kexec.c
>> +++ b/kernel/kexec.c
>> @@ -945,7 +945,7 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
>>       int result;
>>
>>       /* We only trust the superuser with rebooting the system. */
>> -     if (!capable(CAP_SYS_BOOT))
>> +     if (!capable(CAP_SYS_BOOT) || !capable(CAP_SYS_MODULE))
>>               return -EPERM;
>>
>>       /*

Re: [Patch] kexec_load: check CAP_SYS_MODULE

[Eric Paris]

On Thu, Jan 6, 2011 at 3:47 AM, Eric W. Biederman <ebiederm@xmission.com> wrote:
> Amerigo Wang <amwang@redhat.com> writes:
>
>> Eric pointed out that kexec_load() actually allows you to
>> run any code you want in ring0, this is more like CAP_SYS_MODULE.
>
> Let me get this straight you want to make the permission checks
> less stringent by allowing either CAP_SYS_MODULE or CAP_SYS_BOOT?

Nope, read my patch again.  It actually requires BOTH of them.

> CAP_SYS_BOOT is the correct capability.  Sure you can run any
> code but only after rebooting.  I don't see how this differs
> from any other reboot scenario.

The difference is that after a reboot the bootloader and the system
control what code is run.  kexec_load() immediately runs the new
kernel which is not controlled by the bootloader or by the system.
Imagine a situation where the bootloader and the /boot directory are
RO (enforced by hardware).   kexec_load() would let you run any kernel
code you want on the box whereas reboot would not.

>> Reported-by: Eric Paris <eparis@redhat.com>
>> Signed-off-by: WANG Cong <amwang@redhat.com>
>>
>> ---
>> diff --git a/kernel/kexec.c b/kernel/kexec.c
>> index b55045b..c30d613 100644
>> --- a/kernel/kexec.c
>> +++ b/kernel/kexec.c
>> @@ -945,7 +945,7 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
>>       int result;
>>
>>       /* We only trust the superuser with rebooting the system. */
>> -     if (!capable(CAP_SYS_BOOT))
>> +     if (!capable(CAP_SYS_BOOT) || !capable(CAP_SYS_MODULE))
>>               return -EPERM;
>>
>>       /*

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [Patch] kexec_load: check CAP_SYS_MODULE

[Eric W. Biederman]

Eric Paris <eparis@parisplace.org> writes:

> On Thu, Jan 6, 2011 at 3:47 AM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>> Amerigo Wang <amwang@redhat.com> writes:
>>
>>> Eric pointed out that kexec_load() actually allows you to
>>> run any code you want in ring0, this is more like CAP_SYS_MODULE.
>>
>> Let me get this straight you want to make the permission checks
>> less stringent by allowing either CAP_SYS_MODULE or CAP_SYS_BOOT?
>
> Nope, read my patch again.  It actually requires BOTH of them.

Ah right.  Testing the negative and going to -EPERM.

>> CAP_SYS_BOOT is the correct capability.  Sure you can run any
>> code but only after rebooting.  I don't see how this differs
>> from any other reboot scenario.
>
> The difference is that after a reboot the bootloader and the system
> control what code is run.  kexec_load() immediately runs the new
> kernel which is not controlled by the bootloader or by the system.
> Imagine a situation where the bootloader and the /boot directory are
> RO (enforced by hardware).   kexec_load() would let you run any kernel
> code you want on the box whereas reboot would not.

The scenario is imaginable (not common but imaginable) but I don't see
how requiring CAP_SYS_MODULE makes anything better.

If I was building a configuration where I didn't want anyone to be able
to direct the kernel into a different state by locking down the
bootloaders I expect I would compile out the syscall as well.

Most bootloaders have the option of booting something else the mechanism
is just different. I really don't see what the addition of
CAP_SYS_MODULE gains you.

Right now CAP_SYS_BOOT still makes sense to me and CAP_SYS_MODULE stills
seems like nonsense in this context.

Eric

Re: [Patch] kexec_load: check CAP_SYS_MODULE

[Eric W. Biederman]

Eric Paris <eparis@parisplace.org> writes:

> On Thu, Jan 6, 2011 at 3:47 AM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>> Amerigo Wang <amwang@redhat.com> writes:
>>
>>> Eric pointed out that kexec_load() actually allows you to
>>> run any code you want in ring0, this is more like CAP_SYS_MODULE.
>>
>> Let me get this straight you want to make the permission checks
>> less stringent by allowing either CAP_SYS_MODULE or CAP_SYS_BOOT?
>
> Nope, read my patch again.  It actually requires BOTH of them.

Ah right.  Testing the negative and going to -EPERM.

>> CAP_SYS_BOOT is the correct capability.  Sure you can run any
>> code but only after rebooting.  I don't see how this differs
>> from any other reboot scenario.
>
> The difference is that after a reboot the bootloader and the system
> control what code is run.  kexec_load() immediately runs the new
> kernel which is not controlled by the bootloader or by the system.
> Imagine a situation where the bootloader and the /boot directory are
> RO (enforced by hardware).   kexec_load() would let you run any kernel
> code you want on the box whereas reboot would not.

The scenario is imaginable (not common but imaginable) but I don't see
how requiring CAP_SYS_MODULE makes anything better.

If I was building a configuration where I didn't want anyone to be able
to direct the kernel into a different state by locking down the
bootloaders I expect I would compile out the syscall as well.

Most bootloaders have the option of booting something else the mechanism
is just different. I really don't see what the addition of
CAP_SYS_MODULE gains you.

Right now CAP_SYS_BOOT still makes sense to me and CAP_SYS_MODULE stills
seems like nonsense in this context.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [Patch] kexec_load: check CAP_SYS_MODULE

[Eric Paris]

On Fri, 2011-01-07 at 12:10 -0800, Eric W. Biederman wrote:
> Eric Paris <eparis@parisplace.org> writes:

> >> CAP_SYS_BOOT is the correct capability.  Sure you can run any
> >> code but only after rebooting.  I don't see how this differs
> >> from any other reboot scenario.
> >
> > The difference is that after a reboot the bootloader and the system
> > control what code is run.  kexec_load() immediately runs the new
> > kernel which is not controlled by the bootloader or by the system.
> > Imagine a situation where the bootloader and the /boot directory are
> > RO (enforced by hardware).   kexec_load() would let you run any kernel
> > code you want on the box whereas reboot would not.
> 
> The scenario is imaginable (not common but imaginable) but I don't see
> how requiring CAP_SYS_MODULE makes anything better.
> 
> If I was building a configuration where I didn't want anyone to be able
> to direct the kernel into a different state by locking down the
> bootloaders I expect I would compile out the syscall as well.

As sad as it may sound the vast majority of people don't build their own
kernels.  And even those people who have the intelligence to do it are
often constrained by some non-technical policy to run 'approved'
kernels. 

> Most bootloaders have the option of booting something else the mechanism
> is just different. I really don't see what the addition of
> CAP_SYS_MODULE gains you.
> 
> Right now CAP_SYS_BOOT still makes sense to me and CAP_SYS_MODULE stills
> seems like nonsense in this context.

There is no question in my mind that CAP_SYS_BOOT makes sense.  We are
violently agreed on that point.  The problem is reboot() != kexec_load()
kexec_load() is as close to init_module() as it is to reboot().

Maybe I didn't make it clear how this is going to be used.  I plan to
drop CAP_SYS_MODULE to stop root from loading their own modules and
running their own code in the kernel.  I can control reboot() since I
control the platform and the bootloader.  I cannot control kexec().  I'm
also required to use a generic distro kernel (bet you can't guess which
one)

The only solution I see to solve the problem is to gate kexec on
CAP_SYS_MODULE.  Which makes sense since kexec() is in many respects
close to module_init() than it is to reboot().

-Eric

Re: [Patch] kexec_load: check CAP_SYS_MODULE

[Eric Paris]

On Fri, 2011-01-07 at 12:10 -0800, Eric W. Biederman wrote:
> Eric Paris <eparis@parisplace.org> writes:

> >> CAP_SYS_BOOT is the correct capability.  Sure you can run any
> >> code but only after rebooting.  I don't see how this differs
> >> from any other reboot scenario.
> >
> > The difference is that after a reboot the bootloader and the system
> > control what code is run.  kexec_load() immediately runs the new
> > kernel which is not controlled by the bootloader or by the system.
> > Imagine a situation where the bootloader and the /boot directory are
> > RO (enforced by hardware).   kexec_load() would let you run any kernel
> > code you want on the box whereas reboot would not.
> 
> The scenario is imaginable (not common but imaginable) but I don't see
> how requiring CAP_SYS_MODULE makes anything better.
> 
> If I was building a configuration where I didn't want anyone to be able
> to direct the kernel into a different state by locking down the
> bootloaders I expect I would compile out the syscall as well.

As sad as it may sound the vast majority of people don't build their own
kernels.  And even those people who have the intelligence to do it are
often constrained by some non-technical policy to run 'approved'
kernels. 

> Most bootloaders have the option of booting something else the mechanism
> is just different. I really don't see what the addition of
> CAP_SYS_MODULE gains you.
> 
> Right now CAP_SYS_BOOT still makes sense to me and CAP_SYS_MODULE stills
> seems like nonsense in this context.

There is no question in my mind that CAP_SYS_BOOT makes sense.  We are
violently agreed on that point.  The problem is reboot() != kexec_load()
kexec_load() is as close to init_module() as it is to reboot().

Maybe I didn't make it clear how this is going to be used.  I plan to
drop CAP_SYS_MODULE to stop root from loading their own modules and
running their own code in the kernel.  I can control reboot() since I
control the platform and the bootloader.  I cannot control kexec().  I'm
also required to use a generic distro kernel (bet you can't guess which
one)

The only solution I see to solve the problem is to gate kexec on
CAP_SYS_MODULE.  Which makes sense since kexec() is in many respects
close to module_init() than it is to reboot().

-Eric


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [Patch] kexec_load: check CAP_SYS_MODULE

[Eric W. Biederman]

Eric Paris <eparis@redhat.com> writes:

>> If I was building a configuration where I didn't want anyone to be able
>> to direct the kernel into a different state by locking down the
>> bootloaders I expect I would compile out the syscall as well.
>
> As sad as it may sound the vast majority of people don't build their own
> kernels.  And even those people who have the intelligence to do it are
> often constrained by some non-technical policy to run 'approved'
> kernels. 

Yes I am aware of the crazy game that is called approved kernels.  Where
there are too many regressions for people to trust new kernel releases
but people want to change the kernel and the setup from what was tested
and still have the stamp of approval anyway.  Financially it seems to
make people money, but as best I can tell that game is ultimately what
killed unix.

In this instance you seem to be redefining CAP_SYS_MODULE and
CAP_SYS_REBOOT so you can play that game. 

> Maybe I didn't make it clear how this is going to be used.  I plan to
> drop CAP_SYS_MODULE to stop root from loading their own modules and
> running their own code in the kernel.  I can control reboot() since I
> control the platform and the bootloader.  I cannot control kexec().  I'm
> also required to use a generic distro kernel (bet you can't guess which
> one)

If you are truly locked down I recommend dropping CAP_SYS_REBOOT and
setting up a watchdog that keeps the system from rebooting (standard
practice in embedded kinds of setups like you describe).  That should
meet everyone requirements without needing to game the system.

> The only solution I see to solve the problem is to gate kexec on
> CAP_SYS_MODULE.  Which makes sense since kexec() is in many respects
> close to module_init() than it is to reboot().

kexec_load is nothing like module_init().  All it does it puts data in
memory for use by a subsequent reboot.  /sbin/kexec is a bootloader that
runs inside of linux.  All you are noticing is that if you don't control
/sbin/kexec you aren't controlling the bootloader.

Eric

Re: [Patch] kexec_load: check CAP_SYS_MODULE

[Eric W. Biederman]

Eric Paris <eparis@redhat.com> writes:

>> If I was building a configuration where I didn't want anyone to be able
>> to direct the kernel into a different state by locking down the
>> bootloaders I expect I would compile out the syscall as well.
>
> As sad as it may sound the vast majority of people don't build their own
> kernels.  And even those people who have the intelligence to do it are
> often constrained by some non-technical policy to run 'approved'
> kernels. 

Yes I am aware of the crazy game that is called approved kernels.  Where
there are too many regressions for people to trust new kernel releases
but people want to change the kernel and the setup from what was tested
and still have the stamp of approval anyway.  Financially it seems to
make people money, but as best I can tell that game is ultimately what
killed unix.

In this instance you seem to be redefining CAP_SYS_MODULE and
CAP_SYS_REBOOT so you can play that game. 

> Maybe I didn't make it clear how this is going to be used.  I plan to
> drop CAP_SYS_MODULE to stop root from loading their own modules and
> running their own code in the kernel.  I can control reboot() since I
> control the platform and the bootloader.  I cannot control kexec().  I'm
> also required to use a generic distro kernel (bet you can't guess which
> one)

If you are truly locked down I recommend dropping CAP_SYS_REBOOT and
setting up a watchdog that keeps the system from rebooting (standard
practice in embedded kinds of setups like you describe).  That should
meet everyone requirements without needing to game the system.

> The only solution I see to solve the problem is to gate kexec on
> CAP_SYS_MODULE.  Which makes sense since kexec() is in many respects
> close to module_init() than it is to reboot().

kexec_load is nothing like module_init().  All it does it puts data in
memory for use by a subsequent reboot.  /sbin/kexec is a bootloader that
runs inside of linux.  All you are noticing is that if you don't control
/sbin/kexec you aren't controlling the bootloader.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [Patch] kexec_load: check CAP_SYS_MODULE

[Eric Paris]

On Fri, 2011-01-07 at 13:02 -0800, Eric W. Biederman wrote:
> Eric Paris <eparis@redhat.com> writes:

> Yes I am aware of the crazy game that is called approved kernels.  Where
> there are too many regressions for people to trust new kernel releases
> but people want to change the kernel and the setup from what was tested
> and still have the stamp of approval anyway.  Financially it seems to
> make people money, but as best I can tell that game is ultimately what
> killed unix.

I don't believe this is a particularly relevant line of conversion and
should probably drop it, but I can't completely leave it alone.  We
obviously have a very different understanding of what concerning the
unix wars brought about its death.  I'd think it obvious that the very
fact that this conversation is taking place shows that the exact
opposite of the unix wars problems are being seen here.  You clearly
have personal opinions about the benefits of custom built kernels, but
they are not the opinions of the vast majority of linux users.  I rarely
run disto kernels and I'm sure few on lkml do, but it doesn't change the
fact that most users, especially large IT environments, require system
standardization.  I hope to address the needs of this portion of the
linux community even if you might wish they functioned differently.

> In this instance you seem to be redefining CAP_SYS_MODULE and
> CAP_SYS_REBOOT so you can play that game.

Clearly I am refining the meaning of both in some way.  Personally I
think the current differentiation is wrong.

> > Maybe I didn't make it clear how this is going to be used.  I plan to
> > drop CAP_SYS_MODULE to stop root from loading their own modules and
> > running their own code in the kernel.  I can control reboot() since I
> > control the platform and the bootloader.  I cannot control kexec().  I'm
> > also required to use a generic distro kernel (bet you can't guess which
> > one)
> 
> If you are truly locked down I recommend dropping CAP_SYS_REBOOT and
> setting up a watchdog that keeps the system from rebooting (standard
> practice in embedded kinds of setups like you describe).  That should
> meet everyone requirements without needing to game the system.

This does not meet the set of requirements.  I recognize that you don't
have the full architecture in mind (and apologize that I can't describe
it much better than I am already), but root should still be allowed to
reboot the machine.  This is not an embedded platform.  Nor one in which
a watchdog task makes any sense at all.

> > The only solution I see to solve the problem is to gate kexec on
> > CAP_SYS_MODULE.  Which makes sense since kexec() is in many respects
> > close to module_init() than it is to reboot().
> 
> kexec_load is nothing like module_init().  All it does it puts data in
> memory for use by a subsequent reboot.  /sbin/kexec is a bootloader that
> runs inside of linux.  All you are noticing is that if you don't control
> /sbin/kexec you aren't controlling the bootloader.

Does that mean you would instead prefer that we check CAP_SYS_MODULE in
sys_reboot() when LINUX_REBOOT_CMD_KEXEC is set (or really
kernel_kexec())?  It seems to me you indicate that is the more analogous
location since it is the actual place where we load new kernel code on
the running system (aka what sys_module was intended to protect)?

-Eric

Re: [Patch] kexec_load: check CAP_SYS_MODULE

[Eric Paris]

On Fri, 2011-01-07 at 13:02 -0800, Eric W. Biederman wrote:
> Eric Paris <eparis@redhat.com> writes:

> Yes I am aware of the crazy game that is called approved kernels.  Where
> there are too many regressions for people to trust new kernel releases
> but people want to change the kernel and the setup from what was tested
> and still have the stamp of approval anyway.  Financially it seems to
> make people money, but as best I can tell that game is ultimately what
> killed unix.

I don't believe this is a particularly relevant line of conversion and
should probably drop it, but I can't completely leave it alone.  We
obviously have a very different understanding of what concerning the
unix wars brought about its death.  I'd think it obvious that the very
fact that this conversation is taking place shows that the exact
opposite of the unix wars problems are being seen here.  You clearly
have personal opinions about the benefits of custom built kernels, but
they are not the opinions of the vast majority of linux users.  I rarely
run disto kernels and I'm sure few on lkml do, but it doesn't change the
fact that most users, especially large IT environments, require system
standardization.  I hope to address the needs of this portion of the
linux community even if you might wish they functioned differently.

> In this instance you seem to be redefining CAP_SYS_MODULE and
> CAP_SYS_REBOOT so you can play that game.

Clearly I am refining the meaning of both in some way.  Personally I
think the current differentiation is wrong.

> > Maybe I didn't make it clear how this is going to be used.  I plan to
> > drop CAP_SYS_MODULE to stop root from loading their own modules and
> > running their own code in the kernel.  I can control reboot() since I
> > control the platform and the bootloader.  I cannot control kexec().  I'm
> > also required to use a generic distro kernel (bet you can't guess which
> > one)
> 
> If you are truly locked down I recommend dropping CAP_SYS_REBOOT and
> setting up a watchdog that keeps the system from rebooting (standard
> practice in embedded kinds of setups like you describe).  That should
> meet everyone requirements without needing to game the system.

This does not meet the set of requirements.  I recognize that you don't
have the full architecture in mind (and apologize that I can't describe
it much better than I am already), but root should still be allowed to
reboot the machine.  This is not an embedded platform.  Nor one in which
a watchdog task makes any sense at all.

> > The only solution I see to solve the problem is to gate kexec on
> > CAP_SYS_MODULE.  Which makes sense since kexec() is in many respects
> > close to module_init() than it is to reboot().
> 
> kexec_load is nothing like module_init().  All it does it puts data in
> memory for use by a subsequent reboot.  /sbin/kexec is a bootloader that
> runs inside of linux.  All you are noticing is that if you don't control
> /sbin/kexec you aren't controlling the bootloader.

Does that mean you would instead prefer that we check CAP_SYS_MODULE in
sys_reboot() when LINUX_REBOOT_CMD_KEXEC is set (or really
kernel_kexec())?  It seems to me you indicate that is the more analogous
location since it is the actual place where we load new kernel code on
the running system (aka what sys_module was intended to protect)?

-Eric


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [Patch] kexec_load: check CAP_SYS_MODULE

[Eric W. Biederman]

Eric Paris <eparis@redhat.com> writes:

> On Fri, 2011-01-07 at 13:02 -0800, Eric W. Biederman wrote:
>> Eric Paris <eparis@redhat.com> writes:
>
>> Yes I am aware of the crazy game that is called approved kernels.  Where
>> there are too many regressions for people to trust new kernel releases
>> but people want to change the kernel and the setup from what was tested
>> and still have the stamp of approval anyway.  Financially it seems to
>> make people money, but as best I can tell that game is ultimately what
>> killed unix.
>
> I don't believe this is a particularly relevant line of conversion and
> should probably drop it, but I can't completely leave it alone.  We
> obviously have a very different understanding of what concerning the
> unix wars brought about its death.  I'd think it obvious that the very
> fact that this conversation is taking place shows that the exact
> opposite of the unix wars problems are being seen here.  You clearly
> have personal opinions about the benefits of custom built kernels, but
> they are not the opinions of the vast majority of linux users.  I rarely
> run disto kernels and I'm sure few on lkml do, but it doesn't change the
> fact that most users, especially large IT environments, require system
> standardization.  I hope to address the needs of this portion of the
> linux community even if you might wish they functioned differently.

Sure and if you have a good clear architecture not an adhoc set of goals
getting it into the standard kernel makes sense.

Trying to shoe horn everyone crazy ideas into the standard kernel before
they are well thought out is a bad idea.

What I am most sensitive to about distro kernels is the massive
stagnation that happens (it gets extremely silly to run a kernel that is
several years old on bleeding edge hardware) as well as the crazy hacks
that I see people asking for because they must use a distro kernel for
random reasons.

>> In this instance you seem to be redefining CAP_SYS_MODULE and
>> CAP_SYS_REBOOT so you can play that game.
>
> Clearly I am refining the meaning of both in some way.  Personally I
> think the current differentiation is wrong.

To some extent I agree.  The old check for being uid == 0 is the only
real check that makes much sense.

>> > Maybe I didn't make it clear how this is going to be used.  I plan to
>> > drop CAP_SYS_MODULE to stop root from loading their own modules and
>> > running their own code in the kernel.  I can control reboot() since I
>> > control the platform and the bootloader.  I cannot control kexec().  I'm
>> > also required to use a generic distro kernel (bet you can't guess which
>> > one)
>> 
>> If you are truly locked down I recommend dropping CAP_SYS_REBOOT and
>> setting up a watchdog that keeps the system from rebooting (standard
>> practice in embedded kinds of setups like you describe).  That should
>> meet everyone requirements without needing to game the system.
>
> This does not meet the set of requirements.  I recognize that you don't
> have the full architecture in mind (and apologize that I can't describe
> it much better than I am already), but root should still be allowed to
> reboot the machine.  This is not an embedded platform.  Nor one in which
> a watchdog task makes any sense at all.

What you are asking for if I understand this correctly is a way to
disable sys_kexec_load?

What strange things are you trying to accomplish on top of a
distribution kernel?

>> > The only solution I see to solve the problem is to gate kexec on
>> > CAP_SYS_MODULE.  Which makes sense since kexec() is in many respects
>> > close to module_init() than it is to reboot().
>> 
>> kexec_load is nothing like module_init().  All it does it puts data in
>> memory for use by a subsequent reboot.  /sbin/kexec is a bootloader that
>> runs inside of linux.  All you are noticing is that if you don't control
>> /sbin/kexec you aren't controlling the bootloader.
>
> Does that mean you would instead prefer that we check CAP_SYS_MODULE in
> sys_reboot() when LINUX_REBOOT_CMD_KEXEC is set (or really
> kernel_kexec())?  It seems to me you indicate that is the more analogous
> location since it is the actual place where we load new kernel code on
> the running system (aka what sys_module was intended to protect)?

We aren't dealing with modules I think CAP_SYS_MODULE is totally
irrelevant in the context of kexec.

I think to accomplish what you want we either need a way to disable
sys_kexec_load or possibly a new very targeted capability bit.

You are making it so that giving someone CAP_SYS_MODULE is giving more
than the ability to load kernel modules.  Which seems non-intuitive from
a system management point of view.

Eric

Re: [Patch] kexec_load: check CAP_SYS_MODULE

[Eric W. Biederman]

Eric Paris <eparis@redhat.com> writes:

> On Fri, 2011-01-07 at 13:02 -0800, Eric W. Biederman wrote:
>> Eric Paris <eparis@redhat.com> writes:
>
>> Yes I am aware of the crazy game that is called approved kernels.  Where
>> there are too many regressions for people to trust new kernel releases
>> but people want to change the kernel and the setup from what was tested
>> and still have the stamp of approval anyway.  Financially it seems to
>> make people money, but as best I can tell that game is ultimately what
>> killed unix.
>
> I don't believe this is a particularly relevant line of conversion and
> should probably drop it, but I can't completely leave it alone.  We
> obviously have a very different understanding of what concerning the
> unix wars brought about its death.  I'd think it obvious that the very
> fact that this conversation is taking place shows that the exact
> opposite of the unix wars problems are being seen here.  You clearly
> have personal opinions about the benefits of custom built kernels, but
> they are not the opinions of the vast majority of linux users.  I rarely
> run disto kernels and I'm sure few on lkml do, but it doesn't change the
> fact that most users, especially large IT environments, require system
> standardization.  I hope to address the needs of this portion of the
> linux community even if you might wish they functioned differently.

Sure and if you have a good clear architecture not an adhoc set of goals
getting it into the standard kernel makes sense.

Trying to shoe horn everyone crazy ideas into the standard kernel before
they are well thought out is a bad idea.

What I am most sensitive to about distro kernels is the massive
stagnation that happens (it gets extremely silly to run a kernel that is
several years old on bleeding edge hardware) as well as the crazy hacks
that I see people asking for because they must use a distro kernel for
random reasons.

>> In this instance you seem to be redefining CAP_SYS_MODULE and
>> CAP_SYS_REBOOT so you can play that game.
>
> Clearly I am refining the meaning of both in some way.  Personally I
> think the current differentiation is wrong.

To some extent I agree.  The old check for being uid == 0 is the only
real check that makes much sense.

>> > Maybe I didn't make it clear how this is going to be used.  I plan to
>> > drop CAP_SYS_MODULE to stop root from loading their own modules and
>> > running their own code in the kernel.  I can control reboot() since I
>> > control the platform and the bootloader.  I cannot control kexec().  I'm
>> > also required to use a generic distro kernel (bet you can't guess which
>> > one)
>> 
>> If you are truly locked down I recommend dropping CAP_SYS_REBOOT and
>> setting up a watchdog that keeps the system from rebooting (standard
>> practice in embedded kinds of setups like you describe).  That should
>> meet everyone requirements without needing to game the system.
>
> This does not meet the set of requirements.  I recognize that you don't
> have the full architecture in mind (and apologize that I can't describe
> it much better than I am already), but root should still be allowed to
> reboot the machine.  This is not an embedded platform.  Nor one in which
> a watchdog task makes any sense at all.

What you are asking for if I understand this correctly is a way to
disable sys_kexec_load?

What strange things are you trying to accomplish on top of a
distribution kernel?

>> > The only solution I see to solve the problem is to gate kexec on
>> > CAP_SYS_MODULE.  Which makes sense since kexec() is in many respects
>> > close to module_init() than it is to reboot().
>> 
>> kexec_load is nothing like module_init().  All it does it puts data in
>> memory for use by a subsequent reboot.  /sbin/kexec is a bootloader that
>> runs inside of linux.  All you are noticing is that if you don't control
>> /sbin/kexec you aren't controlling the bootloader.
>
> Does that mean you would instead prefer that we check CAP_SYS_MODULE in
> sys_reboot() when LINUX_REBOOT_CMD_KEXEC is set (or really
> kernel_kexec())?  It seems to me you indicate that is the more analogous
> location since it is the actual place where we load new kernel code on
> the running system (aka what sys_module was intended to protect)?

We aren't dealing with modules I think CAP_SYS_MODULE is totally
irrelevant in the context of kexec.

I think to accomplish what you want we either need a way to disable
sys_kexec_load or possibly a new very targeted capability bit.

You are making it so that giving someone CAP_SYS_MODULE is giving more
than the ability to load kernel modules.  Which seems non-intuitive from
a system management point of view.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [Patch] kexec_load: check CAP_SYS_MODULE

[Cong Wang]

于 2011年01月09日 10:09, Eric W. Biederman 写道:
>
> We aren't dealing with modules I think CAP_SYS_MODULE is totally
> irrelevant in the context of kexec.


Yeah, although I don't really understand CAP_SYS_MODULE, but it
really confused me to add it to kexec_load() from its name.

>
> I think to accomplish what you want we either need a way to disable
> sys_kexec_load or possibly a new very targeted capability bit.
>
> You are making it so that giving someone CAP_SYS_MODULE is giving more
> than the ability to load kernel modules.  Which seems non-intuitive from
> a system management point of view.
>

How about CAP_SYS_KEXEC?

Thanks.

Re: [Patch] kexec_load: check CAP_SYS_MODULE

[Cong Wang]

于 2011年01月09日 10:09, Eric W. Biederman 写道:
>
> We aren't dealing with modules I think CAP_SYS_MODULE is totally
> irrelevant in the context of kexec.


Yeah, although I don't really understand CAP_SYS_MODULE, but it
really confused me to add it to kexec_load() from its name.

>
> I think to accomplish what you want we either need a way to disable
> sys_kexec_load or possibly a new very targeted capability bit.
>
> You are making it so that giving someone CAP_SYS_MODULE is giving more
> than the ability to load kernel modules.  Which seems non-intuitive from
> a system management point of view.
>

How about CAP_SYS_KEXEC?

Thanks.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [Patch] kexec_load: check CAP_SYS_MODULE

[Eric Paris]

On Sat, 2011-01-08 at 18:09 -0800, Eric W. Biederman wrote:
> Eric Paris <eparis@redhat.com> writes:

> What you are asking for if I understand this correctly is a way to
> disable sys_kexec_load?
> 
> What strange things are you trying to accomplish on top of a
> distribution kernel?

I've already described the situation.  We'd like to launch machines in
which root in unable to easily run their own kernel code.  This is
largely easy to do if you control the platform which holds the
bootloader and you drop CAP_SYS_MODULE and CAP_SYS_RAWIO before you
allow 'root' access to the machine.  Except kexec.  kexec seems to
believe that running any code you want in kernel space is the same as
rebooting a machine.  It's not.

> >> > The only solution I see to solve the problem is to gate kexec on
> >> > CAP_SYS_MODULE.  Which makes sense since kexec() is in many respects
> >> > close to module_init() than it is to reboot().
> >> 
> >> kexec_load is nothing like module_init().  All it does it puts data in
> >> memory for use by a subsequent reboot.  /sbin/kexec is a bootloader that
> >> runs inside of linux.  All you are noticing is that if you don't control
> >> /sbin/kexec you aren't controlling the bootloader.
> >
> > Does that mean you would instead prefer that we check CAP_SYS_MODULE in
> > sys_reboot() when LINUX_REBOOT_CMD_KEXEC is set (or really
> > kernel_kexec())?  It seems to me you indicate that is the more analogous
> > location since it is the actual place where we load new kernel code on
> > the running system (aka what sys_module was intended to protect)?
> 
> We aren't dealing with modules I think CAP_SYS_MODULE is totally
> irrelevant in the context of kexec.
> 
> I think to accomplish what you want we either need a way to disable
> sys_kexec_load or possibly a new very targeted capability bit.
> 
> You are making it so that giving someone CAP_SYS_MODULE is giving more
> than the ability to load kernel modules.  Which seems non-intuitive from
> a system management point of view.

I'm looking at what CAP_SYS_MODULE means in terms of operation of the
system and applying it where it fits.  A task with CAP_SYS_MODULE can
run any code they want in ring0 without any method for the hardware or
platform to determine or inspect what code is running or to realize that
the code it thought was running wasn't.  This is exactly what kexec()
allows.  Do you not see where these two operations are very similar?

I'm not giving anyone anything new.  I'm further restricting access.
Having CAP_SYS_MODULE alone won't let you use kexec.  And it's not like
anyone would have to grant any new permissions or make any userspace
changes for this to be backwards compatible (unless someone has an suid
kexec app which drops permissions explictly, which seems braindead, if
you don't trust that whole app your fscked anyway).  Maybe you don't
realize how caps work.  On nearly every system out there uid==0 means
you have all capabilities.  If you drop them, just exec something and
you get them back.

I'm willing to accept a way to disable kexec or even a new cap (since I
think CAP_SYS_REBOOT is really wrong) but I still think that the
operation CAP_SYS_MODULE was intended to mediate is the operation that's
happening here.

-Eric

Re: [Patch] kexec_load: check CAP_SYS_MODULE

[Eric Paris]

On Sat, 2011-01-08 at 18:09 -0800, Eric W. Biederman wrote:
> Eric Paris <eparis@redhat.com> writes:

> What you are asking for if I understand this correctly is a way to
> disable sys_kexec_load?
> 
> What strange things are you trying to accomplish on top of a
> distribution kernel?

I've already described the situation.  We'd like to launch machines in
which root in unable to easily run their own kernel code.  This is
largely easy to do if you control the platform which holds the
bootloader and you drop CAP_SYS_MODULE and CAP_SYS_RAWIO before you
allow 'root' access to the machine.  Except kexec.  kexec seems to
believe that running any code you want in kernel space is the same as
rebooting a machine.  It's not.

> >> > The only solution I see to solve the problem is to gate kexec on
> >> > CAP_SYS_MODULE.  Which makes sense since kexec() is in many respects
> >> > close to module_init() than it is to reboot().
> >> 
> >> kexec_load is nothing like module_init().  All it does it puts data in
> >> memory for use by a subsequent reboot.  /sbin/kexec is a bootloader that
> >> runs inside of linux.  All you are noticing is that if you don't control
> >> /sbin/kexec you aren't controlling the bootloader.
> >
> > Does that mean you would instead prefer that we check CAP_SYS_MODULE in
> > sys_reboot() when LINUX_REBOOT_CMD_KEXEC is set (or really
> > kernel_kexec())?  It seems to me you indicate that is the more analogous
> > location since it is the actual place where we load new kernel code on
> > the running system (aka what sys_module was intended to protect)?
> 
> We aren't dealing with modules I think CAP_SYS_MODULE is totally
> irrelevant in the context of kexec.
> 
> I think to accomplish what you want we either need a way to disable
> sys_kexec_load or possibly a new very targeted capability bit.
> 
> You are making it so that giving someone CAP_SYS_MODULE is giving more
> than the ability to load kernel modules.  Which seems non-intuitive from
> a system management point of view.

I'm looking at what CAP_SYS_MODULE means in terms of operation of the
system and applying it where it fits.  A task with CAP_SYS_MODULE can
run any code they want in ring0 without any method for the hardware or
platform to determine or inspect what code is running or to realize that
the code it thought was running wasn't.  This is exactly what kexec()
allows.  Do you not see where these two operations are very similar?

I'm not giving anyone anything new.  I'm further restricting access.
Having CAP_SYS_MODULE alone won't let you use kexec.  And it's not like
anyone would have to grant any new permissions or make any userspace
changes for this to be backwards compatible (unless someone has an suid
kexec app which drops permissions explictly, which seems braindead, if
you don't trust that whole app your fscked anyway).  Maybe you don't
realize how caps work.  On nearly every system out there uid==0 means
you have all capabilities.  If you drop them, just exec something and
you get them back.

I'm willing to accept a way to disable kexec or even a new cap (since I
think CAP_SYS_REBOOT is really wrong) but I still think that the
operation CAP_SYS_MODULE was intended to mediate is the operation that's
happening here.

-Eric


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec