Unkerberized NFS

[Ed Phillips]

How common is the /etc/publickey in various OSes?  I was thinking that for
our site, it might be nice to access public keys using PAM/LDAP.  On
Solaris, theoretically, sshd could call getpublickey().  It puts another
constraint on login (the LDAP server has to be available), but chances
are, if you're using LDAP, and the LDAP server is down, the Solaris system
can get at /etc/passwd, et. al., stuff either through LDAP, so you'd get a
cached version if available in nscd.

Just a thought...

	Ed

On Tue, 6 Nov 2001, Nicolas Williams wrote:

> Date: Tue, 6 Nov 2001 15:29:57 -0500
> From: Nicolas Williams <Nicolas.Williams at ubsw.com>
> To: Tim McGarry <tim at mcgarry.ch>, mouring at etoh.eviladmin.org
> Cc: Dave Dykstra <dwd at bell-labs.com>, openssh-unix-dev at mindrot.org
> Subject: Re: Unkerberized NFS
>
> I was referring merely to the packet sniffing attack. That was a
> reference to the fact that you can run kerberized NFS without encrypting
> the NFS traffic.
>
> Clearly, using authorized_keys on non-secure NFS home directories is not
> good.
>
> It might be nice, however, to have an option to place authorized_keys
> or alternate authorized_keys files in secure directories, much like
> sendmail has an option to place .forward files in places other than
> users' homedirs. But even this wouldn't help much with non-secure NFS --
> as long as you store useful or sensitive data on non-secure NFS you
> lose.
>
> Nico
>
>
> On Tue, Nov 06, 2001 at 09:20:16PM +0100, Tim McGarry wrote:
> > Sound's good
> >
> > what about authorized_keys though, doesn't stop hacks with rsa, at least
> > with Nicos kerberos principals extension, you'll know who it was who
> > compromised the system (unless of course they undo the changes done to
> > authorizeds_keys really quick. after gaining access)
> >
> > ----- Original Message -----
> > From: "Nicolas Williams" <Nicolas.Williams at ubsw.com>
> > To: <mouring at etoh.eviladmin.org>
> > Cc: "Tim McGarry" <tim at mcgarry.ch>; "Dave Dykstra" <dwd at bell-labs.com>;
> > <openssh-unix-dev at mindrot.org>
> > Sent: Tuesday, November 06, 2001 9:16 PM
> > Subject: Re: Unkerberized NFS
> >
> >
> > > Can't these user-specific seed files be stored in
> > {/var}/tmp/ssh-seed-$user/?
> > >
> > > On Tue, Nov 06, 2001 at 01:46:35PM -0600, mouring at etoh.eviladmin.org
> > wrote:
> > > >
> > > > seed files on NFS.. My only concern is packet sniffing.  How may NFS
> > > > connetions are encryped now days?
> > > >
> > > > - Ben
> > > >
> > > > On Tue, 6 Nov 2001, Tim McGarry wrote:
> > > >
> > > > > I suppose your right, but if you edit someones .profile, you can
> > easily
> > > > > compromise the boxes they log into. If you edit authorized_keys,
> > access to
> > > > > every box in the organisation could be possible
> > > > >
> > > > > Tim McGarry
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Dave Dykstra" <dwd at bell-labs.com>
> > > > > To: "Tim McGarry" <tim at mcgarry.ch>
> > > > > Cc: <openssh-unix-dev at mindrot.org>
> > > > > Sent: Tuesday, November 06, 2001 8:30 PM
> > > > > Subject: Re: Unkerberized NFS
> > > > >
> > > > >
> > > > > > On Tue, Nov 06, 2001 at 08:14:26PM +0100, Tim McGarry wrote:
> > > > > > > I disagree, about NFS, obviously any smart organisation will
> > ensure that
> > > > > NFS
> > > > > > > is secured with kerberos BEFORE they allow RSA authentication.
> > > > > > > But those who dont know better shouldn't find that installing
> > OpenSSH
> > > > > > > actually reduces the system security.
> > > > > >
> > > > > > It does not reduce system security.  If you are exporting a
> > filesystem
> > > > > with
> > > > > > unkerberized NFS read-write, anybody can read and write any (usually
> > > > > non-root)
> > > > > > file, including many things the user executes such as .profile so
> > even
> > > > > > without .rhosts or .ssh/authorized_keys it is totally wide open.
> > Having
> > > > > > SSH worry about unkerberized NFS is like trying to put a slightly
> > stronger
> > > > > > lock on the door of a safe that has a whole wall missing.
> > > > > >
> > > > > > - Dave Dykstra
> > > > > >
> > > > >
> > > > >
> > > --
> > > -DISCLAIMER: an automatically appended disclaimer may follow. By posting-
> > > -to a public e-mail mailing list I hereby grant permission to distribute-
> > > -and copy this message.-
> > >
> > > Visit our website at http://www.ubswarburg.com
> > >
> > > This message contains confidential information and is intended only
> > > for the individual named.  If you are not the named addressee you
> > > should not disseminate, distribute or copy this e-mail.  Please
> > > notify the sender immediately by e-mail if you have received this
> > > e-mail by mistake and delete this e-mail from your system.
> > >
> > > E-mail transmission cannot be guaranteed to be secure or error-free
> > > as information could be intercepted, corrupted, lost, destroyed,
> > > arrive late or incomplete, or contain viruses.  The sender therefore
> > > does not accept liability for any errors or omissions in the contents
> > > of this message which arise as a result of e-mail transmission.  If
> > > verification is required please request a hard-copy version.  This
> > > message is provided for informational purposes and should not be
> > > construed as a solicitation or offer to buy or sell any securities or
> > > related financial instruments.
> > >
> --
> -DISCLAIMER: an automatically appended disclaimer may follow. By posting-
> -to a public e-mail mailing list I hereby grant permission to distribute-
> -and copy this message.-
>
> Visit our website at http://www.ubswarburg.com
>
> This message contains confidential information and is intended only
> for the individual named.  If you are not the named addressee you
> should not disseminate, distribute or copy this e-mail.  Please
> notify the sender immediately by e-mail if you have received this
> e-mail by mistake and delete this e-mail from your system.
>
> E-mail transmission cannot be guaranteed to be secure or error-free
> as information could be intercepted, corrupted, lost, destroyed,
> arrive late or incomplete, or contain viruses.  The sender therefore
> does not accept liability for any errors or omissions in the contents
> of this message which arise as a result of e-mail transmission.  If
> verification is required please request a hard-copy version.  This
> message is provided for informational purposes and should not be
> construed as a solicitation or offer to buy or sell any securities or
> related financial instruments.
>

Ed Phillips <ed at udel.edu> University of Delaware (302) 831-6082
Systems Programmer III, Network and Systems Services
finger -l ed at polycut.nss.udel.edu for PGP public key