Vulnerability Development mailing list archives
Re: spoofing the ethernet address (license managers)
From: Michael.Wojcik () MERANT COM (Michael Wojcik)
Date: Wed, 29 Mar 2000 09:13:46 -0800
From: Eric Sherrill [mailto:sherrill () ti com] Sent: Wednesday, March 29, 2000 10:19 AM I disagree with the assessment that it only helps honest people stay
honest,
in large part because tying license managers to supposedly "unique" information like MAC addresses, can become a real pain for the sysadmin.
Administrative problems with licensing have nothing to do with whether licensing is only effective for honest customers. If licensing interferes with administration, how does that make it harder to crack? This is a different issue entirely.
Here are some examples.
Yes, yes, all of these have been debated ad nauseum in the forums I mentioned (comp.security.unix, etc.). We can, and do, issue temporary emergency licenses with a built-in expiration date. That's been enough for our customers so far; no one's ever refused to purchase the product because of licensing, and many customers have bought it because licensing enabled them to pay for just what they needed. It's a trade-off, and the market so far has justified it.
2. I lose my license server.
This has nothing to do with using MACs (or any other OS-provided system identification; we just call whatever API the OS offers - I don't care if, as on Unixware, it's just whatever's in a special file in /etc). It's a matter of a poorly designed client/server licensing mechanism. The last time I looked at FlexLM, though, it allowed backup servers. (Our licensing is all node-locked, so this is a moot point for me.)
4. I want to install a new machine, say solely for some temporary purpose, such as troubleshooting a problem. Now I either have to have a spare license available on the license server, or I have to send information to the vendor and wait for them to issue an updated license file. This can involve anything from a simple e-mail or two, to layers of corporate purchasing red tape (and weeks of waiting).
I want to drive a new car, say solely for some temporary purpose, such as replacing mine while it's in the shop. Now I have to fill out a bunch of paperwork and pay some money.
5. Most license managers I have worked with are only "network-aware" in
the
minimal sense that they seem to work in only a limited client-server paradigm - one server, many clients. What would be more helpful: a license manager that can discover and report (to the admin, not
the
vendor) on authorized and unauthorized copies of licensed software running anywhere on your network (although this type of port-scan might also raise some network managers' eyebrows);
And it's trivial to defeat, and again it only works if the customers are honest. Hell, we have license auditing capability built into our stuff. It logs license-related events to a local file in a known location, and the system administrator can do anything they want with it. It's off by default and has to be enabled by the system administrator. I've never known anyone to use it.
that can implement a shared pool of licenses among more than one
"server"
machine (this would also help with 3. above);
When there's sufficient demand in the market for a feature like this, it'll be developed.
that can automatically issue a limited number of "exceptions" within certain boundaries to help with variable peak loads (say you go over by
one
or two seats for a few days on your quota, no problem; if you consistently abuse it, however, the vendor is notified).
People who want a margin for excessive use can pay for it. Oh, I see your point. There's an arguable value difference between licenses you use all the time and licenses you only use in exceptional circumstances, and it's possible that part of that value could be reclaimed by the customer. There's no reason for the vendor to do that, however, unless they also get part of that value, in the form of increased sales, for example. And I haven't seen any evidence that the market will sufficiently reward the vendor for providing such a feature. Particularly considering the difficulties of design and implementation and the ample opportunities for abuse. (It might be implemented as "ablative" licenses, for example: you have a pool of reusable licenses, and a pool of single-use licenses that only get consumed when all the reusables are in use. But that requires persistent storage of the count of remaining single-use licenses, which is going to be vulnerable to attack. Rollback is particularly likely: I snapshot the entire license server just after installation, and restore it every time I use up my single-use licenses.) Yes, software licensing has problems, and it poses difficulties for the system administrator. On the other hand, it offers a more flexible pricing model and allows the vendor to retain a larger portion of due profit, which funds maintenance and additional development. If you don't feel you're paying for maintenance and additional development, why are you buying the product in the first place? Use something open-sourced, or write your own. Purchasing software is always a matter of the efficient application of resources. Customers who decide the penalties of software licensing outweigh the combined benefits of licensing and of having that particular software package at all apply their resources elsewhere. That's how the market works. And the market can change. The weight of opinion shifted against copy protection for personal computer software. It may shift against software licensing. Years ago I advocated dropping licensing for the base product and making it Open Source, with an API for plugging in additional features, then selling the features - some at flat rate, and some with usage-based licensing. Flexibility is what's important. Michael Wojcik michael.wojcik () merant com MERANT Department of English, Miami University
Current thread:
- TCP Sequence Prediction, (continued)
- TCP Sequence Prediction Dean Michael Dorman (Mar 29)
- Re: TCP Sequence Prediction H D Moore (Mar 29)
- Re: TCP Sequence Prediction Seth R Arnold (Mar 29)
- Re: TCP Sequence Prediction Vladimir Dubrovin (Mar 30)
- Re: TCP Sequence Prediction Maxime Rousseau (Mar 30)
- Re: TCP Sequence Prediction Paul Taylor (Mar 30)
- TCP Sequence Prediction Dean Michael Dorman (Mar 29)
- Re: Explorer crashes when it sees this .lnk file AnorEXia (Mar 30)
- Re: Explorer crashes when it sees this .lnk file Vladimir Dubrovin (Mar 30)
- Re: Explorer crashes when it sees this .lnk file AnorEXia (Mar 31)
- Exposures in MQ and CORBA Adam.Levine () BANKOFAMERICA COM (Mar 31)