On Lu, 26 dec 11, 15:37:03, Russell Coker wrote:
> >
> > At least a couple of years ago if you left /home with no free space, kdm
> > (or something under the hood) would be unable to create ~/.Xauthority-*
> > files, making it impossible to log into a graphical session.
Still true with Squeeze.
On Sun, Dec 25, 2011 at 12:08:57PM +, Philipp Kern wrote:
> On 2011-12-25, Stephan Seitz wrote:
> > All admins I know have at least some servers with custom kernels (in the
> > past it was said, to build your firewall/server kernels without module
> > support, so that no rootkit module could b
On Mon, Dec 26, 2011 at 11:38:10AM +0100, Iustin Pop wrote:
> > > All admins I know have at least some servers with custom kernels (in the
> > > past it was said, to build your firewall/server kernels without module
> > > support, so that no rootkit module could be loaded).
> >
> > No longer neede
On Mon, Dec 26, 2011 at 11:38:10AM +0100, Iustin Pop wrote:
> On Sun, Dec 25, 2011 at 12:08:57PM +, Philipp Kern wrote:
> > On 2011-12-25, Stephan Seitz wrote:
> > > All admins I know have at least some servers with custom kernels (in the
> > > past it was said, to build your firewall/server k
On Mon, Dec 26, 2011 at 04:42:45PM +0600, Andrey Rahmatullin wrote:
> On Mon, Dec 26, 2011 at 11:38:10AM +0100, Iustin Pop wrote:
> > > > All admins I know have at least some servers with custom kernels (in the
> > > > past it was said, to build your firewall/server kernels without module
> > > > s
On Mon, 26 Dec 2011, Iustin Pop wrote:
> > No longer needed. See /proc/sys/kernel/modules_disabled.
>
> That's not equivalent - an attacker that can load modules can also
> remove the init script that sets this variable to 1 and reboot the
> machine.
For many of the things that can be done by l
On Dec 26, Russell Coker wrote:
> For many of the things that can be done by loading a kernel module an
> attacker
> can achieve similar goals by replacing libc or by using ptrace to install
> hostile code in a long-running process that runs as root.
Or load code in the kernel using /dev/mem,
* Philipp Kern [111226 12:02]:
> Sorry, but what kind of argumentation is that? If the admin doesn't notice
> reboots and/or file tampering, I could just replace the kernel with my
> modified
> one and reboot. Now of course you could increase your paranoia and boot the
> kernel from an immutabl
* Russell Coker [111226 14:16]:
> For many of the things that can be done by loading a kernel module an attacker
> can achieve similar goals by replacing libc or by using ptrace to install
> hostile code in a long-running process that runs as root.
Except replacing libc does not help against stat
On 12/22/2011 07:19 PM, Philip Hands wrote:
> I'm still yet to understand the significant upsides of this proposal
So far, the only upside that has been written here, if I understand
well, is less patches for upstream udev, which is important since we
don't have enough people to work on alternative
On 12/22/2011 05:50 PM, Marco d'Itri wrote:
> The main objections so far can be summarized as "I like to do thing my
> way and changes make me unconfortable".
>
No, the main objection is:
I have already many systems/servers in production already. Please don't
break them.
I don't mind if using
On 12/09/2011 03:21 PM, Goswin von Brederlow wrote:
> As I mentioned I have a bug open (in the grml bug tracker) about
> providing a grml.deb. That would install an image in /boot and add
> itself to the bootloader. The small grml image is more like 180MB than
> 25-50MB but it is a verry good rescu
On Dec 26, Thomas Goirand wrote:
> On 12/22/2011 07:19 PM, Philip Hands wrote:
> > I'm still yet to understand the significant upsides of this proposal
> So far, the only upside that has been written here, if I understand
> well, is less patches for upstream udev, which is important since we
> do
On Mon, 26 Dec 2011 20:25:12 +0100, m...@linux.it (Marco d'Itri) wrote:
> On Dec 26, Thomas Goirand wrote:
>
> > On 12/22/2011 07:19 PM, Philip Hands wrote:
> > > I'm still yet to understand the significant upsides of this proposal
> > So far, the only upside that has been written here, if I unde
jida...@jidanni.org writes:
>
> Filesystem 1K-blocksUsed
> Available Use% Mounted on
> rootfs 1071468 287940
> 729100 29% /
> /dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78 1071
On 26/12/11 14:15, Russell Coker wrote:
> But it seems to me that a more useful feature would be the ability to create
> a
> white-list of which modules can be loaded to solve the problem of unwanted
> triggers for module loading and the problem of buggy kernel modules being
> autoloaded in res
On Sat, Dec 24, 2011 at 07:03:10PM +0800, Paul Wise wrote:
> > I'd still like to know what the compelling reason for the change is
> > though.
> Apparently the reason is simply that our upstreams (who it sounds like
> are predominantly driven by Redhat folks) are dropping support for /
> and /usr
On Sat, Dec 24, 2011 at 08:17:25PM -0800, Josh Triplett wrote:
> Not quite. Redhat and others want to make this change (moving binaries
> and libraries from / into /usr) not just for ease of maintenance (though
> that makes sense too) but for several rather interesting reasons. It
> would consoli
On 2011-12-26, Bernhard R. Link wrote:
> * Philipp Kern [111226 12:02]:
>> Sorry, but what kind of argumentation is that? If the admin doesn't notice
>> reboots and/or file tampering, I could just replace the kernel with my
>> modified
>> one and reboot. Now of course you could increase your p
Hello,
The latest Boost (1.48) is now in testing, and I'd like to switch the
defaults. My first plan was to simply announce the switch then make
it. I did so and got an immediate email from the release team
asking to revert the default change, which I did.
On Tue, Dec 20, 2011 at 08:00:15PM -0
Adam Borowski writes:
>> And things may change yet again in the future. With Btrfs, one can
>> have a single filesystem with multiple subvolumes. The subvolumes
>> can be mounted independently, and also snapshotted independently,
>> but have a common pool for free data, so unlike partitions any
On Mon, Dec 26, 2011 at 06:59:07PM +0100, Bernhard R. Link wrote:
> > It is a good thing to run with minimum privs, but compiling a new kernel to
> > support this seems to be a lot of work for a fairly small benefit.
> First of all it is quite a significant benefit. And you get quite some
> other a
On Mon, 2011-12-26 at 22:17 +, Philip Hands wrote:
> On Mon, 26 Dec 2011 20:25:12 +0100, m...@linux.it (Marco d'Itri) wrote:
> > On Dec 26, Thomas Goirand wrote:
> >
> > > On 12/22/2011 07:19 PM, Philip Hands wrote:
> > > > I'm still yet to understand the significant upsides of this proposal
* Andrey Rahmatullin [111227 07:53]:
> On Mon, Dec 26, 2011 at 06:59:07PM +0100, Bernhard R. Link wrote:
> > > It is a good thing to run with minimum privs, but compiling a new kernel
> > > to
> > > support this seems to be a lot of work for a fairly small benefit.
> > First of all it is quite a
Le lundi 26 décembre 2011 à 17:08 -0800, Steve Langasek a écrit :
> If someone would give even *one* example where something legitimately needed
> by a udev rule could not be moved from /usr to / without breaking interfaces
> or otherwise complicating matters, then that would be worth discussing.
Le mardi 27 décembre 2011 à 08:53 +0100, Josselin Mouette a écrit :
> Le lundi 26 décembre 2011 à 17:08 -0800, Steve Langasek a écrit :
> > If someone would give even *one* example where something legitimately needed
> > by a udev rule could not be moved from /usr to / without breaking interfaces
* Philipp Kern [111227 04:04]:
> > As you pointed out so nicely: modules_disabled is only a replacement if
> > you have a custom initramfs and do not allow that to be modified
> > automatically. So from the point of the original discussion,
> > modules_disabled is no solution.
>
> You just stuff a
27 matches
Mail list logo
