No, it was the GPL patch folk. If you look through the old news, you'll see the announcement that they lost their sponsor. They later announced - I think on LWN - that they were indeed stopping all work. Well, obviously they got the money they needed so fortunately I'm wrong in thinking that this had continued into the present day. Nonetheless, for a while they were zombified.
In theory, there are exceptions. In practice, you're so close to 100% right that I'd need extended floats to find the exceptions.
By the time you get into the Bs and As, which is where MAC gets involved, MAC is considered to encompass ALL communications, ALL memory management as well as ALL program access, except where otherwise noted. (Orange Book doesn't cover all the uses of MAC, so the Orange Book definitions alone aren't enough.)
Thus, it is possible to have SYSV shared memory in B1, but all processes sharing memory have to have MAC labels such that you can't violate MAC through shared memory AND the memory being shared has itself to be in a region of memory that is authorized for access by that MAC label. In fact, you're supposed to have to security label even TCP/IP packets and not permit access control violations via regular networking. (This is in part why the anonymous coward's reference to MIC doesn't cover Orange Book-rated MAC.) Because nobody in their right minds implements Unix pipes or SYSV SHM with security labeling, only those in their left minds have non-covert forms of these. The rest of the population, as you correctly say, can't use top, kill, or almost anything else that forms the lifeblood of Unix use.
Because Orange Book MAC is bi-directional (unlike MIC, which is uni-directional), you cannot access material that is on either side of the MAC classification. This is good, in some respects. You can't transfer a virus from an unknown source to a destination that has a different MAC classification, for example. The net result is that anyone going for B-rated OS' under Orange Book is likely to go with the weaker-end of the spectrum. The higher-end is simply too restrictive or, because there's a hell of a lot of overhead involved in de-coverting all the Unix communications channels, too expensive on the CPU and on the wallet.
In consequence, even though solutions to the covert communications channel problem are permitted by the Rainbow series, almost nobody uses them.
His words are fine. You CAN use virtualization as a way to strengthen security, just as you can use concrete to make really strong structures. The problem is that concrete, on its own or poorly-utilized, is worthless for making much of anything.
You're correct. A security kernel that is provably (and proven) correct is hard to design, but has been doable for a long time. Any "Trusted" (as opposed to "Trustable" - which means "you can't actually trust it at all") OS is built around a verifiable level of isolation. (For example, if prior to the Common Criteria, you'd wanted Linux to be an A1-class OS, you could have done it even though Linux wasn't specified out from the start. A1 was perfectly achievable if the security kernel alone was specified from the start and the rest of the OS was merely audited to prove everything went through it.)
Even that is unnecessary, though. GRSecurity went belly-up because there were not enough developers interested in it and no funding for it at all. Problems any of the commercial distros could have fixed in a heartbeat and any of the major vendors (IBM, you listening?) SHOULD have fixed in a heartbeat. That wasn't perfect isolation but it was vastly superior to what we currently have which is too limited in scope and too limited in usage.
Remember, though, this last bit only applies to Linux. Some of the BSDs have MAC of some sort, but not all, though all of them could have it tomorrow if they wanted.
Windows - the only relationship it has with MAC is the British image of a dirty old man in a raincoat. But even there, where was the necessity? It has a built-in hardware abstraction layer and a few other key areas that could, quite easily, have all linked up with a proper security kernel. Instead, we've got BS and I don't mean it earned a degree.
Nobody with any cents invests long-term but, as I noted earlier, anybody with any sense certainly does. If you don't, you have a 66% chance of losing on any given transaction.
No, but you might be a poor investor. Yes, it'll boost immediate returns but only by sacrificing long-term benefits. The benefit will be brief. It's things like this that are why investment is almost entirely cognitive illusion and not based on skill or rational thought. The ones who are any good work along selective inaction. Responding to the market is the worst thing you can do.
You did not read the report. You didn't even bother with the report. You aren't twitching a finger because you know you've lost the argument. You're trolling because that's all you have left. You're pathetic.
How many offshore oil rigs are there in the estuary around Seascale? (If you answered "lots", you're probably from Texas and haven't a bloody clue where Seascale is. Clue - it's not in the fucking North Sea, where the bloody oil rigs are.)
Go read what it says about the Irish Sea, Sellafield/Seascale specifically, and stop with your bullshit crap.
Well, paper is to a decent degree C12, though there's some C14 as it's organic. The toner was probably graphite, so C12 and C14 again. Amounts - well, all of it.
There are 2 links on the 2nd paragraph, 1 on the 4th and the rest are on the unordered list as part of the 5th.
No, those are NOT my demands. Bloody Flat-Earther. My demands, as you know damn well, were that you show me the paper YOU got YOUR claim from. I've shown what papers I've got mine from, not that any other person needed those links - they googled them on their own, using the information I had already provided. A skill you apparently have yet to learn.
Are you a Fox News reporter? They're the only ones THIS incompetent.
The 24 references are listed in another of my posts and you are quite capable of going to my profile, selecting from this topic and looking them up. You won't? Ohhhh, now THERE'S a surprise! Not bothering to read is something that should have been evident to anyone within a mile of this thread.
Oh, and for those others still bothering to read, polonium-210 is the only radioisotope weighing at 210 reported in the Sellafield area. (Why bother with the link? Well, it's handy for illustrating the difference in credibility. I *CAN* show links, you CANNOT.)
I'd suggest you put that on ICHC with Chemistry Cat reading it as a news bulletin, but I might get sued by The Onion for patent infringement on Over-Satirizing the point.
Mother Nature has this one covered. They're to be called the non-citrtussy-roundish-things-that-are-great-at-keeping-doctors-away, N-CRT-TAGA-KDA for short, and will be sold by The Pirate Party for a small fee.
So, we're apparently agreed that I have 24 references to peer-reviewed papers to your bugger all, my experience to your zilch and my being there and involved in the work to your nothing whatsoever.
Conclusions, anyone?
(Mine would probably be that picking a fight with a researcher involved in the work is NEVER a good way to win an argument.)
See my other post. I have provided more than enough. And any damn fool can look up either the Gardner Report or the CERRIE report.
Further, I did indeed provide references earlier. You ignored them, sure, but I did provide them. You refusing to bother to look them up is not my concern. You, however, provided NOTHING. NADA. ZIPPO. ZILCH.
Certainly not daylight, but probably quite visible to any decent gamma ray detector. If you did a Google Earth but at the gamma or x-ray frequencies, the Irish Sea would certainly be the brightest mass of water anywhere in the world and quite possibly THE brightest mass of anything outside of the remnants of nuclear test sites.
Well, the one from the NRPB might be a better one to look at. There have certainly been more than 5 cases - indeed the only 5 I could see in this report is to a specific section in the references. The Gardner Report, which DOES mention 5 cases, refers to 5 cases that occurred in a specific time interval over the entire nation where 4 of those occurred in Seascale. The Gardner Report is the one which is the most-cited reference to childhood leukemia in Britain.
In fact, the table at the bottom-right for the Gardner Report is the most interesting for this purpose - a six-fold rise in leukemia incidents in the region surrounding Seascale with levels of leukemia remaining (a) constant and (b) at expected levels everywhere else over the same time period.
Radionuclide research groups *fried* the attempts by BNFL to conceal the link at the time and would doubtless be disgusted by the other posters here trying to attribute the cancers to "natural lead poisoning". I look forward to seeing these alleged papers "proving" that these distinguished experts were wrong and that a pseud-anonymous Slashdot poster is so vastly better and brighter that they can identify a wholly imagined lead isotope as the cause without having done an ounce of legwork.
Show me. Link to the papers charting everything that has been found at Seascale and show me, line and paragraph, where lead-210 is mentioned by isotope and quantity. Go on.
As with any good Object Oriented design, overrides are at the clause level and not the Act level. However, law has an interesting peculiarity in that semantics are considered as well as syntax. The result is that case law can state that a clause which is nominally overriding only does so under specific conditions. Case law always overrides written law.
The practical upshot is that you'd have to map out every clause in every one of the Acts, Charters and Dooms that form the basis of English Law, together with how they interact and what case law does to constrain those interactions, in order to put together what the current basis actually is.
This is partly why really good lawyers (as in "lawyers who actually understand what English law means", rather than "lawyers who understand how to profitably abuse the law") are extremely rare, extremely bright, and half-dead from old age. (It's hard to be extremely half-dead, or I'd have qualified that too.) Even then, there are probably more physicists who understand the totality of M-Theory than who understand the totality of the English legal system. And, yes, I know the total number of physicists who understand the totality of M-Theory is 0. This is why the English Constitution remains unwritten, complex and possibly wholly imaginary.
(I am unaware of any attempt to describe law using sedenions. It would probably be seditious anyway.)
See above. See LWN's article on low-level libraries. Hell, see a book on design. Low level libraries aren't applications and aren't application level. They're userspace but they're not appspace.
True, but when it's in the filesystem, you're restricted to the specific filesystem versions that use compatible compression. When it's a layer, it doesn't matter what version of anything anyone uses. That's the great thing about layered OS design - you're not subject to version hell. API hell, yes, but not version hell. Can't do much about API hell, since loosely-coupled designs have to rely on some method of communicating, but Linux limits API hell by enforcing backwards-compatibility at key points. This means, however, that you have to add your version-independent layers at those points and no other.
It's not in the kernel, it's in the low-level app libraries. (Ok, actually there IS a zlib compression function in the kernel that can be used for files, but it's not the one I'm referring to. Damn complexity.)
Basically, it overrides the "standard" application-layer I/O functions and replaces them with ones that do on-the-fly compression. It's totally invisible to applications, so you can ignore any references by others to "application level" workarounds. This isn't in the applications at all. It's in the interface between userspace and kernelspace, which (arguably) is where it should be. To the application, it's as if it were in the kernel - the app can't tell the difference - but it's not hogging up kernel threads and therefore not subject to all the headaches you get when a kernel thread goes nuts munching on CPU time.
I would imagine it's tunable. I've honestly never tried tuning it. It's there and when I roll my own distros (I'll only use other people's distros when I'm rushed for time) I invariably use it.
(For those not around long enough, I have spent almost 2 decades ferreting out under-utilized, obscure yet amazingly useful projects - be they kernel or userspace. I wouldn't even rate this project as obscure in relative terms - I've seen far more obscure projects that people are insane for not using but can be excused on the grounds that nobody tells anyone anything. Y'know, word-of-mouth is great but it requires one to open one's mouth.)
Slashdot Mirror
No, it was the GPL patch folk. If you look through the old news, you'll see the announcement that they lost their sponsor. They later announced - I think on LWN - that they were indeed stopping all work. Well, obviously they got the money they needed so fortunately I'm wrong in thinking that this had continued into the present day. Nonetheless, for a while they were zombified.
In theory, there are exceptions. In practice, you're so close to 100% right that I'd need extended floats to find the exceptions.
By the time you get into the Bs and As, which is where MAC gets involved, MAC is considered to encompass ALL communications, ALL memory management as well as ALL program access, except where otherwise noted. (Orange Book doesn't cover all the uses of MAC, so the Orange Book definitions alone aren't enough.)
Thus, it is possible to have SYSV shared memory in B1, but all processes sharing memory have to have MAC labels such that you can't violate MAC through shared memory AND the memory being shared has itself to be in a region of memory that is authorized for access by that MAC label. In fact, you're supposed to have to security label even TCP/IP packets and not permit access control violations via regular networking. (This is in part why the anonymous coward's reference to MIC doesn't cover Orange Book-rated MAC.) Because nobody in their right minds implements Unix pipes or SYSV SHM with security labeling, only those in their left minds have non-covert forms of these. The rest of the population, as you correctly say, can't use top, kill, or almost anything else that forms the lifeblood of Unix use.
Because Orange Book MAC is bi-directional (unlike MIC, which is uni-directional), you cannot access material that is on either side of the MAC classification. This is good, in some respects. You can't transfer a virus from an unknown source to a destination that has a different MAC classification, for example. The net result is that anyone going for B-rated OS' under Orange Book is likely to go with the weaker-end of the spectrum. The higher-end is simply too restrictive or, because there's a hell of a lot of overhead involved in de-coverting all the Unix communications channels, too expensive on the CPU and on the wallet.
In consequence, even though solutions to the covert communications channel problem are permitted by the Rainbow series, almost nobody uses them.
MIC is not MAC as defined under the Rainbow books. As noted before, questioning my research is more likely to show deficiencies in yours than in mine.
That was Deep Thought. Eddy's answer was infinity minus 1.
Still not seeing any links from you that rebut a damn thing. Just spittle. Link or be damned.
His words are fine. You CAN use virtualization as a way to strengthen security, just as you can use concrete to make really strong structures. The problem is that concrete, on its own or poorly-utilized, is worthless for making much of anything.
You're correct. A security kernel that is provably (and proven) correct is hard to design, but has been doable for a long time. Any "Trusted" (as opposed to "Trustable" - which means "you can't actually trust it at all") OS is built around a verifiable level of isolation. (For example, if prior to the Common Criteria, you'd wanted Linux to be an A1-class OS, you could have done it even though Linux wasn't specified out from the start. A1 was perfectly achievable if the security kernel alone was specified from the start and the rest of the OS was merely audited to prove everything went through it.)
Even that is unnecessary, though. GRSecurity went belly-up because there were not enough developers interested in it and no funding for it at all. Problems any of the commercial distros could have fixed in a heartbeat and any of the major vendors (IBM, you listening?) SHOULD have fixed in a heartbeat. That wasn't perfect isolation but it was vastly superior to what we currently have which is too limited in scope and too limited in usage.
Remember, though, this last bit only applies to Linux. Some of the BSDs have MAC of some sort, but not all, though all of them could have it tomorrow if they wanted.
Windows - the only relationship it has with MAC is the British image of a dirty old man in a raincoat. But even there, where was the necessity? It has a built-in hardware abstraction layer and a few other key areas that could, quite easily, have all linked up with a proper security kernel. Instead, we've got BS and I don't mean it earned a degree.
I've read it, I've understood it, you're trolling it and ignoring it. That's the end of it.
I wonder if the "final" set of patches from AMD include an easter-egg encouraging you to buy Intel.
Nobody with any cents invests long-term but, as I noted earlier, anybody with any sense certainly does. If you don't, you have a 66% chance of losing on any given transaction.
No, but you might be a poor investor. Yes, it'll boost immediate returns but only by sacrificing long-term benefits. The benefit will be brief. It's things like this that are why investment is almost entirely cognitive illusion and not based on skill or rational thought. The ones who are any good work along selective inaction. Responding to the market is the worst thing you can do.
You did not read the report. You didn't even bother with the report. You aren't twitching a finger because you know you've lost the argument. You're trolling because that's all you have left. You're pathetic.
How many offshore oil rigs are there in the estuary around Seascale? (If you answered "lots", you're probably from Texas and haven't a bloody clue where Seascale is. Clue - it's not in the fucking North Sea, where the bloody oil rigs are.)
Go read what it says about the Irish Sea, Sellafield/Seascale specifically, and stop with your bullshit crap.
Well, paper is to a decent degree C12, though there's some C14 as it's organic. The toner was probably graphite, so C12 and C14 again. Amounts - well, all of it.
There are 2 links on the 2nd paragraph, 1 on the 4th and the rest are on the unordered list as part of the 5th.
No, those are NOT my demands. Bloody Flat-Earther. My demands, as you know damn well, were that you show me the paper YOU got YOUR claim from. I've shown what papers I've got mine from, not that any other person needed those links - they googled them on their own, using the information I had already provided. A skill you apparently have yet to learn.
Are you a Fox News reporter? They're the only ones THIS incompetent.
The 24 references are listed in another of my posts and you are quite capable of going to my profile, selecting from this topic and looking them up. You won't? Ohhhh, now THERE'S a surprise! Not bothering to read is something that should have been evident to anyone within a mile of this thread.
Oh, and for those others still bothering to read, polonium-210 is the only radioisotope weighing at 210 reported in the Sellafield area. (Why bother with the link? Well, it's handy for illustrating the difference in credibility. I *CAN* show links, you CANNOT.)
I'd suggest you put that on ICHC with Chemistry Cat reading it as a news bulletin, but I might get sued by The Onion for patent infringement on Over-Satirizing the point.
Mother Nature has this one covered. They're to be called the non-citrtussy-roundish-things-that-are-great-at-keeping-doctors-away, N-CRT-TAGA-KDA for short, and will be sold by The Pirate Party for a small fee.
So, we're apparently agreed that I have 24 references to peer-reviewed papers to your bugger all, my experience to your zilch and my being there and involved in the work to your nothing whatsoever.
Conclusions, anyone?
(Mine would probably be that picking a fight with a researcher involved in the work is NEVER a good way to win an argument.)
The US Government already backs up all the porn on the Internet, except for NASA Ames which backs up all the movies.
See my other post. I have provided more than enough. And any damn fool can look up either the Gardner Report or the CERRIE report.
Further, I did indeed provide references earlier. You ignored them, sure, but I did provide them. You refusing to bother to look them up is not my concern. You, however, provided NOTHING. NADA. ZIPPO. ZILCH.
Certainly not daylight, but probably quite visible to any decent gamma ray detector. If you did a Google Earth but at the gamma or x-ray frequencies, the Irish Sea would certainly be the brightest mass of water anywhere in the world and quite possibly THE brightest mass of anything outside of the remnants of nuclear test sites.
Well, the one from the NRPB might be a better one to look at. There have certainly been more than 5 cases - indeed the only 5 I could see in this report is to a specific section in the references. The Gardner Report, which DOES mention 5 cases, refers to 5 cases that occurred in a specific time interval over the entire nation where 4 of those occurred in Seascale. The Gardner Report is the one which is the most-cited reference to childhood leukemia in Britain.
In fact, the table at the bottom-right for the Gardner Report is the most interesting for this purpose - a six-fold rise in leukemia incidents in the region surrounding Seascale with levels of leukemia remaining (a) constant and (b) at expected levels everywhere else over the same time period.
Radionuclide research groups *fried* the attempts by BNFL to conceal the link at the time and would doubtless be disgusted by the other posters here trying to attribute the cancers to "natural lead poisoning". I look forward to seeing these alleged papers "proving" that these distinguished experts were wrong and that a pseud-anonymous Slashdot poster is so vastly better and brighter that they can identify a wholly imagined lead isotope as the cause without having done an ounce of legwork.
Other links to papers that may be of interest:
Show me. Link to the papers charting everything that has been found at Seascale and show me, line and paragraph, where lead-210 is mentioned by isotope and quantity. Go on.
As with any good Object Oriented design, overrides are at the clause level and not the Act level. However, law has an interesting peculiarity in that semantics are considered as well as syntax. The result is that case law can state that a clause which is nominally overriding only does so under specific conditions. Case law always overrides written law.
The practical upshot is that you'd have to map out every clause in every one of the Acts, Charters and Dooms that form the basis of English Law, together with how they interact and what case law does to constrain those interactions, in order to put together what the current basis actually is.
This is partly why really good lawyers (as in "lawyers who actually understand what English law means", rather than "lawyers who understand how to profitably abuse the law") are extremely rare, extremely bright, and half-dead from old age. (It's hard to be extremely half-dead, or I'd have qualified that too.) Even then, there are probably more physicists who understand the totality of M-Theory than who understand the totality of the English legal system. And, yes, I know the total number of physicists who understand the totality of M-Theory is 0. This is why the English Constitution remains unwritten, complex and possibly wholly imaginary.
(I am unaware of any attempt to describe law using sedenions. It would probably be seditious anyway.)
See above. See LWN's article on low-level libraries. Hell, see a book on design. Low level libraries aren't applications and aren't application level. They're userspace but they're not appspace.
True, but when it's in the filesystem, you're restricted to the specific filesystem versions that use compatible compression. When it's a layer, it doesn't matter what version of anything anyone uses. That's the great thing about layered OS design - you're not subject to version hell. API hell, yes, but not version hell. Can't do much about API hell, since loosely-coupled designs have to rely on some method of communicating, but Linux limits API hell by enforcing backwards-compatibility at key points. This means, however, that you have to add your version-independent layers at those points and no other.
It's not in the kernel, it's in the low-level app libraries. (Ok, actually there IS a zlib compression function in the kernel that can be used for files, but it's not the one I'm referring to. Damn complexity.)
Basically, it overrides the "standard" application-layer I/O functions and replaces them with ones that do on-the-fly compression. It's totally invisible to applications, so you can ignore any references by others to "application level" workarounds. This isn't in the applications at all. It's in the interface between userspace and kernelspace, which (arguably) is where it should be. To the application, it's as if it were in the kernel - the app can't tell the difference - but it's not hogging up kernel threads and therefore not subject to all the headaches you get when a kernel thread goes nuts munching on CPU time.
I would imagine it's tunable. I've honestly never tried tuning it. It's there and when I roll my own distros (I'll only use other people's distros when I'm rushed for time) I invariably use it.
(For those not around long enough, I have spent almost 2 decades ferreting out under-utilized, obscure yet amazingly useful projects - be they kernel or userspace. I wouldn't even rate this project as obscure in relative terms - I've seen far more obscure projects that people are insane for not using but can be excused on the grounds that nobody tells anyone anything. Y'know, word-of-mouth is great but it requires one to open one's mouth.)