m...@linux.it (Marco d'Itri) writes:
On Jan 30, Holger Levsen hol...@layer-acht.org wrote:
http://blog.bofh.it/debian/id_413
would you mind filing a bug about this?! Refering to your blog post is nice,
Yes, since the upstream maintainers do not consider this to be a bug.
--
ciao,
Yves-Alexis Perez cor...@debian.org writes:
On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
What is stopping you from creating another package, that
On 02/03/2012 01:55 AM, Vincent Bernat wrote:
With vservers and OpenVZ you can run each service in its own container
with a small memory footprint. With Xen/KVM, you will need to allocate
at least 128 MB for each container.
NO ! The limit isn't that great.
With Etch, 48 MB was enough.
On 02/03/2012 08:53 PM, Adam Borowski wrote:
ssh works.
It triples the memory footprint of an empty Debian container (init + syslogd +
cron[1]), and adds a new daemon that can be potentially subverted.
Of course, usually sshd is strongly preferred (so much better than needing
near-full
On Wed, 8 Feb 2012, Thomas Goirand z...@debian.org wrote:
With Etch, 48 MB was enough. With Lenny, 64 MB was enough.
With Squeeze, 96 MB is enough (the minimum is between 64 and
96 MB, I didn't care investigating). And with 96 MB, you can already
run a DNS server, OpenVPN, or a (very basic)
On Feb 07, Thomas Goirand z...@debian.org wrote:
Are you trying to make the point that, with containers,
you wouldn't need ssh, and you would with VMs? If so,
With *OpenVZ* I do not need sshd, ftpd and cron in the guest because
I can use the one in the host.
It's a custom environment, but I
OoO En ce début d'après-midi nuageux du mardi 07 février 2012, vers
14:00, Thomas Goirand z...@debian.org disait :
With vservers and OpenVZ you can run each service in its own container
with a small memory footprint. With Xen/KVM, you will need to allocate
at least 128 MB for each
On Tue, Feb 07, 2012 at 06:09:40PM +0100, Vincent Bernat wrote:
[...]
It applies. The major point is that with containers, RAM is shared
accross containers (the same kernel is used for all containers). If one
container needs for a few seconds 200 MB, it can just use them. No
On Tue, 07 Feb 2012, Marco d'Itri wrote:
On Feb 07, Thomas Goirand z...@debian.org wrote:
Are you trying to make the point that, with containers,
you wouldn't need ssh, and you would with VMs? If so,
With *OpenVZ* I do not need sshd, ftpd and cron in the guest because
I can use the one in
On Feb 03, Bastian Blank wa...@debian.org wrote:
http://blog.bofh.it/debian/id_413
This example shows nothing new. If you have CAP_SYS_MOUNT, you can also
just mount the root filesystem into your own tree.
Linux-VServer does not help against processes with too much
capabilities, not sure
On Sat, Feb 04, 2012 at 05:15:26PM +0100, Marco d'Itri wrote:
On Feb 03, Bastian Blank wa...@debian.org wrote:
http://blog.bofh.it/debian/id_413
This example shows nothing new. If you have CAP_SYS_MOUNT, you can also
just mount the root filesystem into your own tree.
Linux-VServer
On Mon, Jan 30, 2012 at 02:31:15AM +0100, Marco d'Itri wrote:
On Jan 30, Adam Borowski kilob...@angband.pl wrote:
It would be nice to have some documentation about how lxc is different from
them, and how to work around bugs and limitations. I for one spent ~10
Let's start with this: in its
On Wed, Feb 01, 2012 at 07:37:38PM +, Moritz Naumann wrote:
So there are obvious issues with LXC as a container solution for Linux, such
as
lacking actual containment (for the root user)
No, it is not obvious. If you give a process a certain permission, it
can use it. If you remove this
Am 03.02.2012 03:15, schrieb Russell Coker:
Some shared libraries have code which can't be run without an
executable
stack, it's a small number of libraries that are written in assembler
code.
We want to allow running them but don't want to give all programs
permission
to execute code on the
On Fri, Feb 03, 2012 at 12:31:03PM +0100, Bastian Blank wrote:
On Mon, Jan 30, 2012 at 02:31:15AM +0100, Marco d'Itri wrote:
On Jan 30, Adam Borowski kilob...@angband.pl wrote:
It would be nice to have some documentation about how lxc is different
from
them, and how to work around
On 02/01/2012 06:41 PM, Yves-Alexis Perez wrote:
[...]
Now indeed when doing the job for Squeeze kernel it's a bit less
straightforward because of the huge amount of driver backports, but from
my own experience, the conflicts are still mostly about changed context
lines.
Remember, just
On 02.02.2012 02:21 Russell Coker wrote:
Are there many users who need root containment but who won't have the
resources to run Xen or KVM when the support for Squeeze ends?
I am convinced there are several hosting providers and NGOs who use
linux-vservers for (amongst other) the purpose of
On Thu, 2012-02-02 at 09:29 +0200, Jonathan Carter (highvoltage) wrote:
[...]
We tried the 2.6.32 VZ kernel on squeeze / wheezy / lucid / precise -
and it works.
That's what I would expect, but it's good to know.
We have a PPA[1] for our experimental packages too. We
might run into bugs
OoO En cette nuit striée d'éclairs du jeudi 02 février 2012, vers 02:21,
Russell Coker russ...@coker.com.au disait :
However, a low profile container/virtualization solution is needed, and I
know there is quite some demand for it: both some larger scale
organisations and several
unsubscribe
On Sun, Jan 29, 2012 at 1:22 PM, Ben Hutchings b...@decadent.org.uk wrote:
Debian 7.0 'wheezy' will include Linux 3.2. This is currently in
unstable and will soon enter testing.
The kernel team is open to backporting some features from later kernel
versions, particularly
On Thu, 2012-02-02 at 12:18 +1100, Russell Coker wrote:
The current approach of having a kernel patch package seems to work well.
Phew... well there are many people running at stable... and for
them it does not... as the package seems more or less orphaned.
Also,.. configuring something
On Fri, Feb 03, 2012 at 12:55:59AM +0100, Christoph Anton Mitterer wrote:
On Thu, 2012-02-02 at 12:18 +1100, Russell Coker wrote:
The current approach of having a kernel patch package seems to work well.
Phew... well there are many people running at stable... and for
them it does not...
On Fri, 2012-02-03 at 00:34 +, Ben Hutchings wrote:
There is an easy way to benefit from it.
Well still the user wouldn't know how to configure it...
Actually I must admit that I haven't followed PaX/grsec now for some
time (mainly due to the deb package being always out of date in sid).
On Fri, 3 Feb 2012, Christoph Anton Mitterer cales...@scientia.net wrote:
Wasn't it once the case with PaX that packages have to be compiled
specially? Or some ELF headers added or so?
Some shared libraries have code which can't be run without an executable
stack, it's a small number of
On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
On Mon, 30 Jan 2012 22:26:50 +0100, Yves-Alexis Perez cor...@debian.org
wrote:
So I think it's perfectly clear that nor Debian nor Grsecurity are
really interested in Debian shipping a Grsecurity kernel.
Well, I don't think its
On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
What is stopping you from creating another package, that provides the
kernel with grsecurity patches applied? Don't bother the kernel team
with it, and just maintain
On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
What is stopping you from creating another package, that provides the
kernel with grsecurity patches
On Wed, 2012-02-01 at 10:51 +0100, Yves-Alexis Perez wrote:
On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
What is stopping you from creating another
On mer., 2012-02-01 at 14:32 +, Ben Hutchings wrote:
On Wed, 2012-02-01 at 10:51 +0100, Yves-Alexis Perez wrote:
On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
On mar., 2012-01-31 at 11:01 -0500, micah
On Wed, Feb 01, 2012 at 06:41:43PM +0100, Yves-Alexis Perez wrote:
On mer., 2012-02-01 at 14:32 +, Ben Hutchings wrote:
On Wed, 2012-02-01 at 10:51 +0100, Yves-Alexis Perez wrote:
On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
On Wed, Feb 01, 2012 at 10:24:40AM +0100,
On Wed, Feb 01, 2012 at 02:32:19PM +, Ben Hutchings wrote:
On Wed, 2012-02-01 at 10:51 +0100, Yves-Alexis Perez wrote:
On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
On mar., 2012-01-31 at 11:01 -0500,
So there are obvious issues with LXC as a container solution for Linux, such as
lacking actual containment (for the root user), which defeat sits purpose in
production environments as a linux-vserver or OpenVZ replacement.
However, a low profile container/virtualization solution is needed, and I
On 02/02/2012 03:37 AM, Moritz Naumann wrote:
So there are obvious issues with LXC as a container solution for Linux, such
as
lacking actual containment (for the root user), which defeat sits purpose in
production environments as a linux-vserver or OpenVZ replacement.
However, a low
On Thu, 2 Feb 2012, dann frazier da...@dannf.org wrote:
Whilte it may help the kernel team to not have to worry about problems
in the grsec flavor when preparing uploads, preventing delays for the
non-grsec images. But, that just pushes the coordination down a ways -
for stable updates we
On Thu, 2 Feb 2012, Moritz Naumann lists.debian@moritz-naumann.com
wrote:
So there are obvious issues with LXC as a container solution for Linux,
such as lacking actual containment (for the root user), which defeat sits
purpose in production environments as a linux-vserver or OpenVZ
On Feb 02, Russell Coker russ...@coker.com.au wrote:
Are there many users who need root containment but who won't have the
resources to run Xen or KVM when the support for Squeeze ends?
Are there many users who like to waste resources (mostly RAM, here) for
no good reason?
--
ciao,
Marco
Perhaps you should contact Julien Tinnes of http://kernelsec.cr0.org/
He has been too busy to work on the kernels lately but maybe he wants to
help.
On do, 2012-02-02 at 12:18 +1100, Russell Coker wrote:
On Thu, 2 Feb 2012, dann frazier da...@dannf.org wrote:
Whilte it may help the
On do, 2012-02-02 at 12:18 +1100, Russell Coker wrote:
On Thu, 2 Feb 2012, dann frazier da...@dannf.org wrote:
Whilte it may help the kernel team to not have to worry about problems
in the grsec flavor when preparing uploads, preventing delays for the
non-grsec images. But, that just
Hi Russell
On 02/02/2012 03:21, Russell Coker wrote:
However, a low profile container/virtualization solution is needed, and I
know there is quite some demand for it: both some larger scale
organisations and several smaller/non-profit organisations I am acquainted
with use either OpenVZ or
On Mon, 30 Jan 2012 22:26:50 +0100, Yves-Alexis Perez cor...@debian.org wrote:
On lun., 2012-01-30 at 14:08 +, Ben Hutchings wrote:
On Mon, 2012-01-30 at 11:05 +0100, Yves-Alexis Perez wrote:
(adding few CC:s to keep track on the bug)
On dim., 2012-01-29 at 21:26 +, Ben
Am Montag, 30. Januar 2012, 11:44:10 schrieb Marco d'Itri:
On Jan 30, Holger Levsen hol...@layer-acht.org wrote:
http://blog.bofh.it/debian/id_413
would you mind filing a bug about this?! Refering to your blog post is
nice,
Yes, since the upstream maintainers do not consider this to
On Mon, 2012-01-30 at 08:02 -0500, Brad Spengler wrote:
Frankly it makes more sense for me to offer .debs myself than to deal
with a bureaucracy and non-standard kernel in Debian. It contains
who-knows-what extra code, and I doubt anyone looked at any of it to see if
it allows for some way
On 02/01/2012 12:01 AM, micah anderson wrote:
What is stopping you from creating another package, that provides the
kernel with grsecurity patches applied? Don't bother the kernel team
with it, and just maintain it yourself in the archive? Its free software
afterall.
micah
Having such
Hi Marco,
thanks for these infos!
On Montag, 30. Januar 2012, Marco d'Itri wrote:
Let's start with this: in its current form, it is not designed to
protect the host system from an untrusted root user in a guest.
So far lxc is nice for testing, but not much more.
(adding few CC:s to keep track on the bug)
On dim., 2012-01-29 at 21:26 +, Ben Hutchings wrote:
On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote:
On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote:
Featuresets
---
The only featureset provided will be
On Jan 30, Holger Levsen hol...@layer-acht.org wrote:
http://blog.bofh.it/debian/id_413
would you mind filing a bug about this?! Refering to your blog post is nice,
Yes, since the upstream maintainers do not consider this to be a bug.
--
ciao,
Marco
signature.asc
Description: Digital
On 01/30/2012 01:44 AM, Adam Borowski wrote:
[...]
* how to ensure good isolation while still being able to do useful work?
The point of vserver is that even root inside a VM shouldn't be able to
affect the host, on lxc you keep hurting the host by accident. Messing
with capabilities
Indeed. Brad, I'm not sure if you received the initial mail, so if you
have any comment???
It looks like there were quite a few messages I wasn't involved in ;)
Regarding minimizing the patchset, we do that already where we see
opportunities to do so. We used to carry a large constifying
On Mon, 2012-01-30 at 11:05 +0100, Yves-Alexis Perez wrote:
(adding few CC:s to keep track on the bug)
On dim., 2012-01-29 at 21:26 +, Ben Hutchings wrote:
On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote:
On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote:
[Brad Spengler]
Frankly it makes more sense for me to offer .debs myself than to deal
with a bureaucracy and non-standard kernel in Debian. It contains
who-knows-what extra code, and I doubt anyone looked at any of it to
see if it allows for some way to leak information I prevent against a
On lun., 2012-01-30 at 14:08 +, Ben Hutchings wrote:
On Mon, 2012-01-30 at 11:05 +0100, Yves-Alexis Perez wrote:
(adding few CC:s to keep track on the bug)
On dim., 2012-01-29 at 21:26 +, Ben Hutchings wrote:
On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote:
On
On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote:
Featuresets
---
The only featureset provided will be 'rt' (realtime), currently built
for amd64 only. If there is interest in realtime support for other
architectures, we may be able to add that. However, we do need to
On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote:
On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote:
Featuresets
---
The only featureset provided will be 'rt' (realtime), currently built
for amd64 only. If there is interest in realtime support for other
On Sun, 2012-01-29 at 21:26 +, Ben Hutchings wrote:
So in the end what are the reasons for not trying the grsecurity
featureset? #605090 lacks any reply from the kernel team since quite a
while, and especially after answers were provided to question asked.
Whew I'd also be waiting
On Sun, Jan 29, 2012 at 09:26:11PM +, Ben Hutchings wrote:
On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote:
On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote:
Featuresets
---
The only featureset provided will be 'rt' (realtime)
If there are
On Jan 30, Adam Borowski kilob...@angband.pl wrote:
lxc wasn't anywhere near feature parity with vserver/openvz then.
And it still isn't.
It would be nice to have some documentation about how lxc is different from
them, and how to work around bugs and limitations. I for one spent ~10
Let's
56 matches
Mail list logo
