Difference between revisions of "Talk:Secure chroot Barrier"
From Linux-VServer
| (14 intermediate revisions by 10 users not shown) | |||
| Line 1: | Line 1: | ||
# setattr --barrier /vservers | # setattr --barrier /vservers | ||
# showattr /vservers | # showattr /vservers | ||
| + | *NOTE: when setting xattrs on reiserfs, please not that the filesystem has to be mounted explicitly with 'attrs' option, i.e.: mount /dev/reiserfsdev /vservers -oattrs to get the barrier survive after umount/reboot. | ||
Seems insufficient. You need to set --barrier for every existing and NEW directory except those below /vservers/. as the suggested command protects only against chdir .. | Seems insufficient. You need to set --barrier for every existing and NEW directory except those below /vservers/. as the suggested command protects only against chdir .. | ||
| Line 7: | Line 8: | ||
Am I right? | Am I right? | ||
| + | |||
| + | once you gain root inside the scure chroot: | ||
| + | |||
| + | may you gain access to the device node? | ||
| + | |||
| + | i/o ports not restricted? | ||
| + | |||
| + | |||
| + | # Accoring to http://oldwiki.linux-vserver.org/Step-by-Step+Guide+2.6: "On Linux 2.6 this isn't really necessary, since another mechanism is used to lock in the guests anyway" - maybe someone could elaborate on this and put it in the article, please | ||
Latest revision as of 06:02, 5 June 2013
- setattr --barrier /vservers
- showattr /vservers
- NOTE: when setting xattrs on reiserfs, please not that the filesystem has to be mounted explicitly with 'attrs' option, i.e.: mount /dev/reiserfsdev /vservers -oattrs to get the barrier survive after umount/reboot.
Seems insufficient. You need to set --barrier for every existing and NEW directory except those below /vservers/. as the suggested command protects only against chdir ..
Why? The fchdir.
Am I right?
once you gain root inside the scure chroot:
may you gain access to the device node?
i/o ports not restricted?
- Accoring to http://oldwiki.linux-vserver.org/Step-by-Step+Guide+2.6: "On Linux 2.6 this isn't really necessary, since another mechanism is used to lock in the guests anyway" - maybe someone could elaborate on this and put it in the article, please
