Netinfo and Security
John C. Randolph
Well, here I go, starting a new thread:
I like Netinfo. Netinfo, today, must be kept *behind* a firewall.
Here are a few things that I would say netinfo needs, off the top of my
head:
1) Secure DNS support. Do a web search on the Free/SWAN project if you
need an explanation.
2) All traffic between netinfo domains should go by an encrypted tunnel.
3) Netinfo databases themselves should not be kept in the clear on disk.
4) a good hard look needs to be taken at how much of the netinfo database
should be available to users who arent' in the "staff" or "wheel" groups.
Right now, user "nobody" can do an "nidump passwd /", and then run crack
against the results.
5) Netinfo (and all other similar tools) needs a batch-renumbering
capability. Networks change, and it shouldn't be so bleeding hard to
select sixty machines on a given subnet, and tell them that they are
now in a different block.
6) Netinfo should provide public key service for users in its database. If
I want to send you mail, it would be *so* nice if my mailer looked you
up, took your key, and encrypted the message just for you.
Comments?
-jcr
al...@izzy.net
In <5lv54c$gs7$1...@ironhorse.plsys.co.uk> Matthew Seaman wrote:
> In <5lumsu$f...@idiom.com> John C. Randolph wrote:
<great ideas munched...>
To mutate the topic a bit:
NetInfo, like NIS and such, is supposed to get rid of /etc/foo.conf files,
right?
What about adding features to make it easier for standard and third party
server apps to use NetInfo to store configuration data? Like a ServerKit
that provided a good starting point for writing new, or wrapping old Server
programs. A related idea would be a ServerManager "dashboard" type program
for (local and remote) administration of Server processes. The ServerKit
might include a pallette object for the creation of a bundle for
ServerManager.
Regards,
Alan Frabutt (al...@izzy.net)
planetary
al...@izzy.net wrote:
: NetInfo, like NIS and such, is supposed to get rid of /etc/foo.conf files,
: right?
: What about adding features to make it easier for standard and third party
: server apps to use NetInfo to store configuration data? Like a ServerKit
: that provided a good starting point for writing new, or wrapping old Server
: programs. A related idea would be a ServerManager "dashboard" type program
: for (local and remote) administration of Server processes. The ServerKit
: might include a pallette object for the creation of a bundle for
: ServerManager.
I'd like to see a ServerKit support LDAP.
This would allow very nice integration of Rhapsody boxen into an NDS,
ADSI, or JNDI environment, giving you what you asked for in a
platform-independent way.
You could access defaults databases, administer user accounts, configure
DNS servers from an LDAP administrator platform.
..............kris
--
Kristopher Magnusson kr...@xmission.com (no NeXTmail, please)
---------------------------------------------------------------------------
Contains freshness saver packet. DO NOT EAT.
Matthew Seaman
Amen to that, with bells on. My two cents:
7) The trusted_networks property should work via address and mask --- at the
moment it restricts you to netmasks that fall on byte bounduaries, which is a
real pain if your ISP has issued you with a CIDR block that doesn't match
that.
8) Ditto for the networks property in /locations/snmp/communities/whatever
9) Built in shadow password support, with password aging and so forth ---
again, this needs a more selective "read permission" as in (4)
10) Support for DHCP rather than bootp as the standard mechanism for
supplying host IP numbers from a central database.
11) Support for tcp_wrappers like functionality, via say
/locations/hosts.allow, plus supplying either xinetd or tcp_wrappers
configured as standard. Also, supply V8 sendmail compiled with -DTCPWRAPPERS
and Wietse Venema's replacement portmap daemon
(ftp://ftp.win.tue.nl//pub/security/portmap_5beta.tar.gz) which adds
tcp_wrappers protection to rpc connections too.
12) A configuration option to use a tcp rather than udp based connection to
netinfo servers which are a long way away in network terms (this would
usually be between a remote master server and local clone servers): netinfo
works well between physically separated sites, but suffers if packets go
astray in much the same way that NFS does. Also, getting a well-known
netinfo port number assigned would be helpful when configuring firewalls.
Matthew
--
Matthew Seaman
P&L Systems, 12 The Broadway, Amersham, Bucks., HP7 0HP, England
Tel: +44 1494 432422 Fax: +44 1494 432478
Luke HOWARD
planetary (kr...@xmission.xmission.com) wrote:
: al...@izzy.net wrote:
: I'd like to see a ServerKit support LDAP.
: This would allow very nice integration of Rhapsody boxen into an NDS,
: ADSI, or JNDI environment, giving you what you asked for in a
: platform-independent way.
: You could access defaults databases, administer user accounts, configure
: DNS servers from an LDAP administrator platform.
There are a few issues that come out of this.
- an abstraction of common server-related functions, eg. starting and
stopping services (a la NT). The result would hopefully be reduced
development time and greater consistency between applications (thus
easing administration).
- a directory service API (a la JNDI) providing an additional layer
of abstraction above NetInfo and LDAP, such that developers would
have a consistent means for, say, looking up DO string binding
handles, or user preferences, etc...
The JNDI model is *good* (see http://www.ecr.mu.oz.au/~lhow/jndi/)
and, depending on the degree of Java integration in the OS, would
be a good candidate.
- support for LDAP in lookupd. Very doable.
-- Luke
[speaking for myself, only]
Luke HOWARD
Matthew Seaman (Matthew...@plsys.co.uk) wrote:
: > 1) Secure DNS support. Do a web search on the Free/SWAN project if you
: > need an explanation.
DNS is mostly independent of NetInfo. Including the ISC BIND would
be good, however.
: > 4) a good hard look needs to be taken at how much of the netinfo database
: > should be available to users who arent' in the "staff" or "wheel" groups.
: > Right now, user "nobody" can do an "nidump passwd /", and then run crack
: > against the results.
chmod 700 /usr/bin/ni*? In any case, users can get at this kind of stuff
with the NetInfo and/or C libraries.
: > 6) Netinfo should provide public key service for users in its database. If
: > I want to send you mail, it would be *so* nice if my mailer looked you
: > up, took your key, and encrypted the message just for you.
Any MUA writer could add support for this.
: 7) The trusted_networks property should work via address and mask --- at the
: moment it restricts you to netmasks that fall on byte bounduaries, which is a
: real pain if your ISP has issued you with a CIDR block that doesn't match
: that.
Agreed. We support this for aliases, but not trusted_networks at this
time.
endo> niutil -read -t talcum/testing /
...
alias_name: gothic
alias_addrs: 192.207.36.1&255.255.255.255 192.207.36.22&255.255.255.255
127.0.0.0&255.0.0.0
: 9) Built in shadow password support, with password aging and so forth ---
: again, this needs a more selective "read permission" as in (4)
Read access verification may impose an undesirable performance overhead.
It would be good to support it at least in lookupd for those name
services which can handle it, though (like flat files and LDAP).
: usually be between a remote master server and local clone servers): netinfo
: works well between physically separated sites, but suffers if packets go
: astray in much the same way that NFS does. Also, getting a well-known
: netinfo port number assigned would be helpful when configuring firewalls.
You can need more than one port for netinfod if you're running multiple
tags on one machines.
-- Luke
[speaking for myself only]
Hugo Burm
In article <5lumsu$f...@idiom.com> j...@idiom.com (John C. Randolph) writes:
> Well, here I go, starting a new thread:
>
> I like Netinfo. Netinfo, today, must be kept *behind* a firewall.
>
> Here are a few things that I would say netinfo needs, off the top of my
> head:
>
7) Better documentation. Can somebody summarize what docs on netinfo are
available?
Matthew Seaman
In <5m0i6r$n...@mulga.cs.mu.OZ.AU> Luke HOWARD wrote:
> Matthew Seaman (Matthew...@plsys.co.uk) wrote:
> : > 1) Secure DNS support. Do a web search on the Free/SWAN project if you
> : > need an explanation.
>
> DNS is mostly independent of NetInfo. Including the ISC BIND would
> be good, however.
Ahem. Watch the attributions please --- I didn't write points 1) to 6), John
C. Randolph <j...@idiom.com> did. Although I agree entirely that ISC BIND-8.1
or whatever is current at the time should be shipped with OpenStep/Rhapsody.
> : > 4) a good hard look needs to be taken at how much of the netinfo
database
> : > should be available to users who arent' in the "staff" or "wheel"
groups.
> : > Right now, user "nobody" can do an "nidump passwd /", and then run
crack
> : > against the results.
>
> chmod 700 /usr/bin/ni*? In any case, users can get at this kind of stuff
> with the NetInfo and/or C libraries.
Indeed. My personal favourite is
perl -e 'while (@_ = getpwent()) { print (join (":", @_), "\n"); }'
Which you will note on most normally configured NS 3.3 or OS 4.x systems
prints out all the encrypted passwords for each domain up the netinfo tree
from "." to "/". On many Unices, the system library getpwent() routine will
only return the encrypted password for the privileged user, or require the
use of a special 'getspent()' call restricted to the super-user: perl's
getpwent function simply reflects the behaviour of the system library.
> : 7) The trusted_networks property should work via address and mask --- at
the
> : moment it restricts you to netmasks that fall on byte bounduaries, which
is a
> : real pain if your ISP has issued you with a CIDR block that doesn't match
> : that.
>
> Agreed. We support this for aliases, but not trusted_networks at this
> time.
>
> endo> niutil -read -t talcum/testing /
> ...
> alias_name: gothic
> alias_addrs: 192.207.36.1&255.255.255.255 192.207.36.22&255.255.255.255
> 127.0.0.0&255.0.0.0
Now that's a new one on me, (I've still got NS 3.3 on my desktop) but like
"Wow, cool". I could have used this feature at one of our clients years
ago...
> : 9) Built in shadow password support, with password aging and so forth ---
> : again, this needs a more selective "read permission" as in (4)
>
> Read access verification may impose an undesirable performance overhead.
> It would be good to support it at least in lookupd for those name
> services which can handle it, though (like flat files and LDAP).
I can see that this feature will involve significant effort to implement ---
hey, I'm only asking for the access control mechanism of the whole netinfo
system to be completely redesigned :-) --- but ponder this: how secure is
secure enough? A few well publicised security incidents, along the lines of
the Internet Explorer debacle, could cause damage disproportionate to their
true significance.
Sun Solaris implemented shadow passwords for all of the passwd databases
natively supported (flat files, NIS and NIS+). If they can do it for their
networked database, why can't Apple/Xedoc do it for netinfo?
> : usually be between a remote master server and local clone servers):
netinfo
> : works well between physically separated sites, but suffers if packets go
> : astray in much the same way that NFS does. Also, getting a well-known
> : netinfo port number assigned would be helpful when configuring firewalls.
>
> You can need more than one port for netinfod if you're running multiple
> tags on one machines.
As I understand it, you need distinct *sockets* between the server and client
machines: all the netinfo connections could go to the same port on the server
so long as they come from distinct ports on the client, or vice versa.
Mind you, the modern approach, as seen in http daemons, bind-8.1 and so forth
is to make the port number used a configuration option, with the "well known
port" just becoming the canonical port to use. Why not have a 'tcp_port'
property in the root directory of a netinfo domain, which the master for that
domain listens for connections on?
Another point concerning the use of tcp rather than udp strikes me: wouldn't
the guarranteed packet delivery of the tcp protocol[*] make a lot of sense
when
creating clone servers and so forth --- the sort of operations that generate
the warning message about the network not being too busy in
NetInfomanager.app?
Matthew
[*] One for the Department of Redundancy Department...
Luke HOWARD
Hugo Burm (hu...@tamtam.xs4all) wrote:
: >
: > Here are a few things that I would say netinfo needs, off the top of my
: > head:
: >
: > 1, 2, 3, 4, 5, 6 ...
: 7) Better documentation. Can somebody summarize what docs on netinfo are
: available?
The Xedoc documentation, which is really quite useful IMHO is available
from http://www.xedoc.com. Documentation for NetInfo Editions 4.11
will be released soon, which implicitly includes some documentation
on NetInfo in OPENSTEP for Mach 4.2.
Starting with OPENSTEP for Mach 4.0, I believe NeXT included some
additional NetInfo documentation in /NextLibrary. There's always
the NEXTSTEP system administration manual, which is also very
good.
And, finally, Marc Majka & Alan Marcum's journal articles are
excellent. Check out http://www.next.com/NeXTanswers?NetInfo.
-- Luke
Luke HOWARD
Matthew Seaman (Matthew...@plsys.co.uk) wrote:
: In <5m0i6r$n...@mulga.cs.mu.OZ.AU> Luke HOWARD wrote:
: > Matthew Seaman (Matthew...@plsys.co.uk) wrote:
: Ahem. Watch the attributions please --- I didn't write points 1) to 6), John
: C. Randolph <j...@idiom.com> did. Although I agree entirely that ISC BIND-8.1
: or whatever is current at the time should be shipped with OpenStep/Rhapsody.
Apologies.
: from "." to "/". On many Unices, the system library getpwent() routine will
: only return the encrypted password for the privileged user, or require the
: use of a special 'getspent()' call restricted to the super-user: perl's
: getpwent function simply reflects the behaviour of the system library.
This is true. It should be possible to implement getspent() under Rhapsody,
as long as whether the user is "priveleged" can be determined over Mach IPC.
: Now that's a new one on me, (I've still got NS 3.3 on my desktop) but like
: "Wow, cool". I could have used this feature at one of our clients years
: ago...
Yep, it's real useful on multihomed hosts (which NEXTSTEP and OPENSTEP
for Mach currently do not support, but I'd expect Rhapsody to support).
From the 4.2 Release Notes:
This release of OPENSTEP incorporates a number of enhancements to NetInfo.
These enhancements have already been made available to users of previous
OPENSTEP and NEXTSTEP releases in the form of a patch. The following
document was shipped along with that patch.
Modifications to NetInfo
from 3.3Patch (58.4) to TS2 (58.4.8483.5)
...
: I can see that this feature will involve significant effort to implement ---
: hey, I'm only asking for the access control mechanism of the whole netinfo
: system to be completely redesigned :-) --- but ponder this: how secure is
: secure enough? A few well publicised security incidents, along the lines of
: the Internet Explorer debacle, could cause damage disproportionate to their
Agreed. The fact that Rhapsody will receive significant use and exposure may
prompt Apple to fix these things.
: Sun Solaris implemented shadow passwords for all of the passwd databases
: natively supported (flat files, NIS and NIS+). If they can do it for their
: networked database, why can't Apple/Xedoc do it for netinfo?
There are few technical reason why it couldn't be implemented, but -- as
you're no doubt well aware -- technical reasons alone do not a product
decision make.
: As I understand it, you need distinct *sockets* between the server and client
: machines: all the netinfo connections could go to the same port on the server
: so long as they come from distinct ports on the client, or vice versa.
But there may be multiple *servers* (instances of netinfod) on one machine.
nibindd returns a (tag, port) tuple to the client which contacts the
appropriate netinfod itself.
: is to make the port number used a configuration option, with the "well known
: port" just becoming the canonical port to use. Why not have a 'tcp_port'
: property in the root directory of a netinfo domain, which the master for that
: domain listens for connections on?
Yes, having it configurable (instead of randomly assignable) would at least
make deterministic firewall configuration possible. ;-)
: Matthew Seaman
: P&L Systems, 12 The Broadway, Amersham, Bucks., HP7 0HP, England
Not too far from NeXT? (I would have visited you in Feb...)
-- Luke