At 10:34 Uhr +0200 19.6.2001, Ethan Benson wrote:
On Tue, Jun 19, 2001 at 10:09:51AM +0200, Christian Jaeger wrote:
> But if the passwd command doesn't itself have the rights to access
> /etc/shadow but only the root login shell has (which only runs if
> called through sshd), then the cracker
At 10:34 Uhr +0200 19.6.2001, Ethan Benson wrote:
>On Tue, Jun 19, 2001 at 10:09:51AM +0200, Christian Jaeger wrote:
> > But if the passwd command doesn't itself have the rights to access
> > /etc/shadow but only the root login shell has (which only runs if
> > called through sshd), then the cr
On Tue, Jun 19, 2001 at 12:28:46AM -0800, Ethan Benson wrote:
> On Tue, Jun 19, 2001 at 12:17:07PM +0800, Ben Harvey wrote:
>
> > cracker==root sysadmin==root+LIDS_password
> > if someone can sniff me typing in my lids password (encrypted in the kernel)
> > then I am stuffed.
>
> they can always
On Tue, Jun 19, 2001 at 12:28:46AM -0800, Ethan Benson wrote:
> On Tue, Jun 19, 2001 at 12:17:07PM +0800, Ben Harvey wrote:
>
> > cracker==root sysadmin==root+LIDS_password
> > if someone can sniff me typing in my lids password (encrypted in the kernel)
> > then I am stuffed.
>
> they can always
On Wed, Jun 20, 2001 at 12:02:47AM -0600, Hubert Chan wrote:
> be SUID, you're safer without it being SUID). Is there any (sane) way
> of making it so that programs such as passwd, chsh, etc. don't need to
> be SUID?
Not really. Not if you want to ensure that any of the data they can alter
passe
On Wed, Jun 20, 2001 at 12:02:47AM -0600, Hubert Chan wrote:
> be SUID, you're safer without it being SUID). Is there any (sane) way
> of making it so that programs such as passwd, chsh, etc. don't need to
> be SUID?
Not really. Not if you want to ensure that any of the data they can alter
pass
On Wed, Jun 20, 2001 at 12:02:47AM -0600, Hubert Chan wrote:
> > "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes:
>
> Ethan> echo 'eb::0:0:Ethan Benson:/home/eb:/bin/bash' > /etc/passwd.d/eb
>
> Ethan> login whe r00t!
>
> Hmm. Forgot about that. I guess that would be a bit of a secu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes:
Ethan> echo 'eb::0:0:Ethan Benson:/home/eb:/bin/bash' > /etc/passwd.d/eb
Ethan> login whe r00t!
Hmm. Forgot about that. I guess that would be a bit of a security
hole. :-(
Ethan> it wo
On Wed, Jun 20, 2001 at 12:02:47AM -0600, Hubert Chan wrote:
> > "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes:
>
> Ethan> echo 'eb::0:0:Ethan Benson:/home/eb:/bin/bash' > /etc/passwd.d/eb
>
> Ethan> login whe r00t!
>
> Hmm. Forgot about that. I guess that would be a bit of a sec
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes:
Ethan> echo 'eb::0:0:Ethan Benson:/home/eb:/bin/bash' > /etc/passwd.d/eb
Ethan> login whe r00t!
Hmm. Forgot about that. I guess that would be a bit of a security
hole. :-(
Ethan> it w
On Tue, Jun 19, 2001 at 12:35:51PM -0600, Hubert Chan wrote:
> > "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes:
>
> Ethan> passwd not being able to update /etc/shadow would be a very bad
> Ethan> thing since users would be unable to change thier own passwords.
> Ethan> users need to be en
On Tue, Jun 19, 2001 at 12:35:51PM -0600, Hubert Chan wrote:
> > "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes:
>
> Ethan> passwd not being able to update /etc/shadow would be a very bad
> Ethan> thing since users would be unable to change thier own passwords.
> Ethan> users need to be e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes:
Ethan> passwd not being able to update /etc/shadow would be a very bad
Ethan> thing since users would be unable to change thier own passwords.
Ethan> users need to be encouraged to change thier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> "Ethan" == Ethan Benson <[EMAIL PROTECTED]> writes:
Ethan> passwd not being able to update /etc/shadow would be a very bad
Ethan> thing since users would be unable to change thier own passwords.
Ethan> users need to be encouraged to change thie
On Tue, Jun 19, 2001 at 10:09:51AM +0200, Christian Jaeger wrote:
> At 2:17 Uhr +0200 19.6.2001, Ethan Benson wrote:
> >what if the attacker can poisen your DNS, or routing tables? then he
> >can trick apt into downloading his 37337 `security update' (more like
> >unsecurity update heh)
>
> Yes,
On Tue, Jun 19, 2001 at 12:17:07PM +0800, Ben Harvey wrote:
> cracker==root sysadmin==root+LIDS_password
> if someone can sniff me typing in my lids password (encrypted in the kernel)
> then I am stuffed.
they can always read the password hash out of the kernel and run a
brute force attack on it
At 2:17 Uhr +0200 19.6.2001, Ethan Benson wrote:
what if the attacker can poisen your DNS, or routing tables? then he
can trick apt into downloading his 37337 `security update' (more like
unsecurity update heh)
Yes, but that's a problem anyway, isn't it? In fact it's a question I
have about d
On Tue, Jun 19, 2001 at 10:09:51AM +0200, Christian Jaeger wrote:
> At 2:17 Uhr +0200 19.6.2001, Ethan Benson wrote:
> >what if the attacker can poisen your DNS, or routing tables? then he
> >can trick apt into downloading his 37337 `security update' (more like
> >unsecurity update heh)
>
> Yes,
On Tue, Jun 19, 2001 at 12:17:07PM +0800, Ben Harvey wrote:
> cracker==root sysadmin==root+LIDS_password
> if someone can sniff me typing in my lids password (encrypted in the kernel)
> then I am stuffed.
they can always read the password hash out of the kernel and run a
brute force attack on it
At 2:17 Uhr +0200 19.6.2001, Ethan Benson wrote:
>what if the attacker can poisen your DNS, or routing tables? then he
>can trick apt into downloading his 37337 `security update' (more like
>unsecurity update heh)
Yes, but that's a problem anyway, isn't it? In fact it's a question I
have about
On Sun, Jun 17, 2001 at 07:55:40PM -0800, Ethan Benson wrote:
>
> a bit. lids makes system adminsitration utterly impossible. unless
> you leave enough holes open which an attacker can use to bypass it
> all.
well nearly...
at least you can prevent new or unknown process/files from acessing stu
On Sun, Jun 17, 2001 at 07:55:40PM -0800, Ethan Benson wrote:
>
> a bit. lids makes system adminsitration utterly impossible. unless
> you leave enough holes open which an attacker can use to bypass it
> all.
well nearly...
at least you can prevent new or unknown process/files from acessing st
On Mon, Jun 18, 2001 at 06:41:59PM +0200, Christian Jaeger wrote:
>
> Well, if the 'apt-get update && apt-get upgrade' wrapper doesn't take
> any input and resets the environment (is there anything else it
> should take care of?) then even if called by the cracker it wouldn't
> do anything else
On Mon, Jun 18, 2001 at 06:41:59PM +0200, Christian Jaeger wrote:
>
> Well, if the 'apt-get update && apt-get upgrade' wrapper doesn't take
> any input and resets the environment (is there anything else it
> should take care of?) then even if called by the cracker it wouldn't
> do anything els
At 5:55 Uhr +0200 18.6.2001, Ethan Benson wrote:
On Mon, Jun 18, 2001 at 03:03:06AM +0200, Christian Jaeger wrote:
> ... install some special binaries to which you
> grant many permissions.
the thing is once you make exceptions for the system adminsistrator to
use to maintain the you open the
On Mon, Jun 18, 2001 at 03:52:46AM -0800, Ethan Benson wrote:
> On Mon, Jun 18, 2001 at 12:43:41PM +0200, Philipp Schulte wrote:
> > Ok, so just do make sure: http://www.lids.org/lids-howto/node53.html
> > is claiming that CAP_SYS_RAWIO allows access to raw block devices.
>
> they are mistaken.
At 5:55 Uhr +0200 18.6.2001, Ethan Benson wrote:
>On Mon, Jun 18, 2001 at 03:03:06AM +0200, Christian Jaeger wrote:
> > ... install some special binaries to which you
> > grant many permissions.
>
>the thing is once you make exceptions for the system adminsistrator to
>use to maintain the you op
On Mon, Jun 18, 2001 at 03:52:46AM -0800, Ethan Benson wrote:
> On Mon, Jun 18, 2001 at 12:43:41PM +0200, Philipp Schulte wrote:
> > Ok, so just do make sure: http://www.lids.org/lids-howto/node53.html
> > is claiming that CAP_SYS_RAWIO allows access to raw block devices.
>
> they are mistaken.
On Mon, Jun 18, 2001 at 12:43:41PM +0200, Philipp Schulte wrote:
> On Mon, Jun 18, 2001 at 12:35:13AM -0800, Ethan Benson wrote:
>
> > chattr +i and +a cannot be set or removed if CAP_LINUX_IMMUTABLE is
> > removed from the bounding set. however that does not prevent root
> > from messing with /
On Mon, Jun 18, 2001 at 12:35:13AM -0800, Ethan Benson wrote:
> chattr +i and +a cannot be set or removed if CAP_LINUX_IMMUTABLE is
> removed from the bounding set. however that does not prevent root
> from messing with /dev/hda* directly, niether does CAP_SYS_RAWIO.
>
> there is no capabilit
On Mon, Jun 18, 2001 at 12:43:41PM +0200, Philipp Schulte wrote:
> On Mon, Jun 18, 2001 at 12:35:13AM -0800, Ethan Benson wrote:
>
> > chattr +i and +a cannot be set or removed if CAP_LINUX_IMMUTABLE is
> > removed from the bounding set. however that does not prevent root
> > from messing with
On Mon, Jun 18, 2001 at 04:02:08AM -0300, Peter Cordes wrote:
>
> You need to keep it somewhere if you ever want to build more modules
> that that kernel will load. I don't know why I assumed it would be
> stored in the kernel image.
it could be a separate file, encrpyted (like gpg private keys
On Mon, Jun 18, 2001 at 08:56:03AM +0200, Philipp Schulte wrote:
> On Sun, Jun 17, 2001 at 10:42:17PM -0800, Ethan Benson wrote:
>
> > you would need to fix filesystem immutability and block device access
> > as well. currently lcap CAP_LINUX_IMMUTABLE is useless since there
> > is no way to de
On Mon, Jun 18, 2001 at 12:35:13AM -0800, Ethan Benson wrote:
> chattr +i and +a cannot be set or removed if CAP_LINUX_IMMUTABLE is
> removed from the bounding set. however that does not prevent root
> from messing with /dev/hda* directly, niether does CAP_SYS_RAWIO.
>
> there is no capabili
On Sun, Jun 17, 2001 at 10:42:17PM -0800, Ethan Benson wrote:
> On Mon, Jun 18, 2001 at 01:38:16AM -0300, Peter Cordes wrote:
> > I like the package signing idea. That would be cool. That way, you
> > could still load and unload modules. I like being able to do that.
> > One obvious problem with
On Sun, Jun 17, 2001 at 10:42:17PM -0800, Ethan Benson wrote:
> you would need to fix filesystem immutability and block device access
> as well. currently lcap CAP_LINUX_IMMUTABLE is useless since there
> is no way to deny root the ability to write directly to /dev/hda* and
> remove the immutab
On Mon, Jun 18, 2001 at 01:38:16AM -0300, Peter Cordes wrote:
> I like the package signing idea. That would be cool. That way, you
> could still load and unload modules. I like being able to do that.
> One obvious problem with the scheme is that an attacker could
> potentially read the keys from
On Mon, Jun 18, 2001 at 04:02:08AM -0300, Peter Cordes wrote:
>
> You need to keep it somewhere if you ever want to build more modules
> that that kernel will load. I don't know why I assumed it would be
> stored in the kernel image.
it could be a separate file, encrpyted (like gpg private key
On Mon, Jun 18, 2001 at 08:56:03AM +0200, Philipp Schulte wrote:
> On Sun, Jun 17, 2001 at 10:42:17PM -0800, Ethan Benson wrote:
>
> > you would need to fix filesystem immutability and block device access
> > as well. currently lcap CAP_LINUX_IMMUTABLE is useless since there
> > is no way to d
I like the package signing idea. That would be cool. That way, you
could still load and unload modules. I like being able to do that.
One obvious problem with the scheme is that an attacker could
potentially read the keys from /boot/vmlinuz-2.4.5, or whatever, and
sign their own module. This ca
On Sun, Jun 17, 2001 at 10:42:17PM -0800, Ethan Benson wrote:
> On Mon, Jun 18, 2001 at 01:38:16AM -0300, Peter Cordes wrote:
> > I like the package signing idea. That would be cool. That way, you
> > could still load and unload modules. I like being able to do that.
> > One obvious problem wit
On Sun, Jun 17, 2001 at 10:42:17PM -0800, Ethan Benson wrote:
> you would need to fix filesystem immutability and block device access
> as well. currently lcap CAP_LINUX_IMMUTABLE is useless since there
> is no way to deny root the ability to write directly to /dev/hda* and
> remove the immuta
On Mon, Jun 18, 2001 at 01:38:16AM -0300, Peter Cordes wrote:
> I like the package signing idea. That would be cool. That way, you
> could still load and unload modules. I like being able to do that.
> One obvious problem with the scheme is that an attacker could
> potentially read the keys fro
On Mon, Jun 18, 2001 at 01:27:37AM +, Jim Breton wrote:
> On Sun, Jun 17, 2001 at 02:44:48AM -0800, Ethan Benson wrote:
> >
> > compiling without module support would be mostly the same as just
> >
> > lcap CAP_SYS_MODULE
>
>
> Fwiw, I have heard (though not tested myself) that even if you
On Mon, Jun 18, 2001 at 03:03:06AM +0200, Christian Jaeger wrote:
> Hello
>
> Do you know about LIDS (www.lids.org)? It also gives the ability to
> play with CAP's, but seems much more sophisticated.
>
> I've just subscribed to this list. Has LIDS been discussed here before?
a bit. lids makes
I like the package signing idea. That would be cool. That way, you
could still load and unload modules. I like being able to do that.
One obvious problem with the scheme is that an attacker could
potentially read the keys from /boot/vmlinuz-2.4.5, or whatever, and
sign their own module. This c
On Mon, Jun 18, 2001 at 01:27:37AM +, Jim Breton wrote:
> On Sun, Jun 17, 2001 at 02:44:48AM -0800, Ethan Benson wrote:
> >
> > compiling without module support would be mostly the same as just
> >
> > lcap CAP_SYS_MODULE
>
>
> Fwiw, I have heard (though not tested myself) that even if yo
On Mon, Jun 18, 2001 at 03:03:06AM +0200, Christian Jaeger wrote:
> Hello
>
> Do you know about LIDS (www.lids.org)? It also gives the ability to
> play with CAP's, but seems much more sophisticated.
>
> I've just subscribed to this list. Has LIDS been discussed here before?
a bit. lids makes
On Sun, Jun 17, 2001 at 02:44:48AM -0800, Ethan Benson wrote:
>
> compiling without module support would be mostly the same as just
>
> lcap CAP_SYS_MODULE
Fwiw, I have heard (though not tested myself) that even if you compile
your kernel _without_ loadable module support, you will still be ab
Hello
Do you know about LIDS (www.lids.org)? It also gives the ability to
play with CAP's, but seems much more sophisticated.
I've just subscribed to this list. Has LIDS been discussed here before?
I'm interested in using it, but am not sure how to use it best. In
fact I currently think it's
On Sun, Jun 17, 2001 at 02:44:48AM -0800, Ethan Benson wrote:
>
> compiling without module support would be mostly the same as just
>
> lcap CAP_SYS_MODULE
Fwiw, I have heard (though not tested myself) that even if you compile
your kernel _without_ loadable module support, you will still be a
Hello
Do you know about LIDS (www.lids.org)? It also gives the ability to
play with CAP's, but seems much more sophisticated.
I've just subscribed to this list. Has LIDS been discussed here before?
I'm interested in using it, but am not sure how to use it best. In
fact I currently think it's
On Sun, Jun 17, 2001 at 01:54:14PM +0200, Sjarn Valkhoff wrote:
> > lcap CAP_SYS_MODULE CAP_SYS_RAWIO
>
> Thanks for the input. Two points:
>
> 1. I coming at this problem as a laptop user so pcmcia modules must remain
> and be loadable and unloadable at will - as far as I know, there is no
> dir
> lcap CAP_SYS_MODULE CAP_SYS_RAWIO
Thanks for the input. Two points:
1. I coming at this problem as a laptop user so pcmcia modules must remain
and be loadable and unloadable at will - as far as I know, there is no
direct
way to compile pcmcia modules directly into the kernel like the other
driv
On Sun, Jun 17, 2001 at 01:54:14PM +0200, Sjarn Valkhoff wrote:
> > lcap CAP_SYS_MODULE CAP_SYS_RAWIO
>
> Thanks for the input. Two points:
>
> 1. I coming at this problem as a laptop user so pcmcia modules must remain
> and be loadable and unloadable at will - as far as I know, there is no
> di
On Sun, Jun 17, 2001 at 01:21:45PM +0300, Juha Jäykkä wrote:
> > lcap CAP_SYS_MODULE CAP_SYS_RAWIO
> > which will disable module loading entirely as well as access to
> > /dev/mem (which can be just as dangerous as a kernel module and would
> > bypass your signed module thing nicely).
>
> Which
> lcap CAP_SYS_MODULE CAP_SYS_RAWIO
> which will disable module loading entirely as well as access to
> /dev/mem (which can be just as dangerous as a kernel module and would
> bypass your signed module thing nicely).
Which means: so long, X. I have a workstation and using X in,
naturally, necess
> lcap CAP_SYS_MODULE CAP_SYS_RAWIO
Thanks for the input. Two points:
1. I coming at this problem as a laptop user so pcmcia modules must remain
and be loadable and unloadable at will - as far as I know, there is no
direct
way to compile pcmcia modules directly into the kernel like the other
dri
On Sun, Jun 17, 2001 at 01:21:45PM +0300, Juha Jäykkä wrote:
> > lcap CAP_SYS_MODULE CAP_SYS_RAWIO
> > which will disable module loading entirely as well as access to
> > /dev/mem (which can be just as dangerous as a kernel module and would
> > bypass your signed module thing nicely).
>
> Whic
> lcap CAP_SYS_MODULE CAP_SYS_RAWIO
> which will disable module loading entirely as well as access to
> /dev/mem (which can be just as dangerous as a kernel module and would
> bypass your signed module thing nicely).
Which means: so long, X. I have a workstation and using X in,
naturally, neces
On Sat, Jun 16, 2001 at 07:43:38PM +0200, Sjarn Valkhoff wrote:
> How feasable would it be to digitally sign kernel modules? Using a trusted
> local private key, a module could be signed at compile time. The kernel
> could be patched to disallow any unsigned modules from loading. I have no
> idea i
On Sat, Jun 16, 2001 at 07:43:38PM +0200, Sjarn Valkhoff wrote:
> How feasable would it be to digitally sign kernel modules? Using a trusted
> local private key, a module could be signed at compile time. The kernel
> could be patched to disallow any unsigned modules from loading. I have no
> idea
How feasable would it be to digitally sign kernel modules? Using a trusted
local private key, a module could be signed at compile time. The kernel
could be patched to disallow any unsigned modules from loading. I have no
idea if this is technically possible, but Knark seems to be a persistent
weakn
How feasable would it be to digitally sign kernel modules? Using a trusted
local private key, a module could be signed at compile time. The kernel
could be patched to disallow any unsigned modules from loading. I have no
idea if this is technically possible, but Knark seems to be a persistent
weak
64 matches
Mail list logo
