NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/unix/admin/5030

Internet Message Format | 1992-09-14 | 16.5 KB

Xref: sparky comp.unix.admin:5030 comp.unix.questions:11048 comp.unix.programmer:4646
Newsgroups: comp.unix.admin,comp.unix.questions,comp.unix.programmer
Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!spool.mu.edu!sdd.hp.com!ux1.cso.uiuc.edu!m.cs.uiuc.edu!vela!wsu-cs!wsu-eng.eng.wayne.edu!upkar
From: [e-mail] (Upkar Singh Kohli)
Subject: SUMMARY: two questions
Message-ID: <[e-mail]>
Sender: [e-mail] (Usenet News)
Reply-To: [e-mail] (Upkar Singh Kohli)
Organization: Wayne State University, Detroit
Date: Mon, 14 Sep 1992 18:34:03 GMT
Lines: 380

(sorry for the late summary)

Original questions
==================

1. How do I disable echo (under UNIX) (for getting passwords)?

2. What would be the best way to uniquely identify a networked machine
   for software licensing?
-----------------

Thanks to the following for responding to my query:
(sorry if I missed anybody!)

[e-mail] (Gurvinder Singh Ahluwalia)
[e-mail] (Guy Harris)
[e-mail] (Barry A. Boes)
[e-mail] (J. Matt Landrum)
"Andrew Luebker" <[e-mail]>
[e-mail] (Phil Blanchfield)
[e-mail] (Martin Kelly)
[e-mail] (Chuck Yerkes)
evan@flatiron (Evan L. Marcus [Fusion Systems Group, Ltd.])
Tom Conroy <[e-mail]>
Moustafa Hassan <[e-mail]>
[e-mail]
Richard Elling <[e-mail]>
[e-mail] (Jim Ray)
[e-mail]  (Russ Poffenberger)
David Fetrow <[e-mail]>
Robert L Krawitz <[e-mail]>
[e-mail] (Birger A. Wathne)
Chris Siebenmann <[e-mail]>
[e-mail] (Van Hooft PJG)
Simon Coppins <[e-mail]>
[e-mail]
Per Thomsen <[e-mail]>
Mike Raffety <[e-mail]>
[e-mail] (Gordon Burditt)
kalli![e-mail] (Kevin Sheehan {Consulting Poster Child})
[e-mail] (Marc G. Frank)
Casper Dik <[e-mail]>
[e-mail] (Leon Koll)
Dave Mitchell <[e-mail]>
Tobias Weingartner <[e-mail]>
[e-mail] (Adam Shostack)
[e-mail] (Paul Hyder)
[e-mail] (Thad Phetteplace x4461)
[e-mail] (Chris Davies)
[e-mail] (Juergen Nickelsen)
[e-mail] (Miguel de Icaza A.)
[e-mail] (Thad Phetteplace x4461)


1. Answer to the first question was an overwhelming "Use getpass."
   This is sufficient except if the input is more than 8 characters
   then this fails. Some responses included other ways such as
   using "curses" and "ioctl."

2. In essence most of the responses to the second question referred
   to usage of "hostid" "ethernet address" and/or "IP address." All
   these can be faked in one way or the other... There is no standard
   solution. Some responders did not like the idea of uniquely identifying a
   machine because that is usually an overhead when a customer
   needs to switch a software license from one h/w to another.

   Floating license is the closest solution in my case, however
   that can be easily cheated too! Well, trust your users.


Unique Responses (question 1)
=============================

If it is available on your system, you shoulkd use the curses library
,
because it is the easiest and most portable way: noecho() and echo().
But if you want to read a password, you can use the getpass()
function.
--------------------

getpass(3) is one way of doing it, another one has to do with ioctl(2
)
system calls (indeed, you must mimic stty -echo).
--------------------

Check out the man page on the function getpass.  If you want to do al
l the
character IO yourself, look up the functions cbreak, nocbreack, echo,
 noecho
(these are all part of the curses screen library).  I'd be willing to
 mail
you examples if you like.


Responses (question 2)
======================

