NIS interoperability with Linux, was Re: Following directions doesn't seem to work: Adding users in NIS

[Manolis Kiagias]

Lowell Gilbert wrote:
> Manolis Kiagias <sonicy at otenet.gr> writes:
>
>   
>> I have experimented a bit further with my debian NIS server, and this is
>> what I found:
>>
>> >From a NIS client, I can do with my standard user account:
>>
>> sonic at atlantis:~$ ypcat passwd.byname
>> user1:x:1010:1010:Joe User,,,:/home/user1:/bin/bash
>>
>> and I get the standard, world-readable password file (the one without
>> the passwords)
>> However, the standard user cannot run:
>>
>> This is the answer:
>> sonic at atlantis:~$ ypcat shadow.byname
>> No such map shadow.byname. Reason: No such map in server's domain
>>
>> As root, however:
>> root at atlantis:~# ypcat shadow.byname
>> user1:$1$1233245435435345543545345sfsdfsfdf:13577:0:99999:7:::
>> ...
>>
>> This seems to be consistent with the FreeBSD NIS Server behaviour
>> described in nis(8) manual page:
>>
>> " To help prevent this, FreeBSD's NIS server handles the shadow password
>>      maps (master.passwd.byname and master.passwd.byuid) in a special
>> way: the
>>      server will only provide access to these maps in response to requests
>>      that originate on privileged ports.  Since only the super-user is
>> allowed
>>      to bind to a privileged port, the server assumes that all such requests
>>      come from privileged users.  All other requests are denied:
>> requests from
>>      non-privileged ports will receive only an error code from the server."
>>
>> So, it seems linux handles this the same way. Difference is linux has a
>> shadow.byname map while FreeBSD has a master.passwd.byname map
>> (possibly  also internal differences in the files)
>>
>> Now, if I understand correctly, If I where to add the UNSECURE feature
>> in the FreeBSD server, I expect the shadow passwords would be inserted
>> in the passwd.byname map which is world readable and hence a security
>> issue. (Perhaps I will do this experiment next and let you know of the
>> outcome)
>> This is hardly important for my home server scenario, but it would be, 
>> should I decide to implement a FreeBSD NIS server somewhere else.
>> Hence,  the best possible solution would be to get a Makefile for the
>> FreeBSD NIS server that would produce completely Linux compatible maps.
>>     
>
> Hmm.  What you're saying makes sense; unfortunately, I haven't had a
> network configured this way in a while, so I'm rather rusty on the
> details.  It sounds as though this is just a matter of the map names.
> Perhaps you could handle that with nicknames?
>
>   
It is a matter of names, but also there are changes internally in the
file. All can be handled by a modified Makefile, which I hope to be able
to patch
I have a few more urgent "experiments" with the test machine, so this
will have to wait for a while.
> I believe that the master.passwd.byname map is in the same FreeBSD-
> specific format as master.passwd, but that on all systems
> passwd.byname is the standard old format that YP always used.
>   
In fact, in Linux, shadow.byname is the exact same format as
/etc/shadow, so I believe your assumption about master.passwd.byname is
true.
> In most (not all, but most) cases, I don't think it's worth worrying
> about the "secure" modes available, whether you're taking the FreeBSD
> or the Linux map names and formats.  It's based on the assumption that
> someone untrusted can be on your network but can't use low-numbered
> TCP ports.  This is unusual in my experience.
>   
True, and as I said for my home network this is more of an "academic"
exercise.
However considering the (probable) outcome of the UNSECURE line in
Makefile, it would reduce the security of a host to pre-shadow days. The
hashes would be available to anyone, and then someone could discover
john the ripper and give brute force a try.  This is probably something
to keep in mind for more security-conscious environments. Combine it
with the fact it would affect all nis clients and not a single machine,
and you may get a serious security incident.
> Good luck.
> _______________________________________________
>
>   

Thanks, should I decide to "wrestle" with the Makefile, I will need it :)