On Sat, 16 Nov 2002 09:56:53 +0200 (IST), Tzafrir Cohen <[EMAIL PROTECTED]> wrote:
>
> Can that key be limited to running only one command (or script?)
>
> This will limit the impact of a possible breach.
Yes the key can be limited, I already described it in my answer to
Eran. Here it is again:
, E.G. the OS used on AS400.
- Original Message -
From: "Eran Tromer" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Meir Michanie" <[EMAIL PROTECTED]>; "IGLU" <[EMAIL PROTECTED]>
Sent: Saturday, November 16, 2002 9:48 AM
Subject: Re: S
On Fri, 15 Nov 2002, Eran Tromer wrote:
> Having peeked at the TCFS sourcecode and scanned their 95-slides
> presentation
> (http://www.tcfs.it/docs/linux-expo-2001/Diapositiva1.JPG.html):
>
> TCFS encrypts at the file block level, and the protocol for sending file
> blocks back and forth is plain
Tzafrir Cohen wrote:
> On Fri, 15 Nov 2002, Eran Tromer wrote:
>
>>Having peeked at the TCFS sourcecode and scanned their 95-slides
>>presentation
>>(http://www.tcfs.it/docs/linux-expo-2001/Diapositiva1.JPG.html):
>>
>>TCFS encrypts at the file block level, and the protocol for sending file
>>bloc
On 15 Nov 2002, Meir Michanie wrote:
> The problem with using nfs today is authentication (don't read
> authorization, it may be another problem).
>
> NFS and PORTMAP relay on trusted hosts, you could use ips ordns names,
> or * (wilcards?)
>
> spoffing this is as simple mounting the nfs share usi
Ehud Karni wrote:
> On 15 Nov 2002 00:28:00 +0200, Meir Michanie <[EMAIL PROTECTED]> wrote:
>>3. get the private key from one compromised client and you have root
>>control over the net, next step would be ssh root@server -i
>>compromised-key
>
> That is not true. The intruder has already root pri
On Fri, Nov 15, 2002 at 06:58:54AM +0200, Eran Tromer wrote:
> I see that Coda is now in the stock Linux kernel, so maybe things have
> indeed improved.
>
> Eran
>
Wasn't there a CODA option in the Kernel configuration for a long time?
I do know that a new or improved CODA package was uplo
On 15 Nov 2002 00:28:00 +0200, Meir Michanie <[EMAIL PROTECTED]> wrote:
>
> One solution is using NFS over ssh.
>
> to do this you need:
>
> 1. edit /etc/exports to something like
> /home localhost(rw,root_squash,secure)
Agreed.
> 2. generate a private key for root and put it in ever
I have noticed another thing with this post.
People talk about security, firewalling, but I am 100% sure than there
is more people in this list besides me that need the functionality of
NFS, worst is that I am sure they as I were letting this issue pass
under their eyes. So ...
How come nobody re
On Fri, 2002-11-15 at 07:32, Official Flamer/Cabal NON-Leader wrote:
> Quoth Eran Tromer:
>
> > Meir Michanie wrote:
> > > The problem with using nfs today is authentication (don't read
> > > authorization, it may be another problem)
> >
> > The alternative filesystems included AFS, SFS, CODA and
Having peeked at the TCFS sourcecode and scanned their 95-slides
presentation
(http://www.tcfs.it/docs/linux-expo-2001/Diapositiva1.JPG.html):
TCFS encrypts at the file block level, and the protocol for sending file
blocks back and forth is plain NFS, so an eavesdropper knows which block
of which
Quoth Eran Tromer:
> Meir Michanie wrote:
> > The problem with using nfs today is authentication (don't read
> > authorization, it may be another problem)
>
> The alternative filesystems included AFS, SFS, CODA and InterMezzo.
Hmmm... I suspect that TCFS (Transparent Cryptographic FS) is the bet
I see that Coda is now in the stock Linux kernel, so maybe things have
indeed improved.
Eran
Eran Tromer wrote:
> The alternative filesystems included AFS, SFS, CODA and InterMezzo.
> Theoretically all are up to the task, but the last three were immature
> (at least at that time) and AFS lacks
mised-key
[...]
Yup, NFS is fundamentally broken in this sense.
We discussed this issue on linux-il a while ago (subject: "Secure NFS
with untrusted clients"), and shockingly enough there weren't any good
answers.
The alternative filesystems included AFS, SFS, CODA and InterMezzo.
T
The problem with using nfs today is authentication (don't read
authorization, it may be another problem).
NFS and PORTMAP relay on trusted hosts, you could use ips or dns names,
or * (wilcards?)
spoffing this is as simple mounting the nfs share using edited local
/etc/passwd.
You may say that h
Daniel Pearson wrote:
> On Sat, Feb 23, 2002, Eran Tromer <[EMAIL PROTECTED]> wrote
> the following:
>>Not a pretty situation, for something as basic as a network filesystem
>>in which you don't have to totally trust all client boxes!
>>And let's admit it, WinNT shows that better solutions ar
On Sat, Feb 23, 2002, Eran Tromer <[EMAIL PROTECTED]> wrote the following:
[long description of the shortcomings of AFS snipped]
> Not a pretty situation, for something as basic as a network filesystem
> in which you don't have to totally trust all client boxes!
> And let's admit it, WinNT show
Hi,
Tzafrir Cohen wrote:
> On Fri, 22 Feb 2002, Eran Tromer wrote:
>>
>>I wonder about the following scenario, which is quite common:
>>A large network consisting of many users and many Unix boxes. Users
>>aren't supposed to have root access to any box. All home directories
>>reside on a central
On Fri, 22 Feb 2002, Eran Tromer wrote:
> Hello,
>
> I wonder about the following scenario, which is quite common:
> A large network consisting of many users and many Unix boxes. Users
> aren't supposed to have root access to any box. All home directories
> reside on a central fileserver. How do
Hello,
I wonder about the following scenario, which is quite common:
A large network consisting of many users and many Unix boxes. Users
aren't supposed to have root access to any box. All home directories
reside on a central fileserver. How do you configure the networked
filesystem?
The obvi
On Tue, 4 May 1999, guy keren wrote:
I think you need something like this.
Package: cfs
Priority: extra
Section: non-us/otherosfs
Installed-Size: 396
Maintainer: Patrick J. Edwards <[EMAIL PROTECTED]>
Architecture: i386
Version: 1.3.3-1
Size: 174072
Description: Cryptographic Filesystem
On Sun, 2 May 1999, Alex Shnitman wrote:
> Is anybody aware of an alternative to NFS that works the way ssh does,
> i.e. does authentication not according to the IP but according to the
> existance of the right key on the other side? Some kind of NFS with
> public-key cryptoraphy? In other word
It have nothing to do with NFS security; it is related to ONC RPC security. The whole
point behind RPC is to free client-server programmers from certion tasks;
Security is one of them.
For a Linux solution see:
http://www.fit.qut.edu.au/~ashley/sesp5b.html
Guy Cohen wrote:
> At this (Sun,
At this (Sun, May 02, 1999 at 04:19:24PM +0300) day, Alex Shnitman wrote:
| Hi.
|
| Is anybody aware of an alternative to NFS that works the way ssh does,
| i.e. does authentication not according to the IP but according to the
| existance of the right key on the other side? Some kind of NFS with
Alex Shnitman <[EMAIL PROTECTED]> wrote:
> I reckon this is not a unique situation. What do other people use for
> synchronizing work over their computers?
They use rsync. rsync -e ssh to feel safe.
Regards,
Evgeny
--
/ Evge
Hi.
Is anybody aware of an alternative to NFS that works the way ssh does,
i.e. does authentication not according to the IP but according to the
existance of the right key on the other side? Some kind of NFS with
public-key cryptoraphy? In other words, something that is to NFS what
ssh is to rsh
26 matches
Mail list logo
