Re: [Bastille-linux-discuss] Bastille - AccountSecurity - ProtectRhosts: Use PAM instead?

[Jay B. <ja...@ba...>]

John,

  Thanks for the tip, John.
  
  There's not a vulnerability on a box with the ext2 filesystem, because we
set the immutable bit on the .rhost files.  With this bit set, even root
can't delete/modify the file...

  - Jay

In the wise words of John Nilles:

> David/Jay,
> 
> I had been meaning to post about this problem also, but never got around
> to figuring out how to make the PAM files work correctly. 
> 
> The vulnerability of having root own the .rhost file is that the user
> still owns the directory. Thus the user can still delete .rhost file and
> replace it with one of his own creation.
> 
> Since I don't know how sensitive you guys are about posting
> vulnerabilities to the list. I'm just responding to to Jay and David.
> Jay its up to you to decide whether to post this or not.
> 
> John
> 
> Jay Beale wrote:
> > 
> > In the wise words of David Wheeler:
> > 
> > > I have a minor suggestion for improving Bastille.
> > >
> > > In AccountSecurity.pm, subroutine ProtectRhosts, the routine correctly notes
> > > that the r-tools are insecure.  Its solution is to
> > > create a root-owned, non-writable
> > > ".rhosts" file in each account, and fiddles around with
> > > /usr/sbin/useradd so this will occur in future created accounts.
> > >
> > > I recommend a different approach instead.  Why not have
> > > the "ProtectRhosts" routine modify the PAM configuration for the r-tools
> > > to do the same thing?
> > 
> > I think you're completely right, David.  This has been on my personal to-do
> > list for a while.
> > 
> > I had wanted to do the following:
> > 
> >   1) Make sure r-tools are disabled in inetd.conf
> >   2) Configure PAM to disallow
> >   3) Keep the darn .rhosts files, which are pretty darn untouchable on an
> >      ext2 system, as not even root can touch them.  We should confirm
> >      that user home dirs are on ext2 system, though...
> > 
> > I wanted the 3-prong protect to continue with the strong "defense in depth"
> > idea, where you add several levels of protection for each vulnerability, so
> > as to fail safer when a level/component fails...
> > 
> >   - Jay
> > 
> > 
> > >
> > > Rationale for using PAM instead:
> > > 1. The current approach depends on ext2 immutable extensions; this means that
> > >    home directories cannot use filesystems other than ext2, which limits
> > >    flexibility.
> > >
> > > 2. Although I don't know of a way to break this, the idea of having
> > >    your security depend on files in the directory _owned by the user_
> > >    strikes me as a little dangerous.  And it certainly clutters user
> > >    directories.
> > >
> > > 3. The current approach has to fiddle around with & wrap "useradd".  That
> > >    creates more complexity. It's not a crisis, but it creates another
> > >    possibility of error.  In particular, sometimes hurried administrators
> > >    create special accounts "by hand" and a hand-created account
> > >    would have subtle, unintended, and unreported loopholes.
> > >    In this case, hand-created accounts would quietly permit rcommands.
> > >    Best to avoid this situation if you can.
> > >
> > > 4. Defining the conditions under which login is permitted is the whole
> > >    point of PAM.  Bastille's current approach creates another mechanism
> > >    where none is needed.
> > >
> > > 5. If you later decide to allow _some_ users to use the r-tools, there's
> > >    no centralized place where you can list & change those decisions.
> > >    Instead, you have to poke around & find which users don't have those files.
> > >    And then ask, "did that happen intentionally?"
> > >
> > > There's a better way.
> > >
> > > Implementing the PAM approach should be easy; actually, it'd be easier than the
> > > current approach.  Some code just needs to insert additional requirements
> > > into the relevant files in /etc/pam.d (after checking if they're already done).
> > >
> > > For example, for rlogin, you could do both of the following:
> > >
> > > 1. change the "rhosts_auth" authorization entry from
> > >    "sufficient" to "required", meaning that now the ruser has to be in the
> > >    rhosts _AND_ log in using authentication.
> > >
> > > 2. Add the following requirement:
> > >   auth       required     /lib/security/pam_listfile.so item=user \
> > >                           sense=allow file=/etc/rlogin-users onerr=fail
> > >   Meaning that the administrator would have to _specifically_ authorize
> > >   that particular user to use rlogin in the file "rlogin-users".
> > >   Want to know who's authorized?  Look in the file.  Want to change
> > >   the list?  It's all in one place.  And if they're not in the list
> > >   (the default), they can't use it at all.  The default result is the
> > >   same (no rlogin), but it's more flexible, simple, and it coordinates
> > >   nicely with existing authorization mechanisms.
> > >
> > > I can code this up, but I wanted to hear some feedback first.
> > > You could even support backwards compatibility by, after taking these
> > > steps, deleting all those immutable .rhosts files.
> > >
> > > Thoughts?
> > >
> > >
> > > --
> > >
> > > --- David A. Wheeler
> > >     dwh...@id...
> > >
> > >
> > > _______________________________________________
> > > bastille-linux-discuss mailing list
> > > bas...@li...
> > > http://lists.sourceforge.net/mailman/listinfo/bastille-linux-discuss
> > 
> > --
> > Jay Beale                               ja...@ba...
> > Lead Developer, Bastille Linux          http://www.bastille-linux.org
> > 
> > _______________________________________________
> > bastille-linux-discuss mailing list
> > bas...@li...
> > http://lists.sourceforge.net/mailman/listinfo/bastille-linux-discuss

-- 
Jay Beale 				ja...@ba...
Lead Developer, Bastille Linux		http://www.bastille-linux.org