headers
Josip Rodin | 1 Sep 2009 23:56

Re: New kernel vuln...

On Tue, Aug 18, 2009 at 04:31:12PM +0400, Konstantin Khorenko wrote:
> Hi all,
> 
> just wanted to share the info:
> i checked this issue and found that 2.6.18-128.2.1.el5.028stab064.4 kernel (latest OVZ) is immune to
the exploits on the issue described at http://blog.cr0.org/2009/08/linux-null-pointer-dereference-due-to.html
> Exploits do not work both inside a Container and on a Hardware Node.
> 
> On 08/17/2009 10:26 PM, Michael Stauber wrote:
> ...
> > The exploit allows an unprivileged user to gain root access. However: The
> > exploit (as is) *only* works on the master node. NOT inside a VE. Somehow the
> > virtualization already takes care of it and prevents it when someone runs it
> > inside a VE.
> 
> Michael, could you please confirm that you were able to gain root on a kernel before 64.4?
> 
> The kernel is immune due to the fact that 64.4 kernel has the bypassing "mmap_min_addr" issue fixed:
> http://blog.cr0.org/2009/06/bypassing-linux-null-pointer.html - description of the problem
> 
> Exploits for the current issue, in their turn, need this hole to gain root access.

AFAICT the linux-2.6.27-openvz has this obvious issue with mmap_min_addr due
to security/Kconfig containing:

config SECURITY
        bool "Enable different security models"
        depends on SYSFS && !VE

config SECURITY_DEFAULT_MMAP_MIN_ADDR
(Continue reading)

Permalink | Reply | 4 comments |
headers
Dietmar Maurer | 2 Sep 2009 15:59

RE: ERROR: unable to detect lvm volume group, using 'suspend' mode

The problem is the '-' in the volume group name. I will fix that bug in the next vzdump release (soon).

> -----Original Message-----
> From: users-bounces@...
[mailto:users-bounces@...] On
> Behalf Of Nicolas Gorguès
> Sent: Dienstag, 18. August 2009 11:32
> To: users@...
> Subject: RE: [Users] ERROR: unable to detect lvm volume group, using
> 'suspend' mode
> 
> Hello,
> 
> I have the same problem here, under Debian Lenny:
> 
> # uname -a
> Linux breizh.siloh.net 2.6.24-7-pve #1 SMP PREEMPT Mon Aug 17 10:37:00
> CEST 2009 x86_64 GNU/Linux
> 
> # vzctl --help | grep version
> vzctl version 3.0.23-1pve3
> 
> #apt-cache show vzdump | grep Version
> Version: 1.1-2
> 
> # df -h
> Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur
> /dev/sda1             9,7G  740M  8,5G   8% /
> tmpfs                1000M     0 1000M   0% /lib/init/rw
> udev                   10M   48K   10M   1% /dev
(Continue reading)

Permalink | Reply | 503 comments |
headers
Michael Stauber | 2 Sep 2009 16:49
Picon
Favicon

Re: Re: New kernel vuln...

Hi Benny,

> > The exploit allows an unprivileged user to gain root access. However: The
> > exploit (as is) *only* works on the master node. NOT inside a VE.
>
> That is a very weak assurance. The failure of a specific implementation
> of an attack means very little.

True. And that's why I felt a little more secure after I patched my OpenVZ 
kernels myself.

> Indeed. We attempted to move from Fedora to CentOS for a few servers.
> Lack of security updates got that attempt cancelled.

Well, this time around the CentOS team did one of their best turn arounds. 
They released the patched CentOS5 Kernel on the same day as RedHat. But 
unfortunately it was RedHat which sat on it for two weeks.

--

-- 
With best regards

Michael Stauber
Permalink | Reply | 0 comments |
headers
Dietmar Maurer | 3 Sep 2009 07:45

RE: ERROR: unable to detect lvm volume group, using 'suspend' mode

Sorry, forget my last answer. I guess the problem is your locale setting. Try to run with LANG=C

