Don't forget the IBM/SuSE tie in, that brings z-series, i-series and x-series processors. Novell already has eDirectory running on AIX machines (see here). And since it runs on both AIX and Solaris 64-bit machines, the 64-bit jump shouldn't be hard to x86-64, at least. And the Nsure Audit platform agents list on page 21, here includes Linux for IBM S/390 (zSeries). Take the hint!
Because it lacks the corporate hype that Red Hat, et al, gave to Linux.
What I'm trying to figure out is, "What's important? The kernel or the glibc?"
Apps written to glibc will run on GNU/HURD, Linux, Lava, and other kernels, too. Technically, that's a better story. But business wise, the brand in people's mind is "Linux".
The EAL2+ assurance level achieved is NOT the highest rating possible by a long, long shot - it's actually close to the lowest. But, it's a great start.
IBM and SuSE say they're working on a higher level CAPP evaluation, which roughly equates to the old C2 TCSEC criteria.
What I found more interesting than the 2008 date is the purchasing guideline that products purchased need to be IPv6 capable/compliant after October this year.
That doesn't just apply to IP device drivers, but implies that any application that deals with IP addresses, including any networked app, needs to "grok" IPv6 addresses, have expanded buffers for longer addresses, etc.
It means that the infrastructure, from DHCP to DNS to SMTP to syslog and Apache all need to be IPv6 ready in order to make it to the approved products list.
There are still a lot of products out there that don't or can't do that.
Additionally, SCO's unwitting publishing of Linux code does not relieve the fact that they gave their own stuff away.
This, I think, gets to the heart of the danger to the open source community - claims that "a thousand eyes are better/more secure/keep you safe from misappropriated code" only works if any one is looking at the code.
Such a supposition, if untested, unrequired, undocumented, is infinitely worse than security by obscurity or "statistically unlikely event", because it lulls the lazy into thinking (wishing?) someone else is doing their job for them.
When was the last time YOU reviewed the source to your glibc library? gzip? getuid()? Muchless sprintf(), scanf(), or putc()? gcc? ls?
The danger is that Linux may, in fact, be the "Heathkit" of computing software, in a world where "Sony Walkman" is what customers want. Steve Jobs (and Alan Kay, et al) are right - until computers are appliances, they'll just be niche products only useful to those who understand how to make them kind of work.
Heathkit and Sony Walkman are likely the trademarks of their respective owners, if indeed they're trademarked.
SCO Call is Closed - At Least to Novell Employees
on
Today's SCO News
·
· Score: 5, Informative
I tried dialing in - I'm a Novell employee and told the operator that - and they said SCO had asked that Novell employees not be added to the call.
Hrmmph.
You'd think they'd at least let us listen to them talking about us!
...but ISA and PCI are (relatively) simple interfaces for commodity markets. We've not yet reached that point in Software where ANYTHING is commodity and reusable, unless GNU and Linux lead us that direction.
The software standards that work (even if they're insecure) are protocols that were created initially by small teams, and then documented over time by recording concensus. Like IPv4, DNS, HTTP, etc. It's in their follow efforts that design by committee has taken them over, like IPv6, IPSEC/IKE, DNSSec, etc.
The sad truth is that technology uptake follows three repeating phases:
1) do something useful 2) use it to enable unrestricted sharing 3) try to figure out how to limit sharing
Standards groups have gotten incredibly political. It's unseemly.
But when you get down to it...the Common Law is just an excersize in Open Source design by committee, and see how successful it is!
Controlling how others may use or refer to you or your information is tough. It's a major problem with access controll lists - how do you KEEP someone from adding your name to a mail distribution list, ala SPAM, for instance?
SPAM is just an anauthorized link (email referance) to your email account. I'd sure like to be able to restrict those links, and have registered in several "do not call" lists to inhibit telemarketers from calling my home phone.
That's a Digital Rights Management issue - how do I CONSTRAIN what others may do with information I publish (my email address, my web links, etc.)
I wonder, too, if one of the reasons for the do-not-link policies is to fullfill the obligation of affirmative enforcement required of trade mark / service mark holders?
I think I'm saying that GPL DOES choose one business over another, whereas BSD does NOT. That's why I think BSD is closer to "the people's" license than GPL, which is more restrictive, and is designed to be antithetical to an economic business model rejected by its authors.
You're not far wrong - each of those licenses, commercial and GPL, have serious contaminating characteristics.
It's the choice of the developer to impose those restrictions or not.
It should be choice of the consumer (either end- or intermediary) whether they accept those restrictions or not.
That's why Government financed development should be available WITHOUT contamination - via something like the BSD license, with fair attribution for the source of a derivative or integrating use.
I think I agree with you - MS is certainly willing to pay for IP. And they'd like to use "free" IP when it's good (so would we all). The BSD license lets them/us do that without imposing political economic decisions on us.
Government sponsored IP should be free, in the BSD sense, and not incumbered in the GPL sense.
Digital Rights Management is about exercising control over what is legitimately yours. If people don't like what the law says is yours to control, they should change the law. And there is such a movement, of which Lessig's efforts are a part (term of protection).
What the real issue is about is putting limits on "fair use". And deciding who may decide what's "fair".
So, technology has created new issues and opportunities that stretch conventional interpretation of "fair use". The law is an open source project, and we've yet to reach rough concensus on this issue.
But please, don't kill DRM because it protects the fat cats - rather, promote it so as to protect "fair use" and preserve a reasonable expectation of privacy!
The EFF and fair use advocates need to mount their own concerted effort to use technology to protect our rights. To simply attack tools is Luddite.
If DRM is outlawed, only outlaws will have protection for their anonymity and free exchange of ideas.
Advocate privacy as a DRM-enabled right!
Yeah, but Novell doesn't host eDirectory (NDS) on a relational db - but rather our hierarchical flaim db (proprietary yada yada yada). The relational is there for developers and departmental computing. And with the whole eDirectory environment available on Linux, Solaris, Windows, as well as on NetWare, you can integrate your Oracle stuff with it quite nicely.
This is written about a game, but everything
it says reflects the current state of Internet
eCommerce, except that the cards used (credit cards) have liability limits imposed by legislation, and these card games are (effectively) privately minted money.
So, it's not enough to have multiple factor authentication (pin + fingerprint, for instance), it's also important to make sure EACH of the factors is hard to steal, or at least one of them is.
That means authentication is not just about "what you know, what you are, and what you have", it's also about what others don't (or can't) have. A higher bar.
This is a great example of the 'net acting
like a biological organism...routing around
censorship, and developing its own defensive
mechanisms against unwanted intruders.
The image of the Internet community as a
giant "blob", slowly flowing over, bypassing,
and eventually making irrelevant the obstacles
created by others reminds me, too, of a
volcano - locally powerful, representative of tremendous potential.
No - just use the LDAP PAM module on UNIX and Linux and possibly Windows (if you don't want to use Novell's Client32 stack on your NT servers - Microsoft doesn't have an IP-only Novell client).
And eDirectory is totally IP, including the directory-to-directory synchronization and management protocols (not LDAP, but IP).
Back in the days when I first began using email on UNIX, I realized that
1) far too many people had root access to the email servers;
2) far too many people could put sniffers/tcpdump on the ethernet; and
3) far too much mail transited through university campuses (Rutgers Univ comes to mind)
We came to realize, and to advise our management, that email was public speech.
Anything you said was subject to being overheard and repeated. That applies to recipients who forward mail, too.
The same eventually was realized about voice mail.
Encryption (usually) doesn't control recipients storing and forwarding your messages.
DRM has to rely on private key protection, which is what the obfuscation is about. Why?
The DRM software has to be uniquely tied to an individual so that
a) the individual can be made accoutable for their actions, both permitted and disallowed, and
b) the individual cannot repudiate their actions later
It's about bill-back, far more than it is about preventing redistribution.
If content authors can be guaranteed of being paid every time something is played, of course they'll want it distributed by anyone and everyone - Napster go wild!
But if they only get paid iff they control its distribution, that's what they'll do to get paid.
Finally, the obfuscation has to assist "trusted applications" that are certified not to save things for people not permitted to save them, or print them if not permitted, etc.
SELinux is valuable because it provides insight to the open source community about how serious security policies can be constructed and executed with operating system help.
There are two areas (at least) that are worth some concern:
1) writing the security policy for a service or process in SELinux basically requires you to have a complete understanding of what its going to do, so you can grant the LEAST PRIVILAGE needed to the service that will allow it to work correctly, and to fail safely in the event that its hacked - and now in addition to your program bugs you need to worry about the bugs in your security policy! Much help is needed to make managing and selecting security policies "reasonable" for day-to-day system admins, and even more for developer-admins (who have a tendency to try to cheat);
2) concern about backdoors in the kernel are amusing - certainly one could look for them (but who really does), but people should be far more worried about the backdoors being introduced into network interface cards, motherboards, disk controllers and video graphics cards - all being manufactured "over seas" these days...if you seriously wanted to engage in cyberwarfare with the US, wouldn't you be putting "gifts" into BIOS circuits that could be triggered remotely? Or how about the "WakeOnLan" control logic of your NIC cards?
Security is a function of the system, including hardware, software, firmware and operational procedures (backup and password policies, etc). It's foolish to wish for "security" from any single (uncertified) piece of the puzzle.
But - I WOULD like to be able to use SELinux as the basis for my own firewalls, web and DNS servers, smtp relays, etc. Not life threatening stuff, but things I need to make "more secure" from l10n style attacks. To do that, we need a rich library of pre-defined security policies for common services (bind 9.1, smtp 8.x, apache, etc) and to be sure the POLICIES are peer reviewed by the community.
Slashdot Mirror
Don't forget the IBM/SuSE tie in, that brings z-series, i-series and x-series processors. Novell already has eDirectory running on AIX machines (see here). And since it runs on both AIX and Solaris 64-bit machines, the 64-bit jump shouldn't be hard to x86-64, at least. And the Nsure Audit platform agents list on page 21, here includes Linux for IBM S/390 (zSeries). Take the hint!
Because it lacks the corporate hype that Red Hat, et al, gave to Linux.
What I'm trying to figure out is, "What's important? The kernel or the glibc?"
Apps written to glibc will run on GNU/HURD, Linux, Lava, and other kernels, too. Technically, that's a better story. But business wise, the brand in people's mind is "Linux".
The EAL2+ assurance level achieved is NOT the highest rating possible by a long, long shot - it's actually close to the lowest. But, it's a great start.
IBM and SuSE say they're working on a higher level CAPP evaluation, which roughly equates to the old C2 TCSEC criteria.
Come to think of it, so will netcat, nmap, etc. if they're not already.
What I found more interesting than the 2008 date is the purchasing guideline that products purchased need to be IPv6 capable/compliant after October this year.
That doesn't just apply to IP device drivers, but implies that any application that deals with IP addresses, including any networked app, needs to "grok" IPv6 addresses, have expanded buffers for longer addresses, etc.
It means that the infrastructure, from DHCP to DNS to SMTP to syslog and Apache all need to be IPv6 ready in order to make it to the approved products list.
There are still a lot of products out there that don't or can't do that.
Additionally, SCO's unwitting publishing of Linux code does not relieve the fact that they gave their own stuff away.
This, I think, gets to the heart of the danger to the open source community - claims that "a thousand eyes are better/more secure/keep you safe from misappropriated code" only works if any one is looking at the code.
Such a supposition, if untested, unrequired, undocumented, is infinitely worse than security by obscurity or "statistically unlikely event", because it lulls the lazy into thinking (wishing?) someone else is doing their job for them.
When was the last time YOU reviewed the source to your glibc library? gzip? getuid()? Muchless sprintf(), scanf(), or putc()? gcc? ls?
The danger is that Linux may, in fact, be the "Heathkit" of computing software, in a world where "Sony Walkman" is what customers want. Steve Jobs (and Alan Kay, et al) are right - until computers are appliances, they'll just be niche products only useful to those who understand how to make them kind of work.
Heathkit and Sony Walkman are likely the trademarks of their respective owners, if indeed they're trademarked.
I tried dialing in - I'm a Novell employee and told the operator that - and they said SCO had asked that Novell employees not be added to the call.
Hrmmph.
You'd think they'd at least let us listen to them talking about us!
...but ISA and PCI are (relatively) simple interfaces for commodity markets. We've not yet reached that point in Software where ANYTHING is commodity and reusable, unless GNU and Linux lead us that direction.
The software standards that work (even if they're insecure) are protocols that were created initially by small teams, and then documented over time by recording concensus. Like IPv4, DNS, HTTP, etc. It's in their follow efforts that design by committee has taken them over, like IPv6, IPSEC/IKE, DNSSec, etc.
The sad truth is that technology uptake follows three repeating phases:
1) do something useful
2) use it to enable unrestricted sharing
3) try to figure out how to limit sharing
Standards groups have gotten incredibly political. It's unseemly.
But when you get down to it...the Common Law is just an excersize in Open Source design by committee, and see how successful it is!
Controlling how others may use or refer to you or your information is tough. It's a major problem with access controll lists - how do you KEEP someone from adding your name to a mail distribution list, ala SPAM, for instance?
SPAM is just an anauthorized link (email referance) to your email account. I'd sure like to be able to restrict those links, and have registered in several "do not call" lists to inhibit telemarketers from calling my home phone.
That's a Digital Rights Management issue - how do I CONSTRAIN what others may do with information I publish (my email address, my web links, etc.)
I wonder, too, if one of the reasons for the do-not-link policies is to fullfill the obligation of affirmative enforcement required of trade mark / service mark holders?
I think I'm saying that GPL DOES choose one business over another, whereas BSD does NOT. That's why I think BSD is closer to "the people's" license than GPL, which is more restrictive, and is designed to be antithetical to an economic business model rejected by its authors.
You're not far wrong - each of those licenses, commercial and GPL, have serious contaminating characteristics.
It's the choice of the developer to impose those restrictions or not.
It should be choice of the consumer (either end- or intermediary) whether they accept those restrictions or not.
That's why Government financed development should be available WITHOUT contamination - via something like the BSD license, with fair attribution for the source of a derivative or integrating use.
I think I agree with you - MS is certainly willing to pay for IP. And they'd like to use "free" IP when it's good (so would we all). The BSD license lets them/us do that without imposing political economic decisions on us.
Government sponsored IP should be free, in the BSD sense, and not incumbered in the GPL sense.
Digital Rights Management is about exercising control over what is legitimately yours. If people don't like what the law says is yours to control, they should change the law. And there is such a movement, of which Lessig's efforts are a part (term of protection). What the real issue is about is putting limits on "fair use". And deciding who may decide what's "fair". So, technology has created new issues and opportunities that stretch conventional interpretation of "fair use". The law is an open source project, and we've yet to reach rough concensus on this issue. But please, don't kill DRM because it protects the fat cats - rather, promote it so as to protect "fair use" and preserve a reasonable expectation of privacy! The EFF and fair use advocates need to mount their own concerted effort to use technology to protect our rights. To simply attack tools is Luddite. If DRM is outlawed, only outlaws will have protection for their anonymity and free exchange of ideas. Advocate privacy as a DRM-enabled right!
Yeah, but Novell doesn't host eDirectory (NDS) on a relational db - but rather our hierarchical flaim db (proprietary yada yada yada). The relational is there for developers and departmental computing. And with the whole eDirectory environment available on Linux, Solaris, Windows, as well as on NetWare, you can integrate your Oracle stuff with it quite nicely.
This is written about a game, but everything it says reflects the current state of Internet eCommerce, except that the cards used (credit cards) have liability limits imposed by legislation, and these card games are (effectively) privately minted money.
So, it's not enough to have multiple factor authentication (pin + fingerprint, for instance), it's also important to make sure EACH of the factors is hard to steal, or at least one of them is.
That means authentication is not just about "what you know, what you are, and what you have", it's also about what others don't (or can't) have. A higher bar.
This is a great example of the 'net acting like a biological organism...routing around censorship, and developing its own defensive mechanisms against unwanted intruders. The image of the Internet community as a giant "blob", slowly flowing over, bypassing, and eventually making irrelevant the obstacles created by others reminds me, too, of a volcano - locally powerful, representative of tremendous potential.
No - just use the LDAP PAM module on UNIX and Linux and possibly Windows (if you don't want to use Novell's Client32 stack on your NT servers - Microsoft doesn't have an IP-only Novell client). And eDirectory is totally IP, including the directory-to-directory synchronization and management protocols (not LDAP, but IP).
Back in the days when I first began using email on UNIX, I realized that
1) far too many people had root access to the email servers;
2) far too many people could put sniffers/tcpdump on the ethernet; and
3) far too much mail transited through university campuses (Rutgers Univ comes to mind)
We came to realize, and to advise our management, that email was public speech.
Anything you said was subject to being overheard and repeated. That applies to recipients who forward mail, too.
The same eventually was realized about voice mail.
Encryption (usually) doesn't control recipients storing and forwarding your messages.
DRM has to rely on private key protection, which is what the obfuscation is about. Why? The DRM software has to be uniquely tied to an individual so that a) the individual can be made accoutable for their actions, both permitted and disallowed, and b) the individual cannot repudiate their actions later It's about bill-back, far more than it is about preventing redistribution. If content authors can be guaranteed of being paid every time something is played, of course they'll want it distributed by anyone and everyone - Napster go wild! But if they only get paid iff they control its distribution, that's what they'll do to get paid. Finally, the obfuscation has to assist "trusted applications" that are certified not to save things for people not permitted to save them, or print them if not permitted, etc.
Right - so now, anyone have any questions about
what the processor ID for the Pentium III
was for?
There are two areas (at least) that are worth some concern:
Security is a function of the system, including hardware, software, firmware and operational procedures (backup and password policies, etc). It's foolish to wish for "security" from any single (uncertified) piece of the puzzle.
But - I WOULD like to be able to use SELinux as the basis for my own firewalls, web and DNS servers, smtp relays, etc. Not life threatening stuff, but things I need to make "more secure" from l10n style attacks. To do that, we need a rich library of pre-defined security policies for common services (bind 9.1, smtp 8.x, apache, etc) and to be sure the POLICIES are peer reviewed by the community.