many cases these days. Put a padlock on the tab and nobody gonna open that
thing without a bit of hassle.
-Original Message-
From: Alex Pires de Camargo [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 23, 2000 2:08 AM
To: debian-security@lists.debian.org
Subject: Problems with root on ne
many cases these days. Put a padlock on the tab and nobody gonna open that
thing without a bit of hassle.
-Original Message-
From: Alex Pires de Camargo [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 23, 2000 2:08 AM
To: [EMAIL PROTECTED]
Subject: Problems with root on network cl
Just a suggestion: install free s-wan (ipsec) in the computers in
your network, which will take care of securing the underlying IP
connection, and then run whatever you want on top of it. IPSec is a bit
intensive on CPU, but, if correctly implemented, is definitely secure. I
remember somebo
Just a suggestion: install free s-wan (ipsec) in the computers in
your network, which will take care of securing the underlying IP
connection, and then run whatever you want on top of it. IPSec is a bit
intensive on CPU, but, if correctly implemented, is definitely secure. I
remember someb
>they can always plug in a new IDE disk which they can boot from, have
>root, mount NFS... they could also simply bring in a laptop, see
I forgot about that. I ought to be retired and I'm not even
employable. Arggh.
>they can always plug in a new IDE disk which they can boot from, have
>root, mount NFS... they could also simply bring in a laptop, see
I forgot about that. I ought to be retired and I'm not even
employable. Arggh.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscr
On Fri, Nov 24, 2000 at 01:08:14PM -0400, Brad Allen wrote:
> erbenson> NFS is insecure, deal with it.
>
> Such as use something besides NFS that is secure; the options are thin
> and immature, but you may still look around because I have a feeling
> there may be a good match, if you're willing to
On Fri, Nov 24, 2000 at 01:08:14PM -0400, Brad Allen wrote:
> erbenson> NFS is insecure, deal with it.
>
> Such as use something besides NFS that is secure; the options are thin
> and immature, but you may still look around because I have a feeling
> there may be a good match, if you're willing t
The solution to this is to NOT make the xterms mount the users' homes.
This is both not necessary and a security breach.
Use xdm on the server to control the xterm display. This way users
don't need to run anything in the local machine, and the server does
not export the filesystems.
Some of our
The solution to this is to NOT make the xterms mount the users' homes.
This is both not necessary and a security breach.
Use xdm on the server to control the xterm display. This way users
don't need to run anything in the local machine, and the server does
not export the filesystems.
Some of our
* Ethan Benson
| note that i don't fully understand how coda works, but the impression
| i get is you need a very large ammount of LOCAL disk space to hold
| coda's cache/offline storage. this to me defeats the purpose of a
| network filesystem in a large number of cases (i have several machines
* Ethan Benson
| note that i don't fully understand how coda works, but the impression
| i get is you need a very large ammount of LOCAL disk space to hold
| coda's cache/offline storage. this to me defeats the purpose of a
| network filesystem in a large number of cases (i have several machine
On Fri, Nov 24, 2000 at 01:08:14PM -0400, Brad Allen wrote:
> erbenson> NFS is insecure, deal with it.
>
> Such as use something besides NFS that is secure; the options are thin
> and immature, but you may still look around because I have a feeling
> there may be a good match, if you're willing to
On Fri, Nov 24, 2000 at 01:08:14PM -0400, Brad Allen wrote:
> erbenson> NFS is insecure, deal with it.
>
> Such as use something besides NFS that is secure; the options are thin
> and immature, but you may still look around because I have a feeling
> there may be a good match, if you're willing t
Except that sometimes NICs answer ping requests even while in reboot.
Depends on the NIC.
pgpe0Dku5fIUO.pgp
Description: PGP signature
erbenson> NFS is insecure, deal with it.
Such as use something besides NFS that is secure; the options are thin
and immature, but you may still look around because I have a feeling
there may be a good match, if you're willing to sacrafice admin time
to the task. For instance, I'm curious if CODA
Except that sometimes NICs answer ping requests even while in reboot.
Depends on the NIC.
PGP signature
erbenson> NFS is insecure, deal with it.
Such as use something besides NFS that is secure; the options are thin
and immature, but you may still look around because I have a feeling
there may be a good match, if you're willing to sacrafice admin time
to the task. For instance, I'm curious if CODA
In message <[EMAIL PROTECTED]>, Charles Goyard writes:
>Alex Pires de Camargo a ?crit :
>> I administer a network with server and clients Debian based,
>> and would like to know if I can solve this problem.
>> It's a little easy to an user open a PC, damage the batteries,
>> boot with flo
... verify the recipient Luke before pressing the "send" button ;-)
"J-E.Schulz" wrote:
>
> Hi,
>
> as long as the server machines resides in a _really_
> restricted area (e.g. a machine room which may by
> physically accessed only by trusted staff members)
> You may have the chance to securly d
On Thu, Nov 23, 2000 at 02:39:54PM +0100, Philippe Barnetche wrote:
> Hi,
>
> you can change the PAM attributes of "su", avoiding local root to get user
> account access. Of course, if your /etc is local, you'll still have the
> problem.
that would be very weak, if root could write to anywhere
In message <[EMAIL PROTECTED]>, Charles Goyard writes:
>Alex Pires de Camargo a écrit :
>> I administer a network with server and clients Debian based,
>> and would like to know if I can solve this problem.
>> It's a little easy to an user open a PC, damage the batteries,
>> boot with fl
... verify the recipient Luke before pressing the "send" button ;-)
"J-E.Schulz" wrote:
>
> Hi,
>
> as long as the server machines resides in a _really_
> restricted area (e.g. a machine room which may by
> physically accessed only by trusted staff members)
> You may have the chance to securly
Hi,
you can change the PAM attributes of "su", avoiding local root to get user
account access. Of course, if your /etc is local, you'll still have the
problem.
Le jeu, 23 nov 2000, Alex Pires de Camargo a écrit :
> Hi!
> I administer a network with server and clients Debian based,
> and w
On Thu, Nov 23, 2000 at 02:39:54PM +0100, Philippe Barnetche wrote:
> Hi,
>
> you can change the PAM attributes of "su", avoiding local root to get user
> account access. Of course, if your /etc is local, you'll still have the
> problem.
that would be very weak, if root could write to anywhere
Hi,
you can change the PAM attributes of "su", avoiding local root to get user
account access. Of course, if your /etc is local, you'll still have the
problem.
Le jeu, 23 nov 2000, Alex Pires de Camargo a écrit :
> Hi!
> I administer a network with server and clients Debian based,
> and
* Alex Pires de Camargo
| Is there anything I'm forgetting to make? On server I run
| potato, nis (not nis+), nfs-kernel-server.
There is a export-on-demand system, which makes the user authorized
himself via kerberos before his home directory is exported. I don't
remember the name, but I
Alex Pires de Camargo a écrit :
> Hi!
> I administer a network with server and clients Debian based,
> and would like to know if I can solve this problem.
> It's a little easy to an user open a PC, damage the batteries,
> boot with floppy and login as root in a client. But one thi
Hi!
I administer a network with server and clients Debian based,
and would like to know if I can solve this problem.
It's a little easy to an user open a PC, damage the batteries,
boot with floppy and login as root in a client. But one thing is
undesirable. He can do su - a
* Alex Pires de Camargo
| Is there anything I'm forgetting to make? On server I run
| potato, nis (not nis+), nfs-kernel-server.
There is a export-on-demand system, which makes the user authorized
himself via kerberos before his home directory is exported. I don't
remember the name, but
Alex Pires de Camargo a écrit :
> Hi!
> I administer a network with server and clients Debian based,
> and would like to know if I can solve this problem.
> It's a little easy to an user open a PC, damage the batteries,
> boot with floppy and login as root in a client. But one th
Hi!
I administer a network with server and clients Debian based,
and would like to know if I can solve this problem.
It's a little easy to an user open a PC, damage the batteries,
boot with floppy and login as root in a client. But one thing is
undesirable. He can do su -
32 matches
Mail list logo