- Dietmar

> -----Original Message-----
> From: users-bounces@...
[mailto:users-bounces@...] On
> Behalf Of Dietmar Maurer
> Sent: Mittwoch, 02. September 2009 15:59
> To: users@...
> Subject: RE: [Users] ERROR: unable to detect lvm volume group, using
> 'suspend' mode
> 
> The problem is the '-' in the volume group name. I will fix that bug in
> the next vzdump release (soon).
> 
> > -----Original Message-----
> > From: users-bounces@...
[mailto:users-bounces@...] On
> > Behalf Of Nicolas Gorguès
> > Sent: Dienstag, 18. August 2009 11:32
> > To: users@...
> > Subject: RE: [Users] ERROR: unable to detect lvm volume group, using
> > 'suspend' mode
> >
> > Hello,
> >
> > I have the same problem here, under Debian Lenny:
> >
> > # uname -a
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kir Kolyshkin | 3 Sep 2009 14:45
Favicon

Re: ... Strange User-Bean-Counter: othersockbuf

Robert Heinzmann wrote:
> Hello List, 
>
> I have a strange beancouter value for a machine: 
>
> /proc/user_beancounter
> ...
> resource          held   maxheld   barrier   limit       failcnt
> othersockbuf      16184  4364184   6000000   12000000       11
> ...
>
> Altought the barrier was never reached, a failcnt is recorded. How can
> this happen ? Is this a bug ? 
>   
Strange that no one has answered this before, it's pretty trivial. Sorry 
for the late reply, I was on vacation.

If an app tries to allocate more than (barrier - held) bytes at once, 
this allocation will fail, failcnt will increase, maxheld won't change.

Say, in your scenario, if 4364184 bytes is currently allocated and a 
program tries to allocate another 2000000 bytes, such allocation will 
fail with no change in held/maxheld and an increment to failcnt.

Hope that helps.

Kir.
Permalink | Reply | 1 comment |
headers
Kir Kolyshkin | 3 Sep 2009 15:07
Favicon

Re: Re: Cant get information from a kernel connector in a container

It will probably help if you'll show us your code.

Surbhi Chitre wrote:
> Hi again,
>
> I forgot to mention that I am using the following linux version:
> 2.6.27.21 downloaded from the OpenVZ website with the last
> commit : acfd6c89981b9de80b96741380780ffe6c87a15d
> as per the git log.
>
> When I run the user space version of the kernel connector
> from outside the container, then the information of the processes
> running in the container cannot be seen (but the other processes
> related information can be seen !) When I run the same program
> inside a container I cannot send the message to the kernel
> connector because of "Connection refused" error (As mentioned earlier) !!
>
> Do let me know if I am missing any patch ? Any tip or
> help will be very helpful to me and shall be hugely appreciated :)
> Thanks a lot !
>
>
> Warm Regards,
> Surbhi.
>
>
>
>
>
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Surbhi Chitre | 3 Sep 2009 15:17
Picon

Re: Re: Cant get information from a kernel connector in a container

Hello Kir,

I have tried the code in this link for checking:
http://www.suse.de/~krahmer/exec-notify.c

I know why you cannot see the information related
to the processes running in the container when you run this
program outside the container(or on the host machine). But I have
not yet figured out why you cannot get the process related
events when you run the program(mentioned in the link)
inside the container.

Thanks a lot !!

Warm Regards,
Surbhi.



On Thu, Sep 3, 2009 at 3:07 PM, Kir Kolyshkin <kir <at> openvz.org> wrote:
It will probably help if you'll show us your code.

Surbhi Chitre wrote:
Hi again,

I forgot to mention that I am using the following linux version:
2.6.27.21 downloaded from the OpenVZ website with the last
commit : acfd6c89981b9de80b96741380780ffe6c87a15d
as per the git log.

