problem with /proc/sysrq-trigger

problem with /proc/sysrq-trigger

[Gao feng]

Hi all

when I using the container, I found the /proc/sysrq-trigger is not isolated with the host.
when exec echo c > /proc/sysrq-trigger in the container,
the host will crash too.

I don't know if it's correct.
And if it's incorrect,can I fix this by just like this?

diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 05728894..da4d812 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -865,6 +865,10 @@ EXPORT_SYMBOL(unregister_sysrq_key);
 static ssize_t write_sysrq_trigger(struct file *file, const char __user *buf,
                                   size_t count, loff_t *ppos)
 {
+       if (current->nsproxy != &init_nsproxy)
+               return -EFAULT;

        if (count) {
                char c;

Re: problem with /proc/sysrq-trigger

[Serge Hallyn]

Quoting Gao feng (gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org):
> Hi all
> 
> when I using the container, I found the /proc/sysrq-trigger is not isolated with the host.
> when exec echo c > /proc/sysrq-trigger in the container,
> the host will crash too.
> 
> I don't know if it's correct.
> And if it's incorrect,can I fix this by just like this?

Certainly the fix wouldn't be right - the nsproxy is not the right thing
to validate.  It might make more sense to tie it to the pid namespace or,
when it pops into existence, the device namespace.  Device ns makes sense
as you can see the host as a device, and pidns makes sense since if you're
in a child pidns, you can't safely make assumptions about killing all
tasks.

In Ubuntu 12.04+, the apparmor profile simply refuses this write from
containers.  I'll soon need to generalize the support for that in lxc
so you can do the same with selinux and smack.

> diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
> index 05728894..da4d812 100644
> --- a/drivers/tty/sysrq.c
> +++ b/drivers/tty/sysrq.c
> @@ -865,6 +865,10 @@ EXPORT_SYMBOL(unregister_sysrq_key);
>  static ssize_t write_sysrq_trigger(struct file *file, const char __user *buf,
>                                    size_t count, loff_t *ppos)
>  {
> +       if (current->nsproxy != &init_nsproxy)
> +               return -EFAULT;
> 
>         if (count) {
>                 char c;
> _______________________________________________
> Containers mailing list
> Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers

Re: problem with /proc/sysrq-trigger

[Gao feng]

于 2012年04月13日 21:27, Serge Hallyn 写道:
> Quoting Gao feng (gaofeng@cn.fujitsu.com):
>> Hi all
>>
>> when I using the container, I found the /proc/sysrq-trigger is not isolated with the host.
>> when exec echo c > /proc/sysrq-trigger in the container,
>> the host will crash too.
>>
>> I don't know if it's correct.
>> And if it's incorrect,can I fix this by just like this?
> 
> Certainly the fix wouldn't be right - the nsproxy is not the right thing
> to validate.  It might make more sense to tie it to the pid namespace or,
> when it pops into existence, the device namespace.  Device ns makes sense
> as you can see the host as a device, and pidns makes sense since if you're
> in a child pidns, you can't safely make assumptions about killing all
> tasks.
> 
> In Ubuntu 12.04+, the apparmor profile simply refuses this write from
> containers.  I'll soon need to generalize the support for that in lxc
> so you can do the same with selinux and smack.

Hi Serge

I get it,thank you very much!

> 
>> diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
>> index 05728894..da4d812 100644
>> --- a/drivers/tty/sysrq.c
>> +++ b/drivers/tty/sysrq.c
>> @@ -865,6 +865,10 @@ EXPORT_SYMBOL(unregister_sysrq_key);
>>  static ssize_t write_sysrq_trigger(struct file *file, const char __user *buf,
>>                                    size_t count, loff_t *ppos)
>>  {
>> +       if (current->nsproxy != &init_nsproxy)
>> +               return -EFAULT;
>>
>>         if (count) {
>>                 char c;
>> _______________________________________________
>> Containers mailing list
>> Containers@lists.linux-foundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/containers
> 

_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers