Re: NIS interoperability with Linux, was Re: Following directions doesn't seem to work: Adding users in NIS
Lowell Gilbert wrote: > Manolis Kiagias <[EMAIL PROTECTED]> 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: >> >> [EMAIL PROTECTED]:~$ 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: >> [EMAIL PROTECTED]:~$ ypcat shadow.byname >> No such map shadow.byname. Reason: No such map in server's domain >> >> As root, however: >> [EMAIL PROTECTED]:~# ypcat shadow.byname >> user1:$1$1233245435435345543545345sfsdfsfdf:13577:0:9: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 :) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NIS interoperability with Linux, was Re: Following directions doesn't seem to work: Adding users in NIS
Manolis Kiagias <[EMAIL PROTECTED]> writes: > Lowell Gilbert wrote: >> Manolis Kiagias <[EMAIL PROTECTED]> writes: >> >> >>> I've read this the first time I tried and decided not to go with it. >>> The manual says: >>> "If you plan to use a FreeBSD system to serve non-FreeBSD >>> clients that have no support for password shadowing (which is >>> most of them), you will have to disable the password shadowing >>> entirely by uncommenting the UNSECURE=True entry in >>> /var/yp/Makefile." >>> >>> Linux certainly uses password shadowing, and I can see in my debian >>> server maps passwd.byname and shadow.byname files >>> If I perform ypcat passwd.byname from a client I get the standard passwd >>> file with no passwords (exactly like /etc/passwd) >>> The encrypted passwords are in the shadow.byname map. >>> >>> Now, if I understand correctly, the above solution would put the >>> passwords in the passwd.byname map, thus making the system less secure, >>> where in fact I should be able to make FreeBSD export a shadow.byname >>> map that would be compatible with Linux. >>> Am I missing something here / are my assumptions wrong? >>> >> >> I think you are assuming that Linux uses password shadowing over NIS. >> This is not possible, and no system does it. >> >> The FreeBSD security method in question just forces requests for the >> password maps to come from privileged ports. This is a very minor >> security method, and other systems don't support it. >> >> Fundamentally, NIS assumes that you trust the machines you are >> serving. Or at least are willing to let them have the encrypted >> passwords. No OS can change this; it's not a Linux/FreeBSD issue. >> >> >> > 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: > > [EMAIL PROTECTED]:~$ 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: > [EMAIL PROTECTED]:~$ ypcat shadow.byname > No such map shadow.byname. Reason: No such map in server's domain > > As root, however: > [EMAIL PROTECTED]:~# ypcat shadow.byname > user1:$1$1233245435435345543545345sfsdfsfdf:13577:0:9: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? 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 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. Good luck. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NIS interoperability with Linux, was Re: Following directions doesn't seem to work: Adding users in NIS
Lowell Gilbert wrote: > Manolis Kiagias <[EMAIL PROTECTED]> writes: > > >> I've read this the first time I tried and decided not to go with it. >> The manual says: >> "If you plan to use a FreeBSD system to serve non-FreeBSD >> clients that have no support for password shadowing (which is >> most of them), you will have to disable the password shadowing >> entirely by uncommenting the UNSECURE=True entry in >> /var/yp/Makefile." >> >> Linux certainly uses password shadowing, and I can see in my debian >> server maps passwd.byname and shadow.byname files >> If I perform ypcat passwd.byname from a client I get the standard passwd >> file with no passwords (exactly like /etc/passwd) >> The encrypted passwords are in the shadow.byname map. >> >> Now, if I understand correctly, the above solution would put the >> passwords in the passwd.byname map, thus making the system less secure, >> where in fact I should be able to make FreeBSD export a shadow.byname >> map that would be compatible with Linux. >> Am I missing something here / are my assumptions wrong? >> > > I think you are assuming that Linux uses password shadowing over NIS. > This is not possible, and no system does it. > > The FreeBSD security method in question just forces requests for the > password maps to come from privileged ports. This is a very minor > security method, and other systems don't support it. > > Fundamentally, NIS assumes that you trust the machines you are > serving. Or at least are willing to let them have the encrypted > passwords. No OS can change this; it's not a Linux/FreeBSD issue. > > > 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: [EMAIL PROTECTED]:~$ 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: [EMAIL PROTECTED]:~$ ypcat shadow.byname No such map shadow.byname. Reason: No such map in server's domain As root, however: [EMAIL PROTECTED]:~# ypcat shadow.byname user1:$1$1233245435435345543545345sfsdfsfdf:13577:0:9: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. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NIS interoperability with Linux, was Re: Following directions doesn't seem to work: Adding users in NIS
Manolis Kiagias <[EMAIL PROTECTED]> writes: > I've read this the first time I tried and decided not to go with it. > The manual says: > "If you plan to use a FreeBSD system to serve non-FreeBSD > clients that have no support for password shadowing (which is > most of them), you will have to disable the password shadowing > entirely by uncommenting the UNSECURE=True entry in > /var/yp/Makefile." > > Linux certainly uses password shadowing, and I can see in my debian > server maps passwd.byname and shadow.byname files > If I perform ypcat passwd.byname from a client I get the standard passwd > file with no passwords (exactly like /etc/passwd) > The encrypted passwords are in the shadow.byname map. > > Now, if I understand correctly, the above solution would put the > passwords in the passwd.byname map, thus making the system less secure, > where in fact I should be able to make FreeBSD export a shadow.byname > map that would be compatible with Linux. > Am I missing something here / are my assumptions wrong? I think you are assuming that Linux uses password shadowing over NIS. This is not possible, and no system does it. The FreeBSD security method in question just forces requests for the password maps to come from privileged ports. This is a very minor security method, and other systems don't support it. Fundamentally, NIS assumes that you trust the machines you are serving. Or at least are willing to let them have the encrypted passwords. No OS can change this; it's not a Linux/FreeBSD issue. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NIS interoperability with Linux, was Re: Following directions doesn't seem to work: Adding users in NIS
Lowell Gilbert wrote: > Manolis Kiagias <[EMAIL PROTECTED]> writes: > > >> Olivier Nicole wrote: >> Linux doesn't normally use master.passwd. If I recall correctly, it uses /etc/shadow instead (but I don't have such a box at hand right now to check). And yes, the internal format is different (and, again, I don't remember details). >>> If I am not wrong, NIS does not know anything about master.passwd or >>> shadow, it has only passwd.byname passwd.byuid as password maps, both >>> maps including password in them. >>> >>> Olivier >>> > > >> You are probably right, I don't remember the exact files right now, the >> thing is the maps are not linux compatible, so if anyone has a NIS >> Makefile for this, I'd be glad to get a copy. I already tried a patch I >> found but was not successful. >> > > Don't patch anything. Just edit /var/yp/Makefile to remove the > comment character from the UNSECURE line, rebuild, and you're done. > > This is fully explained inline in that file, as well as in the manual > for ypserv(8). > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > > I've read this the first time I tried and decided not to go with it. The manual says: "If you plan to use a FreeBSD system to serve non-FreeBSD clients that have no support for password shadowing (which is most of them), you will have to disable the password shadowing entirely by uncommenting the UNSECURE=True entry in /var/yp/Makefile." Linux certainly uses password shadowing, and I can see in my debian server maps passwd.byname and shadow.byname files If I perform ypcat passwd.byname from a client I get the standard passwd file with no passwords (exactly like /etc/passwd) The encrypted passwords are in the shadow.byname map. Now, if I understand correctly, the above solution would put the passwords in the passwd.byname map, thus making the system less secure, where in fact I should be able to make FreeBSD export a shadow.byname map that would be compatible with Linux. Am I missing something here / are my assumptions wrong? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NIS interoperability with Linux, was Re: Following directions doesn't seem to work: Adding users in NIS
Manolis Kiagias <[EMAIL PROTECTED]> writes: > Olivier Nicole wrote: >>> Linux doesn't normally use master.passwd. If I recall correctly, it >>> uses /etc/shadow instead (but I don't have such a box at hand right now >>> to check). And yes, the internal format is different (and, again, I don't >>> remember details). >>> >> >> If I am not wrong, NIS does not know anything about master.passwd or >> shadow, it has only passwd.byname passwd.byuid as password maps, both >> maps including password in them. >> >> Olivier > You are probably right, I don't remember the exact files right now, the > thing is the maps are not linux compatible, so if anyone has a NIS > Makefile for this, I'd be glad to get a copy. I already tried a patch I > found but was not successful. Don't patch anything. Just edit /var/yp/Makefile to remove the comment character from the UNSECURE line, rebuild, and you're done. This is fully explained inline in that file, as well as in the manual for ypserv(8). ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NIS interoperability with Linux, was Re: Following directions doesn't seem to work: Adding users in NIS
Olivier Nicole wrote: >> Linux doesn't normally use master.passwd. If I recall correctly, it >> uses /etc/shadow instead (but I don't have such a box at hand right now >> to check). And yes, the internal format is different (and, again, I don't >> remember details). >> > > If I am not wrong, NIS does not know anything about master.passwd or > shadow, it has only passwd.byname passwd.byuid as password maps, both > maps including password in them. > > Olivier > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > > You are probably right, I don't remember the exact files right now, the thing is the maps are not linux compatible, so if anyone has a NIS Makefile for this, I'd be glad to get a copy. I already tried a patch I found but was not successful. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NIS interoperability with Linux, was Re: Following directions doesn't seem to work: Adding users in NIS
> Linux doesn't normally use master.passwd. If I recall correctly, it > uses /etc/shadow instead (but I don't have such a box at hand right now > to check). And yes, the internal format is different (and, again, I don't > remember details). If I am not wrong, NIS does not know anything about master.passwd or shadow, it has only passwd.byname passwd.byuid as password maps, both maps including password in them. Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"