Skip to contentSkip to conversation

problem with /proc/sysrq-trigger

PATCH Gao feng 2 participants 3 messages Apr 13, 2012 – Apr 17, 2012 1 message not in the archive TTY layer and serial drivers

lore
Share & tools
lore

Gao feng

author
#0 lore raw

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?

drivers/tty/sysrq.c +2 -0
index 05728894..da4d812 100644
@@ -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;

A message that is not in the archive (sent off-list or not yet received): [email protected]

#2 lore raw
Quoted 8 lines · 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?

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.

Quoted 17 lines
drivers/tty/sysrq.c +2 -0
index 05728894..da4d812 100644
@@ -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

author
#3 lore raw
Quoted 17 lines · Serge Hallyn
Quoted 8 lines · 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?

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.

Quoted 3 lines

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!

Quoted 12 lines
Quoted 12 lines
drivers/tty/sysrq.c +2 -0
index 05728894..da4d812 100644
@@ -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;
Quoted 7 lines
Quoted 6 lines
drivers/tty/sysrq.c +0 -0
        if (count) {
                char c;

_______________________________________________
Containers mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/containers

_______________________________________________
Containers mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/containers