Suns running DNA (Sun's DECnet stack) acquire a different ethernet
address (one with the AA:00:04:00:XX:XX DECnet convention) which
is then used for TCP/IP communication as well.
--------------------

If the purpose is to do software licensing, the best way is to have a
network license server, rather than relying on machines having a unique
identifier.  Yes, Ethernet addresses can be changed on many machines.
Yes, host IDs can be changed on many machines, and even on some where it
can't be changed in a vanilla system, anybody sufficiently knowledgable
about the way the OS works can set their system up to return a fake host
ID.
--------------------

   Sure, the ethernet, hostid, and anything else on a sun can be
"faked" if the person trying it knows what they're doing.  If you want
to protect your software on a single user, non-networked platform,
there's not much you can do to prevent a smart individual from
circumventing the protection.
  However, if the client has networked machines, which is almost
always the case for suns, I think the best method of protection for
fixed node software is to check the machine name and internet address.
Someone could STILL get around that, but it's much more difficult, as
changing the calls that return a machines internet address or name can
cause the machine to become confused.
  There is some pretty good bundled licensing software available for
suns, lmgr, which is used by Frame, Cadence, Mentor, and several
others.  It's pretty good protection, but one disadvantage of using a
package like that is that if someone has figured out how to trick it
for one application, they can trick it for all of them.
--------------------

It is true for hostids, although you need to know
something about the kernel.  As for the most effective way...
it depends on if the software costs more for different
architecures, etc.  The most effective way for me as a user
would be by internet number so if for some reason I need to
swap a CAD and Design machine, I can easily have the software
stay in the appropriate place.
--------------------

I think the boot PROM's also have a serial number.
--------------------

Everybody seems to use the hostid. The hostid lives in a non volatile
ram thing (EEPROM?) on the motherboard. It can be changed in the running
kernel if you know where it is.
--------------------

Have you tried the command "hostid" and/or the system
call "gethostid()" ?

They both return a numeric hex identifier (same one) for the current
host. This hex number is unique across all Suns and is stored in the
PROM or NVRAM chip on the CPU board.
--------------------

With SunOS coming out on platforms without host chips,
they do not recommend relying on chip based licensing.
Call sun, they make their own policies, no mailing lists.
--------------------

Yes, Ethernet address can be easily changed.

The most common way to uniquely identify a Sun workstation is to use
hostid(1).
--------------------

Why do you want to identify the hardware? Are you not more interrested
in identifying a particular 'node' or 'host entity' or somesuch?
Actually, you probably just want to ensure that somebody does not
use a software package on more stations than they have paid for the
priveledge of using the software on.

Using hardware specific id's such as `hostid` or MAC address make it
a real pain in the patookus when you need to swap hardware due to
an upgrade or repair/replacement.

Personally, I would use the network protocol address (if unique).
In the case of IP, the IP address is certainly a unique feature
of a station on a network and could be used to lock a license to
a node. Of course, if the station is not on a network, then all bets
are off.

The floating license servers seem to work out quite well. In this
scenario, a limited number of licenses are available and any station
may 'check out' an available license.
--------------------

I hope that you get lots of objections to this post. The way to do is
through a contract. If you assume your customers are going to rip you
off, and you want to make sure that they don't ever use your software on
a non licensed machine, you are going to cause honest people a lot of
trouble. We bought exactly two such packages, and they caused quite a bit of
of hassle. And we never tried to steal anything.  I will avoid, if at all     i
possible, any cpu locked software.
--------------------

Yes.  As long end users have access to the kernel, there is nothing
they can't change.  Also, the hostid is stored in NVRAM which can
be easily reprogrammed.

hostid is still your best bet.  Or a combination of hostid/IP address.
However, your company had better have a flexible policy for when people
want to reconfigure their network.  Also, since this is a world
community, you'd need to be able to staff a phone line for reconfiguring
networks nearly 24 hours a day.

Alternatively, you may elect to go with an external box connected to the
serial port.  This is the only effect means of copy protecting still
used in the PC market.  This method is doomed for networks since you
still won't have the ability to run the program from other networked
machines.

Some sites are developing policies against buying node-locked software.
So you might consider a floating license manager such as the Highland
License manager.
--------------------

Hostid is probably your best bet.  Quite a few vendors ( software ) use the hostid
to license software.  Ethernet hardware address is not a good choice due to the
ability to change this at boot.
--------------------

The hostid is about the only way. I suppose you could access the ethernet
address in the ID prom, but that is the same place as the hostid, so it
probably doesn't matter.
--------------------

 hostid is a unique serial number built into the ROMS. There is a way around it
(of course. There always is).
--------------------

Yup (at least it was on 3/50's, and I'd be surprised if it's not
possible on later series machines).  We once did it legally, because a
certain application was node licensed and we negotiated a site license,
but the vendor hadn't fixed the licensing scheme, so they let us change
the hostid's for that purpose.

There probably is no way, in the face of determined opposition.
--------------------

hostid's are bound to the PROM. They cannot be changed (Unless the customer
is desperate enough to decode the PROM and burn new ones).

Ethernet addr. is set from the hostid. Thus all ethernet interfaces
on the same host use the same ethernet address. But it can be
changed with ifconfig ether ....

Just make shure the routines you use to read the hostid are not
dynamically linked.....

