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 security
hole. :-(
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 read the
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
-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 would be a
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 security
hole. :-(
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
passes
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 read the
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
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
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, but
-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 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 would be a
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 stuff.
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 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
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, but
-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 passwords,
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 encouraged to
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 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 deny
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 capability
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 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 open the
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 than
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
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 compile
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
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 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 immutable
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 the
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 deny root
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 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 capability
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 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.
Well,
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 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 than
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,
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
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
direct
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 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
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, necessary
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 means:
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
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
direct
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
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 able
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
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
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 if
53 matches
Mail list logo