When I run the user space version of the kernel connector
from outside the container, then the information of the processes
running in the container cannot be seen (but the other processes
related information can be seen !) When I run the same program
inside a container I cannot send the message to the kernel
connector because of "Connection refused" error (As mentioned earlier) !!

Do let me know if I am missing any patch ? Any tip or
help will be very helpful to me and shall be hugely appreciated :)
Thanks a lot !


Warm Regards,
Surbhi.






On Tue, Aug 25, 2009 at 7:50 PM, Surbhi Chitre <csurbhi-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org <mailto:csurbhi-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:

   Hie,

   I want to find out all the processes belonging to a particular
   process group. To find this out I am using the kernel connector
   provided by the Linux kernel. I have written a socket based user
   space program that leverages the information provided by the
   kernel connector.

   This program works successfully when it executes outside any
   container. However when I run it inside a container,
   send() fails because of the following error:
   "Connection refused".

   Running this connector code outside
   the container will not fetch the information of the processes
   executing inside a container.

   Has anyone else tried using the process related events given
   by the kernel connector from a container ? Does this work ?
   Is their any other way of finding out the processes of a group ?
   (or all the children/grandchildren.. of a process running in a
   container ?)

   Thanks a lot!

   Warm Regards,
   Surbhi.


------------------------------------------------------------------------

_______________________________________________
Users mailing list
Users-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org
https://openvz.org/mailman/listinfo/users
 

_______________________________________________
Users mailing list
Users-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org
https://openvz.org/mailman/listinfo/users

_______________________________________________
Users mailing list
Users@...
https://openvz.org/mailman/listinfo/users
Permalink | Reply | 0 comments |
headers
Robert Heinzmann | 3 Sep 2009 15:24
Picon
Favicon

AW: ... Strange User-Bean-Counter: othersockbuf

Hi, 

but isn't barrier a soft limit, which is granted as long as there are
enougth resources ? 

Is'nt limit the one that is never satisfied ? 

Regards,
Robert

> > /proc/user_beancounter
> > ...
> > resource          held   maxheld   barrier   limit       failcnt
> > othersockbuf      16184  4364184   6000000   12000000       11
> > ...
> >
> > Altought the barrier was never reached, a failcnt is 
> recorded. How can 
> > this happen ? Is this a bug ?
> >   
> Strange that no one has answered this before, it's pretty 
> trivial. Sorry for the late reply, I was on vacation.
> 
> If an app tries to allocate more than (barrier - held) bytes 
> at once, this allocation will fail, failcnt will increase, 
> maxheld won't change.
> 
> Say, in your scenario, if 4364184 bytes is currently 
> allocated and a program tries to allocate another 2000000 
> bytes, such allocation will fail with no change in 
> held/maxheld and an increment to failcnt.
>
Permalink | Reply | 0 comments |
headers
Dariush Pietrzak | 3 Sep 2009 20:08
Picon

compile error on ntfs with ovz-128.2.1.el5.028stab064.4-combined


fs/ntfs/aops.c: In function 'ntfs_readpage':
fs/ntfs/aops.c:418: error: implicit declaration of function 'zero_user_page'
make[3]: *** [fs/ntfs/aops.o] Error 1

--

-- 
Key fingerprint = 40D0 9FFB 9939 7320 8294  05E0 BCC7 02C4 75CC 50D9
 Total Existance Failure
Permalink | Reply | 0 comments |
headers
frank | 4 Sep 2009 08:47

global variable for quota files

Hi,
we have OpenVZ running on a cluster with a shared disk for VE data, so 
we are interested to put quota files on a shared disk.
We could do a symbolic link, but we would prefer to use a global 
variable for that because we think it is more clear and easy
to control.
Does such variable exist?
Regards.

Frank

--

-- 
Aquest missatge ha estat analitzat per MailScanner
a la cerca de virus i d'altres continguts perillosos,
i es considera que està net.
For all your IT requirements visit: http://www.transtec.co.uk
Permalink | Reply | 1 comment |

Gmane