And perhaps look into using one of the commercially available license managers
on the market. Network licensing with floating licenses is the way to go.
I think Sun's SunNet License is really the Highland license manager.
--------------------

 You aren't going to like this: there isn't one. IP address(s) of the
machine are about as close as you can come (don't forget that some
machines have more than one, and some have none).
--------------------

Unfortunately, this is a field on which there is no portable solution.

Suns, for example have a fixed hostid that you can use. On other machines
you have to use the ethernetaddress. Since, as you mentioned, you can
change the effective ethernetaddress, you have to go for the default
address, that is burned in the ethernet interface itself.

But to avoid all these problems, I would like to suggest you use
a commercial licensing system, eg netls.
--------------------

Try /usr/bin/hostid.
--------------------

No software licensing method is very effective.  Why not simply
trust your users to do the right thing?
--------------------

This is a tougher one; the ethernet address (as opposed to the IP address is
not all that easy to change, and on some architectures it can't be changed without
burning a new PROM for the network board. So, depending on how secure you want to
be, you can use the ethernet address.

Another possibility is to use the serial number of the machine, if you can get
at it. I'm afraid I don't know how to get a hold of it for any architecture
(through software), but maybe the vendor will tell you.
--------------------

There's no sure-fire way ... I know how to change a hostid, though it's
rather more complicated than changing the Ethernet address (it requires
a binary patch to the kernel code, typically with adb).  Most vendors
just use the hostid anyway, though you could also possibly factor in
things like IP address, hostname, and/or Ethernet address.  The more
factors, of course, the more your customer won't like it, and the more
requests you'll get from customers for a new key, because one or the
other factor changed (e.g., new CPU board, new network, new hostname, etc.).

Many also do network broadcasts, looking for other similar licensing
daemons; if it finds one, it exits, helping ensure there aren't multiple
license daemons running on any one network.
--------------------

Use an identifier in a piece of hardware that cannot break or
malfunction.  (Unfortunately, there is no such thing.  The alternative
is not to sell to people you don't trust.)
--------------------

Kind of - you can't change the prom version of hostid, but you can
change what the kernel returns for an answer.  What I use is a combination
of the two.  It is very rare that people change the ethernet address,
and if they do it on the fly to install software, lots of things will
break.  At any rate, you can encrypt the info you stored for both,
and make sure it doesn't change...  Some packages broadcast their
info in an encrypted form so that other packages of the same flavor
can detect dups...

This is one reason that we are investigating using public key algorithms
for this instead.
--------------------

How about the IP number?
--------------------

There is no ``easy'' way to change the hostid of a Sun. But remember,
with enough time and effort, anything can be changed. Linking a new
system call in the kernel to change or set the hostid is possible.
Or using ptrace/PTRACE_SYSCALL to intercept calls to gethostid()
and return your own special value (I've written a program to do
this once). Since the software interface is all a program has access to,
there will always remain ways in which any a scheme can be subverted.

The hostid is probably your best bet, although using the IP address or
fully qualified hostname is much friendlier. If you use the IP
address, faking will be much harder. Changing is possible, but
not on the network with other hosts with the same IP address.
Since networks can be world-wide, this gives you some protection.
Also, if a host breaks down, it can easily be replaced without having
to redo the license. Same with hardware upgrade. Hostname, at least
the Fully Qualified Domainname, gives much the same protection as
IP address but has the added advantage from the perspective of the
software buyer that machines can be re-IP numbered (not an uncommon
occurrence when moving or getting internet connectivity or when switching
from multiple C nets to one B net or etc ...) without having to reacquire
a license. A license policy for important application that depends
on certain hardware that can be replaced almost immediately when it breaks,
must be accompanied with license update service with the same speed
as the hardware service to minimize effective downtime.
--------------------

offically, hostid cant be changed; in practice, it can be changed by a simple
kernel hack (ie using adb).
--------------------

Depends, how portable do you want it to be?
--------------------

If your intent is to "absolutely positively" protect software by
restricting it to a single host you are out of luck.  Although not
easy, it is possible to change the almost anything including the
hostid on any UNIX platform.  This includes one case that I saw where
a facility had all the hostid's set to the same number.  (This was long
ago but is still easily done with kernel patches.)

The best solution is to implement some type of active user license
server based process (even for a single copy!) and avoid the hostid
restriction attempt completely.  This makes happy users too, hardware
tends to move around these days and shifting licenses is truly a
pain.

Course, if you trust users or sell to a low technology user community
hostid is not a bad choice if you really gotta host restrict.
    Paul Hyder
--------------------

Can't help you here.  Vendors haven't seemed to standardized on anything yet.
I recommend you make the licensing code a tightly enclosed module that can be
customized for each hardware platform.
--------------------

There isn't one (unless you're using a VAX, in which case you can read
the CPU serial number).