Re: [Vserver] bcapabilities not working?
Hi,
Yes the files were both in the correct directory for the vserver.
They both contained '~ALL'
However:
cmp bcapabilities ccapabilities
cmp: EOF on bcapabilities
So there was a problem with the bcapabilties file. Copying the
ccapabilities to the bcapabilities.
cat /proc/self/vinfo
XID:16
BCaps:
CCaps:
CFlags: 00020210
CIPid: 0
Andy
Enrico Scholz wrote:
[EMAIL PROTECTED] (Andrew Mendelsohn) writes:
Here is the Debug output. There is no corresponding line for bcap, as
"++ OPTS_VATTRIBUTE=("[EMAIL PROTECTED]" --ccap "$cap")" for ccap.
...
++ local f=/etc/vservers/apache2server/bcapabilities
++ test -e /etc/vservers/apache2server/bcapabilities
~
...
Using 2.6.10 with patch-2.6.10-vs1.9.3.17.diff and compiling
util-vserver 0.30.196, it seems that I can't remove capabilities
via the /usr/local//etc/vservers/webserver/bcapabilities
~
configuration file using ~ALL.
Are you sure that the '~ALL' was configured in the correct
vserver?
Enrico
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] bcapabilities not working?
Hi,
Here is the Debug output. There is no corresponding line for bcap, as
"++ OPTS_VATTRIBUTE=("[EMAIL PROTECTED]" --ccap "$cap")" for ccap.
Hope this helps.
Andy
++ local cap_opts
++ local flag
++ test '(' '!' -e /etc/vservers/apache2server/hostname -o -e
/etc/vservers/apac
he2server/uts/nodename ')' -a '(' '!' -e
/etc/vservers/apache2server/domainname
-o -e /etc/vservers/apache2server/uts/domainname ')'
++ test -z ''
++ _generateCapabilityOptions /etc/vservers/apache2server
++ local vdir=/etc/vservers/apache2server
++ local cap
++ _generateBCapabilityOptions /etc/vservers/apache2server
++ local vdir=/etc/vservers/apache2server
++ local cap
++ local f=/etc/vservers/apache2server/bcapabilities
++ test -e /etc/vservers/apache2server/bcapabilities
++ read cap
++ _generateCCapabilityOptions /etc/vservers/apache2server
++ local vdir=/etc/vservers/apache2server
++ local cap
++ local f=/etc/vservers/apache2server/ccapabilities
++ test -e /etc/vservers/apache2server/ccapabilities
++ read cap
++ OPTS_VATTRIBUTE=("[EMAIL PROTECTED]" --ccap "$cap")
++ read cap
++ test -e /etc/vservers/apache2server/capabilities
++ return 0
++ _generateFlagOptions /etc/vservers/apache2server
++ local vdir=/etc/vservers/apache2server
++ CHCONTEXT_FLAG_OPTS=()
++ test '!' -e /etc/vservers/apache2server/flags
Herbert Poetzl wrote:
On Fri, Jan 14, 2005 at 06:34:02PM -0800, Andrew Mendelsohn wrote:
Hi,
Using 2.6.10 with patch-2.6.10-vs1.9.3.17.diff and compiling
util-vserver 0.30.196, it seems that I can't remove capabilities via the
/usr/local//etc/vservers/webserver/bcapabilities configuration file
using ~ALL. The /usr/local//etc/vservers/webserver/ccapabilities file
does what it is supposed to when set to ~ALL.
Output of cat /proc/self/vinfo before config files are set to ~ALL
XID:10
BCaps: d44c04ff
CCaps: 0101
CFlags: 00020210
CIPid: 0
Output of cat /proc/self/vinfo after both config files are set to ~ALL
XID:10
BCaps: d44c04ff
CCaps:
CFlags: 00020210
CIPid: 0
Is it a bug, or do I need an additional configuration step?
hmm, didn't test with the config setup, but a quick
check with vxc showed that it is working as expected
$ vxc --xid 100 -- grep Cap /proc/self/status
New security context is 100
CapInh:
CapPrm: feff
CapEff: feff
$ vxc --xid 100 --bcap ~ALL -- cat /proc/self/vinfo
New security context is 100
XID: 100
BCaps:
CCaps:
CFlags: 0002
CIPid: 0
$ vxc --xid 100 --bcap ~ALL -- grep Cap /proc/self/status
New security context is 100
CapInh:
CapPrm:
CapEff:
(kernel) 2.6.11-rc1-vs1.9.4-rc1
no relevant changes to 2.6.10-vs1.9.3.17
please check with --debug if the --bcap arg is
passed properly to vattribue ...
TIA,
Herbert
Thanks,
Andy
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] vserver patch-2.6.10-vs1.9.4-rc2 conflicts with fixes for CAN-2005-0001 and RLIMIT_MEMLOCK exploit]
Hi,
I used splitdiff to split the new patch-2.6.11-rc2-vs1.9.4-rc3.diff,
removed the mm/mmap.c patch and then used it to replace the mm/mmap.c
patch in patch-2.6.10-vs1.9.4-rc3.diff. I then recombined the 2.6.10
patches using cat. The resulting patch cleanly patches the 2.6.10
kernel with the two security fixes listed below with fuzz 2. If anyone
wants the resulting patch file I'll be happy to send it. I'm testing it
now.
Andy
Andrew Mendelsohn wrote:
Hi,
Here are links to the two security patches.
http://www.acm.cs.rpi.edu/~dilinger/patches/2.6.10/as2/linux-2.6.10-as2/033-rlimit_memlock_check.patch
http://www.acm.cs.rpi.edu/~dilinger/patches/2.6.10/as2/linux-2.6.10-as2/034-stack_resize_exploit.patch
Thanks for the suggestion. I'll check out the 2.6.11 patches to see if
they already deal with these exploits.
Thanks for your help!
Andy
Herbert Poetzl wrote:
On Sun, Jan 23, 2005 at 12:59:51AM -0800, Andrew Mendelsohn wrote:
After patching a 2.6.10 kernel with the patch-2.6.10-vs1.9.4-rc2
patch, I can't cleanly apply fixes for CAN-2005-0001 and
RLIMIT_MEMLOCK exploits because of critical changes to mmap.c I was
using fixes from the new as-patch series from Andres Salomon which
is supposed to be a minimum set of security fixes that will be used
by Debian as well as possibly other distros. (
http://www.acm.cs.rpi.edu/~dilinger/patches/2.6.10/as2/ ).
After studying the changes I came to the conclusion that it requires
someone who understands the linux memory subsystem better than I do
:) So, does anyone know how to reconcile these patches?
please be so kind an link me to the patches in question
(in unified diff format if possible) and I'll see what
I can do for you .. aside from that, 2.6.11-rc1 or rc2
should be an option too, no?
best,
Herbert
Here is the mm/mmap.c.rej which shows how significantly the security
patches change the code:
***
*** 1351,1378
*/
address += 4 + PAGE_SIZE - 1;
address &= PAGE_MASK;
- grow = (address - vma->vm_end) >> PAGE_SHIFT;
- /* Overcommit.. */
- if (security_vm_enough_memory(grow)) {
- anon_vma_unlock(vma);
- return -ENOMEM;
}
-
- if (address - vma->vm_start >
current->signal->rlim[RLIMIT_STACK].rlim_$
- ((vma->vm_mm->total_vm + grow) << PAGE_SHIFT) >
- current->signal->rlim[RLIMIT_AS].rlim_cur) {
- anon_vma_unlock(vma);
- vm_unacct_memory(grow);
- return -ENOMEM;
- }
- vma->vm_end = address;
- vma->vm_mm->total_vm += grow;
- if (vma->vm_flags & VM_LOCKED)
- vma->vm_mm->locked_vm += grow;
- __vm_stat_account(vma->vm_mm, vma->vm_flags, vma->vm_file,
grow);
anon_vma_unlock(vma);
- return 0;
}
struct vm_area_struct *
--- 1395,1415
*/
address += 4 + PAGE_SIZE - 1;
address &= PAGE_MASK;
+ error = 0;
+ /* Somebody else might have raced and expanded it already */
+ if (address > vma->vm_end) {
+ unsigned long size, grow;
+
+ size = address - vma->vm_start;
+ grow = (address - vma->vm_end) >> PAGE_SHIFT;
+
+ error = acct_stack_growth(vma, size, grow);
+ if (!error)
+ vma->vm_end = address;
}
anon_vma_unlock(vma);
+ return error;
}
struct vm_area_struct *
***
and
***
*** 1416,1444
* anon_vma lock to serialize against concurrent expand_stacks.
*/
address &= PAGE_MASK;
- grow = (vma->vm_start - address) >> PAGE_SHIFT;
- /* Overcommit.. */
- if (security_vm_enough_memory(grow)) {
- anon_vma_unlock(vma);
- return -ENOMEM;
- }
-
- if (vma->vm_end - address >
current->signal->rlim[RLIMIT_STACK].rlim_cu$
- ((vma->vm_mm->total_vm + grow) << PAGE_SHIFT) >
- current->signal->rlim[RLIMIT_AS].rlim_cur) {
- anon_vma_unlock(vma);
- vm_unacct_memory(grow);
- return -ENOMEM;
}
- vma->vm_start = address;
- vma->vm_pgoff -= grow;
- vma->vm_mm->total_vm += grow;
- if (vma->vm_flags & VM_LOCKED)
- vma->vm_mm->locked_vm += grow;
- __vm_stat_account(vma->vm_mm, vma->vm_flags, vma->vm_file,
grow);
anon_vma_unlock(vma);
- return 0;
}
struct vm_area_struct *
--- 1453,1475
* anon_vma lock to serialize against concurrent expand_stacks.
*/
address &= PAGE_MASK;
+ error = 0;
+ /* Somebody else might have raced and expanded it already */
+ if (address < vma->vm_start
Re: [Vserver] vserver patch-2.6.10-vs1.9.4-rc2 conflicts with fixes for CAN-2005-0001 and RLIMIT_MEMLOCK exploit]
Hi,
Here are links to the two security patches.
http://www.acm.cs.rpi.edu/~dilinger/patches/2.6.10/as2/linux-2.6.10-as2/033-rlimit_memlock_check.patch
http://www.acm.cs.rpi.edu/~dilinger/patches/2.6.10/as2/linux-2.6.10-as2/034-stack_resize_exploit.patch
Thanks for the suggestion. I'll check out the 2.6.11 patches to see if
they already deal with these exploits.
Thanks for your help!
Andy
Herbert Poetzl wrote:
On Sun, Jan 23, 2005 at 12:59:51AM -0800, Andrew Mendelsohn wrote:
After patching a 2.6.10 kernel with the patch-2.6.10-vs1.9.4-rc2 patch,
I can't cleanly apply fixes for CAN-2005-0001 and RLIMIT_MEMLOCK
exploits because of critical changes to mmap.c I was using fixes from
the new as-patch series from Andres Salomon which is supposed to be a
minimum set of security fixes that will be used by Debian as well as
possibly other distros. (
http://www.acm.cs.rpi.edu/~dilinger/patches/2.6.10/as2/ ).
After studying the changes I came to the conclusion that it requires
someone who understands the linux memory subsystem better than I do :)
So, does anyone know how to reconcile these patches?
please be so kind an link me to the patches in question
(in unified diff format if possible) and I'll see what
I can do for you .. aside from that, 2.6.11-rc1 or rc2
should be an option too, no?
best,
Herbert
Here is the mm/mmap.c.rej which shows how significantly the security
patches change the code:
***
*** 1351,1378
*/
address += 4 + PAGE_SIZE - 1;
address &= PAGE_MASK;
- grow = (address - vma->vm_end) >> PAGE_SHIFT;
- /* Overcommit.. */
- if (security_vm_enough_memory(grow)) {
- anon_vma_unlock(vma);
- return -ENOMEM;
}
-
- if (address - vma->vm_start >
current->signal->rlim[RLIMIT_STACK].rlim_$
- ((vma->vm_mm->total_vm + grow) << PAGE_SHIFT) >
- current->signal->rlim[RLIMIT_AS].rlim_cur) {
- anon_vma_unlock(vma);
- vm_unacct_memory(grow);
- return -ENOMEM;
- }
- vma->vm_end = address;
- vma->vm_mm->total_vm += grow;
- if (vma->vm_flags & VM_LOCKED)
- vma->vm_mm->locked_vm += grow;
- __vm_stat_account(vma->vm_mm, vma->vm_flags, vma->vm_file, grow);
anon_vma_unlock(vma);
- return 0;
}
struct vm_area_struct *
--- 1395,1415
*/
address += 4 + PAGE_SIZE - 1;
address &= PAGE_MASK;
+ error = 0;
+ /* Somebody else might have raced and expanded it already */
+ if (address > vma->vm_end) {
+ unsigned long size, grow;
+
+ size = address - vma->vm_start;
+ grow = (address - vma->vm_end) >> PAGE_SHIFT;
+
+ error = acct_stack_growth(vma, size, grow);
+ if (!error)
+ vma->vm_end = address;
}
anon_vma_unlock(vma);
+ return error;
}
struct vm_area_struct *
***
and
***
*** 1416,1444
* anon_vma lock to serialize against concurrent expand_stacks.
*/
address &= PAGE_MASK;
- grow = (vma->vm_start - address) >> PAGE_SHIFT;
- /* Overcommit.. */
- if (security_vm_enough_memory(grow)) {
- anon_vma_unlock(vma);
- return -ENOMEM;
- }
-
- if (vma->vm_end - address >
current->signal->rlim[RLIMIT_STACK].rlim_cu$
- ((vma->vm_mm->total_vm + grow) << PAGE_SHIFT) >
- current->signal->rlim[RLIMIT_AS].rlim_cur) {
- anon_vma_unlock(vma);
- vm_unacct_memory(grow);
- return -ENOMEM;
}
- vma->vm_start = address;
- vma->vm_pgoff -= grow;
- vma->vm_mm->total_vm += grow;
- if (vma->vm_flags & VM_LOCKED)
- vma->vm_mm->locked_vm += grow;
- __vm_stat_account(vma->vm_mm, vma->vm_flags, vma->vm_file, grow);
anon_vma_unlock(vma);
- return 0;
}
struct vm_area_struct *
--- 1453,1475
* anon_vma lock to serialize against concurrent expand_stacks.
*/
address &= PAGE_MASK;
+ error = 0;
+ /* Somebody else might have raced and expanded it already */
+ if (address < vma->vm_start) {
+ unsigned long size, grow;
+
+ size = vma->vm_end - address;
+ grow = (vma->vm_start - address) >> PAGE_SHIFT;
+
+ error = acct_stack_growth(vma, size, grow);
+ if (!error) {
+ vma->vm_start = address;
+ vma->vm_pgoff -= grow;
+ }
}
anon_vma_unlock(vma);
+ return error;
}
struct vm_area_struct *
__
[Vserver] vserver patch-2.6.10-vs1.9.4-rc2 conflicts with fixes for CAN-2005-0001 and RLIMIT_MEMLOCK exploit
After patching a 2.6.10 kernel with the patch-2.6.10-vs1.9.4-rc2 patch,
I can't cleanly apply fixes for CAN-2005-0001 and RLIMIT_MEMLOCK
exploits because of critical changes to mmap.c I was using fixes from
the new as-patch series from Andres Salomon which is supposed to be a
minimum set of security fixes that will be used by Debian as well as
possibly other distros. (
http://www.acm.cs.rpi.edu/~dilinger/patches/2.6.10/as2/ ).
After studying the changes I came to the conclusion that it requires
someone who understands the linux memory subsystem better than I do :)
So, does anyone know how to reconcile these patches?
Here is the mm/mmap.c.rej which shows how significantly the security
patches change the code:
***
*** 1351,1378
*/
address += 4 + PAGE_SIZE - 1;
address &= PAGE_MASK;
- grow = (address - vma->vm_end) >> PAGE_SHIFT;
- /* Overcommit.. */
- if (security_vm_enough_memory(grow)) {
- anon_vma_unlock(vma);
- return -ENOMEM;
}
-
- if (address - vma->vm_start >
current->signal->rlim[RLIMIT_STACK].rlim_$
- ((vma->vm_mm->total_vm + grow) << PAGE_SHIFT) >
- current->signal->rlim[RLIMIT_AS].rlim_cur) {
- anon_vma_unlock(vma);
- vm_unacct_memory(grow);
- return -ENOMEM;
- }
- vma->vm_end = address;
- vma->vm_mm->total_vm += grow;
- if (vma->vm_flags & VM_LOCKED)
- vma->vm_mm->locked_vm += grow;
- __vm_stat_account(vma->vm_mm, vma->vm_flags, vma->vm_file, grow);
anon_vma_unlock(vma);
- return 0;
}
struct vm_area_struct *
--- 1395,1415
*/
address += 4 + PAGE_SIZE - 1;
address &= PAGE_MASK;
+ error = 0;
+ /* Somebody else might have raced and expanded it already */
+ if (address > vma->vm_end) {
+ unsigned long size, grow;
+
+ size = address - vma->vm_start;
+ grow = (address - vma->vm_end) >> PAGE_SHIFT;
+
+ error = acct_stack_growth(vma, size, grow);
+ if (!error)
+ vma->vm_end = address;
}
anon_vma_unlock(vma);
+ return error;
}
struct vm_area_struct *
***
and
***
*** 1416,1444
* anon_vma lock to serialize against concurrent expand_stacks.
*/
address &= PAGE_MASK;
- grow = (vma->vm_start - address) >> PAGE_SHIFT;
- /* Overcommit.. */
- if (security_vm_enough_memory(grow)) {
- anon_vma_unlock(vma);
- return -ENOMEM;
- }
-
- if (vma->vm_end - address >
current->signal->rlim[RLIMIT_STACK].rlim_cu$
- ((vma->vm_mm->total_vm + grow) << PAGE_SHIFT) >
- current->signal->rlim[RLIMIT_AS].rlim_cur) {
- anon_vma_unlock(vma);
- vm_unacct_memory(grow);
- return -ENOMEM;
}
- vma->vm_start = address;
- vma->vm_pgoff -= grow;
- vma->vm_mm->total_vm += grow;
- if (vma->vm_flags & VM_LOCKED)
- vma->vm_mm->locked_vm += grow;
- __vm_stat_account(vma->vm_mm, vma->vm_flags, vma->vm_file, grow);
anon_vma_unlock(vma);
- return 0;
}
struct vm_area_struct *
--- 1453,1475
* anon_vma lock to serialize against concurrent expand_stacks.
*/
address &= PAGE_MASK;
+ error = 0;
+ /* Somebody else might have raced and expanded it already */
+ if (address < vma->vm_start) {
+ unsigned long size, grow;
+
+ size = vma->vm_end - address;
+ grow = (vma->vm_start - address) >> PAGE_SHIFT;
+
+ error = acct_stack_growth(vma, size, grow);
+ if (!error) {
+ vma->vm_start = address;
+ vma->vm_pgoff -= grow;
+ }
}
anon_vma_unlock(vma);
+ return error;
}
struct vm_area_struct *
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] bcapabilities not working?
Hi, Using 2.6.10 with patch-2.6.10-vs1.9.3.17.diff and compiling util-vserver 0.30.196, it seems that I can't remove capabilities via the /usr/local//etc/vservers/webserver/bcapabilities configuration file using ~ALL. The /usr/local//etc/vservers/webserver/ccapabilities file does what it is supposed to when set to ~ALL. Output of cat /proc/self/vinfo before config files are set to ~ALL XID:10 BCaps: d44c04ff CCaps: 0101 CFlags: 00020210 CIPid: 0 Output of cat /proc/self/vinfo after both config files are set to ~ALL XID:10 BCaps: d44c04ff CCaps: CFlags: 00020210 CIPid: 0 Is it a bug, or do I need an additional configuration step? Thanks, Andy ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
