by Eugene Blanchar » Fri, 13 Mar 1998 04:00:00
I'm running NIS (ypserv + ypbind) on my network lab. Anyone on a client
Linux box who logs in as root can su to a user listed in the ypserv
database. Is there a way that I can stop users logged in as root on a
linux client from from having root permissions on the server?
by Chris Bradfiel » Sat, 14 Mar 1998 04:00:00
: I'm running NIS (ypserv + ypbind) on my network lab. Anyone on a client
: Linux box who logs in as root can su to a user listed in the ypserv
: database. Is there a way that I can stop users logged in as root on a
: linux client from from having root permissions on the server?
First off, it is generally a "bad thing" to have your root passwd in your
NIS tables. It makes it way to easily accessable to users and the world
for cracking which is generally not what you desire =). What you should
do instead is either keep the passwd in /etc/passwd or /etc/shadow (if
you are using shadowed passwords) and just have NIS merge the maps with
the files (which is what it does anyway with /etc/passwd).
Doing this will make it so root users are only root on their machine rather
than the NIS network. However, root users can still su to any user on the
box (that includes NIS users). Out of curiousity, why is this an issue?
- Chris
--
-----------------------------------------------------------------------
| Student, Programmer. | |
-- PGP fingerprint: 19 C9 B0 1F AD CF 8A 07 6F 29 84 84 F0 DF 7D 10 --
by Eugene Blanchar » Sat, 14 Mar 1998 04:00:00
> : I'm running NIS (ypserv + ypbind) on my network lab. Anyone on a client
> : Linux box who logs in as root can su to a user listed in the ypserv
> : database. Is there a way that I can stop users logged in as root on a
> : linux client from from having root permissions on the server?
> First off, it is generally a "bad thing" to have your root passwd in your
> NIS tables. It makes it way to easily accessable to users and the world
> for cracking which is generally not what you desire =). What you should
> do instead is either keep the passwd in /etc/passwd or /etc/shadow (if
> you are using shadowed passwords) and just have NIS merge the maps with
> the files (which is what it does anyway with /etc/passwd).
> Doing this will make it so root users are only root on their machine rather
> than the NIS network. However, root users can still su to any user on the
> box (that includes NIS users). Out of curiousity, why is this an issue?
I was wondering if there was a way of preventing them from doing this.
Would this imply that anyone running linux and NIS on a laptop and
logged in as root could break into any NIS network if they knew the nis
domainname?
1. Reasonable nis security between Solaris & Linux (was Re: Is nis (yp) a security worry?
My original question was basically a "should I worry" concerning Solaris
sending encrypted passwords via nis to PC's running Linux. The response I
got was that I should worry, e.g. about spoofing and ypcat passwd. The full
answer seems more complicated - ypcat passwd doesn't return the encrypted
passwords (rather "*" or "*NP*") for the two systems I looked at, and the
shadow file isn't in the "compatibility" list for nis+ under Solaris 2 so it
a question of yp make cobbling together the passwd and shadow file information to
make one backwards-compatible yp file.
But all this does seem to depend on the setup, and of course doesn't get me
any closer to some method of getting encrypted password to Linux clients, who
should have at least the level of security of the Solaris host from which the
passwords are kept - i.e. the /etc/shadow file is not world-readable there
so it shouldn't be readable (via ypcat or whatever) on the clients.
This *must* be something people have solved before? I cannot run nis+ (some
of the clients, such as Linux, Sunos 4.x cannot run that), I cannot run Novell's
NDS on Solaris yet (even though Linux supports it) - besides I'm not sure that
sort of thing is what I want, and being outside the US some security options
are limited anyway.
I am scared of reducing the security of the main system with Linux satellites;
but I appreciate that "reasonable" security is always a compromise, and that
having the encrypted paswords available to Joe User is only a problem if people
choose crackable passwords anyway. What is appropriate for the situation isn't
ultra-high security anyway, e.g. the main worry would be if academic staff's
home directories were readable (due to their encrypted passwords being distributed
to lots of computers they probably will never use) and therefore having to redo
some exam questions. Not that I expect the students will try to break the security
but the new Linux systems are a sensitive issue and I don't want people to *fear*
them as a security loophole.
Perhaps the answer is nis 1.2 on the server, with restricted distribution of
all (? or some??) of these passwords to hosts based on IP or subnet. Again, has
anybody done this already and lived to tell the tale?
--
---------------------------------------------------------------------------
Mark Aitchison, Physics & Astronomy \_ Phone : +64 3 3642-947 a.h. 3371-225
University of Canterbury, </ Fax : +64 3 3642-469 or 3642-999
#include <disclaimer.std> (/'
---------------------------------------------------------------------------
3. NIS+: Client/Server problems. Design flaw?
4. setting up the shadow password file
5. Microsoft discloses security flaws
7. Is writing to /dev/ramdom a security flaw (vserver project)
9. Sun, Microsoft tackle security flaws
10. Security Flaw in IPTables FTP Connection Tracking
11. Unfixable Security Flaw in Win32?
12. Microsoft bugs out - Word macro flaw uncovered along with new IIS security breach
13. Are there known security flaws in X400 ?