Boy, talk about not understanding Internet protocols.
NTP packets are basically "I think it's this time...what do you think", while DNS is "I want to know the IP for www.childpr0n.com".
There just isn't any possible privacy issue with NTP packets, while DNS is basically a record of everything you visit. Heck, if OpenDNS were to modify the TTL in their DNS replies, they could even get more complete data about how often you request each site.
Actually, I must be wrong about you misunderstanding. Nobody could be that dumb, so you must work for OpenDNS (or another company that benefits from their data collection).
The patches for SELinux have the same goal as UAC (and vice versa). That is, they provide a means of controlling what various applications can actually access on a PC.
They may have the same goal, but UAC is completely different in that it works within the existing security token and ACL framework.
UAC can't do things like stopping "cmd.exe" from writing to a file in C:\, while SELinux can do the equivalent. In Windows, the process runs with the security token of the user, and that completely controls what the process can do.
UAC just alters the security token so that processes aren't always as powerful as the user really is. Although you could implement some form of the same control that SELinux offers by having users like "cmd.exe" and assigning "deny" permissions to that user for objects it should not access, this would add a lot of bloat in the filesystem security descriptors. It would also be very difficult to set up the correct permissions so that all this worked across a network, and wasn't avoided by merely renaming the executable.
For example, the idea of "root" means nothing in SELinux. A process with uid root can't get out of its confined security context and go rampant just because of its root privilege.
First, there are specific SELinux user contexts that refer to root (as opposed to a regular user), so, yeah, SELinux does have the idea of "root".
Second, you have to be able to administer the system somehow, and SELinux is part of the system. And, you really don't want SELinux being the part that restricts what can configure SELinux, because then one screwup and the system is hosed.
For a truly secure system, it might not be the case, but with every SELinux-enabled distribution I have seen, "setenforce 0" as root will let you do anything you want.
But if they're lucky, customers will be able to hit that cap quickly.
This refers to the 60Mbps service being offered. However, the summary itself says it will have no cap.
Still, at 15Mpbs, you can hit the 100GB cap for that service level in just 14 hours.
For the 25Mbps service, you hit the 250GB cap in 22 hours. Or, as others have pointed out, the 250GB cap allows you to average 760514 bits per second (about 750Kbps). If you download something that takes just 2 minutes at 25Mbps, that means you essentially can't use your connection at all for the next hour to bring you back to the average.
If you can't actually get the quoted max speed (which is usually the case), this helps a bit, but then you still end up in the situation of paying for more than they can possibly deliver.
The post you cite is talking about a station that has gotten the correct permission from the FCC to shut off the analog transmission early. In that case, the digital signal is counted for their broadcast requirements.
But, it's not just a simple "file this paper". The station has to show that making any change to their coverage area would not run afoul of any of the FCC regs, which include "serving the community".
Most people think that TV (and radio) stations can do things like shut off their transmitter any time they want. If a station just lowers its ERP without letting the FCC know, they can get in trouble. Shutting off entirely without notifying the FCC before the fact had better be caused by some piece of hardware catching on fire.
ATSC channels all broadcast a logical channel assignment, and that's what your PVR is going to use. So if your local "NBC-4" affiliate switches from UHF 48 down to some other assignment (could go back to VHF 4, but most are not returning to the lower VHF band), you'll still see it in the tuner as logical 4.
There is no requirement to use virtual channel numbers in devices. I don't enable it in any of mine that I can avoid, since it offers basically nothing, and causes a lot of problems if you get more than one "virtual channel 4".
But, my TiVo is a problem because it requires me to use virtual numbers to get guide data. And, this is an issue because...
If you're already digital, the only real effect here is that, for OTA stuff, you'll potentially have to re-scan more than once.
...my HD TiVo doesn't have a "re-scan" feature for digital channels...at least not one that connects with guide data. I have an early one, so maybe it's different now.
I'd say that Vista is partly to blame, too, for the stupid decision to restrict writes to the root of drive C:
I've been changing the security on the root of drives since as far back as Windows NT, since there is no reason to allow a general user permission to write to the root directory.
I delete "Everyone" and "CREATOR OWNER", and set "Users" to read-only. I haven't had any issues with this on any program. Sure, you need to be an admin to install some things that create a temporary directory off the root, but that's the point.
The FCC has rules about how many hours of things like public service you have to run to keep your license.
Until February 17, the calculation comes from the analog signal.
So, a station could have just killed the analog early without getting special FCC approval, but then they would have lost their license for both analog and digital.
Likewise, a station can just choose to "go dark", but if they don't meet the FCC regulations, they won't have a license an more if they want to turn back on again. Since good frequencies are worth money (both in the ability to cover more area and in branding goodwill for channel numbers), most would be snapped up by someone else pretty quickly, like domains that expire.
With a hard cutoff date and no option to switch before that day, far less people would be confused.
As it is, now you are adding people who already have ATSC receivers to the "likely confused", as they will have to keep track of exactly when each station switches and how that station switches (changing frequency, power level, transmitter location, virtual channel, etc.).
In addition, automatically programmed devices (like the HD TiVo) will have to change the virtual to physical mapping at different times for each station. In some cases, the stations will choose to re-brand with the new permanent channel because that old channel could now be opened up. Think of the confusion if some new station ends up on channel 4 while "NBC 4" is broadcasting on channel 48.
The thing that is most stupid is that the original plan wasn't to do the cutover on a Saturday afternoon. What possible reason could there be to make Tuesday the changeover day?
Seriously--being a network admin is about making it easy for the end-user. However you want to organize your systems is up to you and your employer, but it seems stupid to come up with a retarded naming scheme for your servers because your users are idiots. That's what DNS is for. Admins should have a nice format for naming servers (like CLLI, but better), then let the users decide what they need to be called and toss that in DNS.
Or, better yet, remove most of the machine names entirely from end-user minds by using some sort of distributed file system.
Although this won't work for some things, it is great for editing files, and users won't have to know what is where. They just need to know that \\YOURDOMAIN\Websites\HumanResources is where they go when they want to edit the HR web content. That content could be on one or more servers, but they won't have to know or care.
DFS is one of the few things that Microsoft has done well, and I haven't seen anything as easy to configure or use in the *nix world.
I worked at a company that named machines after characters and places from Middle Earth (a common naming scheme, I'm sure).
My personal home naming scheme has been bladed weapons (claymore, cutlass, dagger, hatchet, etc.) for 15+ years.
So, it was quite a nice bit of serendipity that the machine that interfaced between the home and work was named bilbo, which is both a hobbit and a weapon.
I might lose any stations that move back into VHF.
This is unlikely.
Very few stations are choosing to move their digital signal to any of the VHF-Low (2-6) channels, and only a very few UHF antennas won't get good enough reception on VHF-Hi (7-13).
Austin has only Fox choosing a VHF-Hi channel (7) as their final digital frequency. See here for more information on the final channel assignments and when and how they expect to make the change.
Everyone in the United States pays federal income tax.
Some get almost all of it refunded due to deductions to income, but to get that money back, they have to file an income tax return with the IRS. The tax code could have been changed to add a $50 credit (or whatever is appropriate) as the last step on the return.
No, Wikipedia's policy is to include information that is available somewhere else on the web, so it can be linked to.
As an example, to "verify" things I've seen Wikipedia link to TV show fan sites pages that are transcripts from some conversation that two people had. One of the people in the conversation worked on the TV show in question in some capacity. How, exactly is that "verifiable"?
In reality, it's not, but because it is listed as "transcript of interview with Joe Electrician who worked on cool sci-fi show" instead of "drunk ramblings of some guy in my mom's basement", it's "verifiable".
Likewise, on the link policy, it pretty much seems like a print-only publication can't be used as a source for a Wikipedia "fact". Thus, even though something is obviously verifiable, it still isn't good enough for Wikipedia.
Last, look at the Steve Jobs entry I mentioned. The only way his birthdate is "verified" is because he stated it in an interview with the Smithsonian. It's pretty damn easy to actually verify this by checking birth records and use an authoritative source, but since it probably can't be linked to, that's not good enough for Wikipedia. Yes, I know it's not really important, but then you get into deciding what is and isn't important enough to verify, and with the controversy that surrounds someone like Steve Jobs, that becomes editorial bias.
And, so, you end up with Wikipedia's policies that are designed to prevent editorial bias actually encourage it, because they automatically rule out using some very authoritative sources, while blinding accepting others that probably aren't authoritative.
Many (inexperienced) linux admins like to reboot their boxen too remember
I've seen many times when issues required a reboot of a *nix machine.
The latest one I'm dealing with is a machine that completely drops off the network (no pings, etc.). Restarting services has no effect, so we suspect it is hardware, but that doesn't make a lot of sense, because the obvious culprit (the network cards) have physical redundancy and pass all diagnostics. We've also swapped out cards, but still see the same thing. The next step is to move to a card that uses a different driver, but that's something that requires change control to get involved.
It only happens about once every two months, and since the machine itself is part of a cluster, it doesn't hurt productivity much, but it is annoying.
And now the malware writer must convince the user to do something that the user was not planning to do, beyond simply opening the virus. Now the user must open virus, then write their own SELinux bypass on the malware author's instruction, and only then can the attack be completed.
Do you not understand the point I was making? The "bypass" is that the malware author needs to add "| cat -" on to the end of a "protected" command. Once you get the user to execute the "malware installer", it's over, since that script can now do anything that the executing user can do. If the executing user has the ability to run as root (like having run sudo recently), it's really over.
SELinux can't protect against anything if you are running as root, since root, by definition has to be able to do everything. So, there is some workaround for every SELinux "protection". The only actual protection a *nix system has is the file system protection, and the fact that non-root users can't just write willy-nilly to any file.
Not if they are competent when it comes to security. Mandatory ACLs and auditing are not something most sysadmins who have security concerns want to disable
SELinux doesn't provide mandatory ACLs. Only the file system provides true mandatory protection, as even root can't bypass them (especially ext3 attributes), although they can change them. The fact that I, as a non-root user, can bypass even one SELinux "protection" without having elevated privileges means it isn't "mandatory".
In addition, the only auditing that ever happens is when SELinux prevents something from happening. What about all the things that don't trigger a failure but are "bad"? How do you know they have happened. Oh, yeah, you don't, at least not from SELinux.
It's frightening that Windows has better auditing built in (although sadly not enabled by default) than even "SEcure Linux".
Except that the workaround will require social engineering,
If by "social engineering", you mean "convincing someone to in some way download your malware", then you are correct. But, that's pretty much a given for any malware, so I don't see what extra effort is required by the malware author to infect an SELinux system.
If you download an RPM or DEB and then double-click it from a GUI, it will install, after maybe asking you for a password (depending on the settings for sudo and sudo-like systems...whatever password it is asking for may be cached). If that installation process runs as root, then it can do anything and SELinux won't stop it, as any malware author will have written the install to bypass any SELinux "protection" with trivial hacks. Hell, it could even permanently turn off SELinux as part of the install (by adding "selinux=0" to the kernel command line in the bootloader).
Part of the problem with SELinux is that it really needs some good policies. How about "log every change or attempted change to any file in/bin,/sbin,/usr/bin,/usr/sbin"? With a re-direction of syslog to another machine, that's something that would be hard to get by. Sure, you could still have malware, but at least you'd know about when the change happened.
Or, how about an SHA1 hash of all the binaries and some sort of daily scanner to verify? These are real ways that you can at least know if your system is compromised, and maybe even stop it.
Last, SELinux does nothing to prevent local users from working on exploits, since they can find out exactly what the policy is and not trigger anything.
For home users, SELinux prevents quiet attacks (or should prevent them if the distro policy maintainers are decent, like Dan Walsh)
If Dan Walsh is responsible for the useless policies installed by default in Fedora 10, then your definition of "decent" is far different from mine. All they do is annoy users, while any malware writer will be able to come up with workarounds that allow install of the malware with no red flags being raised.
Unless the CPU is 100% loaded, then you won't shouldn't notice DRM affecting actual speed.
This is because a 30 frame-per-second video will play back at 30fps on any machine that is fast enough to handle it. A theoretical quad-core 10GHz processor with a GPU capable of handling 1000x the processing of current units would still only play back that video at 30fps.
The difference is that with DRM, more CPU is used. Even though it might not be enough extra CPU usage to cause an issue, it is something.
And, it's easy to see than the DRM code in Vista takes CPU cycles at times when it shouldn't, like playing back un-protected content. This is partially due to the complete paranoia of the design in that authorizing the content at start was not good enough, so the system has hooks that essentially allows DRM on only select portions of the content, which means it must constantly check to see if the particular frame playing right now is protected, and, if so, what needs to be done.
This reminds me of the Microsoft design for security in Access databases, which checks before each row is read/written to see if the operation is permitted. This means that if you have a query that updates a bunch of rows, there is not one check at the start of the query to see if the operation is permitted, but instead right before the operation is performed on each affected row, the security check is made. This also makes transactions really slow to implement. And, like the ability to enable DRM for a few frames of a video, is just as useless.
This is the idea -- you want to ensure that if something is writing to those files, and it is potentially dangerous, it is something that users need to have some minimum level of knowledge to do.
No, that's stupid, because a malware writer certainly has the requisite level of knowledge to bypass the problem. The "iptables-save" example I gave was something I ran into the first day I used an SELinux-enabled system, and it took me all of 10 minutes to figure out the workaround.
So, now you have a user who thinks that as long as there is no SELinux warning, the system is safe. Well, at least's it's better than the UAC warnings, which allow the user to blindly click and let the malware run.
Add in the fact that most (if not all) of the default policies are just plain stupid (why is it OK to "cp" over a file in/var/lib/dhclient but not "mv" over it?), and you see why the first thing most admins do is disable SELinux.
Without any SELinux policies, the edit could happen quietly, without the user ever knowing it happened.
I think you are a bit confused. Once a malware writer figures the workaround, then there is no SELinux log that anything happened, because SELinux only logs "prevents" by default. And, although you can have it log "permits", nobody has that much disk space.
If you want to say something in Wikipedia, you should be prepared to cite a reliable source verifying what you say. It doesn't matter if it's true and you just know it.
So, basically, if someone wrote a piece of software and thus had inside information about the design of that software, until they had that same information reported by the New York Times online, it couldn't be added to Wikipedia.
Likewise, as long as it's reported by the New York Times online and not refuted by any other "reliable source", it can appear in Wikipedia, even if it is completely untrue.
Of course "reliable" seems to be completely flexible, as it appears that somebody blogging from their garage is generally good enough to be called "reliable", while something that only appears in the New York Times print edition isn't "reliable".
I rant about this because I discovered an article on Wikipedia about something that I was personally involved with creating (along with less than a dozen other people), and there is much I could add to expand on it now that over 10 years have gone by, but unfortunately I'm not allowed to, since the information has never been "published" anywhere else. But, since Steve Jobs stated in a recorded speech that he was born on February 24, 1955, that's "reliable", with no extra fact-checking.
With this sort of completely abitrary definition of "reliable", is it any wonder that there is so much controversy about the Wikipedia policies?
SELinux goes a long way toward containing viruses, as long as the distro maintains decent default policies. For example, only files from the Mozilla packages should be able to modify ~/.mozilla/ or any files in that directory, and Fedora's SELinux policy puts those files in their own context.
So, when I want to use vi to edit one of the text files that are used to configure Firefox, I can't?
Although this might be more secure, I call it just a pain in the ass. Most of the SELinux policies fall into this category, although a few are just a pain in the ass without being any more secure. Add the following to your.bashrc to work around one of them:
If this same sort of hack works with the Mozilla SELinux policy, then all you would need to do is read the files from the ~/.mozilla directory, write out any changes to someplace like/tmp, then "download" the files from/tmp using Firefox and store it in the correct place in ~/.mozilla. I'll bet, though, that all that would be required is the "pipe it through a trusted program" hack would work, too.
Slashdot Mirror
Boy, talk about not understanding Internet protocols.
NTP packets are basically "I think it's this time...what do you think", while DNS is "I want to know the IP for www.childpr0n.com".
There just isn't any possible privacy issue with NTP packets, while DNS is basically a record of everything you visit. Heck, if OpenDNS were to modify the TTL in their DNS replies, they could even get more complete data about how often you request each site.
Actually, I must be wrong about you misunderstanding. Nobody could be that dumb, so you must work for OpenDNS (or another company that benefits from their data collection).
At some point, some program has to run as root, or else many things (like starting services, updating software, etc.) can't get done.
The patches for SELinux have the same goal as UAC (and vice versa). That is, they provide a means of controlling what various applications can actually access on a PC.
They may have the same goal, but UAC is completely different in that it works within the existing security token and ACL framework.
UAC can't do things like stopping "cmd.exe" from writing to a file in C:\, while SELinux can do the equivalent. In Windows, the process runs with the security token of the user, and that completely controls what the process can do.
UAC just alters the security token so that processes aren't always as powerful as the user really is. Although you could implement some form of the same control that SELinux offers by having users like "cmd.exe" and assigning "deny" permissions to that user for objects it should not access, this would add a lot of bloat in the filesystem security descriptors. It would also be very difficult to set up the correct permissions so that all this worked across a network, and wasn't avoided by merely renaming the executable.
For example, the idea of "root" means nothing in SELinux. A process with uid root can't get out of its confined security context and go rampant just because of its root privilege.
First, there are specific SELinux user contexts that refer to root (as opposed to a regular user), so, yeah, SELinux does have the idea of "root".
Second, you have to be able to administer the system somehow, and SELinux is part of the system. And, you really don't want SELinux being the part that restricts what can configure SELinux, because then one screwup and the system is hosed.
For a truly secure system, it might not be the case, but with every SELinux-enabled distribution I have seen, "setenforce 0" as root will let you do anything you want.
But if they're lucky, customers will be able to hit that cap quickly.
This refers to the 60Mbps service being offered. However, the summary itself says it will have no cap.
Still, at 15Mpbs, you can hit the 100GB cap for that service level in just 14 hours.
For the 25Mbps service, you hit the 250GB cap in 22 hours. Or, as others have pointed out, the 250GB cap allows you to average 760514 bits per second (about 750Kbps). If you download something that takes just 2 minutes at 25Mbps, that means you essentially can't use your connection at all for the next hour to bring you back to the average.
If you can't actually get the quoted max speed (which is usually the case), this helps a bit, but then you still end up in the situation of paying for more than they can possibly deliver.
The post you cite is talking about a station that has gotten the correct permission from the FCC to shut off the analog transmission early. In that case, the digital signal is counted for their broadcast requirements.
But, it's not just a simple "file this paper". The station has to show that making any change to their coverage area would not run afoul of any of the FCC regs, which include "serving the community".
Most people think that TV (and radio) stations can do things like shut off their transmitter any time they want. If a station just lowers its ERP without letting the FCC know, they can get in trouble. Shutting off entirely without notifying the FCC before the fact had better be caused by some piece of hardware catching on fire.
ATSC channels all broadcast a logical channel assignment, and that's what your PVR is going to use. So if your local "NBC-4" affiliate switches from UHF 48 down to some other assignment (could go back to VHF 4, but most are not returning to the lower VHF band), you'll still see it in the tuner as logical 4.
There is no requirement to use virtual channel numbers in devices. I don't enable it in any of mine that I can avoid, since it offers basically nothing, and causes a lot of problems if you get more than one "virtual channel 4".
But, my TiVo is a problem because it requires me to use virtual numbers to get guide data. And, this is an issue because...
If you're already digital, the only real effect here is that, for OTA stuff, you'll potentially have to re-scan more than once.
...my HD TiVo doesn't have a "re-scan" feature for digital channels...at least not one that connects with guide data. I have an early one, so maybe it's different now.
I'd say that Vista is partly to blame, too, for the stupid decision to restrict writes to the root of drive C:
I've been changing the security on the root of drives since as far back as Windows NT, since there is no reason to allow a general user permission to write to the root directory.
I delete "Everyone" and "CREATOR OWNER", and set "Users" to read-only. I haven't had any issues with this on any program. Sure, you need to be an admin to install some things that create a temporary directory off the root, but that's the point.
The FCC has rules about how many hours of things like public service you have to run to keep your license.
Until February 17, the calculation comes from the analog signal.
So, a station could have just killed the analog early without getting special FCC approval, but then they would have lost their license for both analog and digital.
Likewise, a station can just choose to "go dark", but if they don't meet the FCC regulations, they won't have a license an more if they want to turn back on again. Since good frequencies are worth money (both in the ability to cover more area and in branding goodwill for channel numbers), most would be snapped up by someone else pretty quickly, like domains that expire.
With a hard cutoff date and no option to switch before that day, far less people would be confused.
As it is, now you are adding people who already have ATSC receivers to the "likely confused", as they will have to keep track of exactly when each station switches and how that station switches (changing frequency, power level, transmitter location, virtual channel, etc.).
In addition, automatically programmed devices (like the HD TiVo) will have to change the virtual to physical mapping at different times for each station. In some cases, the stations will choose to re-brand with the new permanent channel because that old channel could now be opened up. Think of the confusion if some new station ends up on channel 4 while "NBC 4" is broadcasting on channel 48.
The thing that is most stupid is that the original plan wasn't to do the cutover on a Saturday afternoon. What possible reason could there be to make Tuesday the changeover day?
I'm not familiar with "the growing peanut fiasco".
Is there a problem because peanut farmers aren't embracing free-range farming techniques?
Most of us have never had a problem with it...except that it required 335 megs of disk space on Windows.
I have a full install of Adobe Reader 7.0 and it takes up less than 80MB.
Perhaps you were thinking of Adobe Acrobat, which is the Adobe software for creating and editing PDF files.
Seriously--being a network admin is about making it easy for the end-user. However you want to organize your systems is up to you and your employer, but it seems stupid to come up with a retarded naming scheme for your servers because your users are idiots. That's what DNS is for. Admins should have a nice format for naming servers (like CLLI, but better), then let the users decide what they need to be called and toss that in DNS.
Or, better yet, remove most of the machine names entirely from end-user minds by using some sort of distributed file system.
Although this won't work for some things, it is great for editing files, and users won't have to know what is where. They just need to know that \\YOURDOMAIN\Websites\HumanResources is where they go when they want to edit the HR web content. That content could be on one or more servers, but they won't have to know or care.
DFS is one of the few things that Microsoft has done well, and I haven't seen anything as easy to configure or use in the *nix world.
I worked at a company that named machines after characters and places from Middle Earth (a common naming scheme, I'm sure).
My personal home naming scheme has been bladed weapons (claymore, cutlass, dagger, hatchet, etc.) for 15+ years.
So, it was quite a nice bit of serendipity that the machine that interfaced between the home and work was named bilbo, which is both a hobbit and a weapon.
I might lose any stations that move back into VHF.
This is unlikely.
Very few stations are choosing to move their digital signal to any of the VHF-Low (2-6) channels, and only a very few UHF antennas won't get good enough reception on VHF-Hi (7-13).
Austin has only Fox choosing a VHF-Hi channel (7) as their final digital frequency. See here for more information on the final channel assignments and when and how they expect to make the change.
Everyone in the United States pays federal income tax.
Some get almost all of it refunded due to deductions to income, but to get that money back, they have to file an income tax return with the IRS. The tax code could have been changed to add a $50 credit (or whatever is appropriate) as the last step on the return.
No, Wikipedia's policy is to include information that is available somewhere else on the web, so it can be linked to.
As an example, to "verify" things I've seen Wikipedia link to TV show fan sites pages that are transcripts from some conversation that two people had. One of the people in the conversation worked on the TV show in question in some capacity. How, exactly is that "verifiable"?
In reality, it's not, but because it is listed as "transcript of interview with Joe Electrician who worked on cool sci-fi show" instead of "drunk ramblings of some guy in my mom's basement", it's "verifiable".
Likewise, on the link policy, it pretty much seems like a print-only publication can't be used as a source for a Wikipedia "fact". Thus, even though something is obviously verifiable, it still isn't good enough for Wikipedia.
Last, look at the Steve Jobs entry I mentioned. The only way his birthdate is "verified" is because he stated it in an interview with the Smithsonian. It's pretty damn easy to actually verify this by checking birth records and use an authoritative source, but since it probably can't be linked to, that's not good enough for Wikipedia. Yes, I know it's not really important, but then you get into deciding what is and isn't important enough to verify, and with the controversy that surrounds someone like Steve Jobs, that becomes editorial bias.
And, so, you end up with Wikipedia's policies that are designed to prevent editorial bias actually encourage it, because they automatically rule out using some very authoritative sources, while blinding accepting others that probably aren't authoritative.
Many (inexperienced) linux admins like to reboot their boxen too remember
I've seen many times when issues required a reboot of a *nix machine.
The latest one I'm dealing with is a machine that completely drops off the network (no pings, etc.). Restarting services has no effect, so we suspect it is hardware, but that doesn't make a lot of sense, because the obvious culprit (the network cards) have physical redundancy and pass all diagnostics. We've also swapped out cards, but still see the same thing. The next step is to move to a card that uses a different driver, but that's something that requires change control to get involved.
It only happens about once every two months, and since the machine itself is part of a cluster, it doesn't hurt productivity much, but it is annoying.
And now the malware writer must convince the user to do something that the user was not planning to do, beyond simply opening the virus. Now the user must open virus, then write their own SELinux bypass on the malware author's instruction, and only then can the attack be completed.
Do you not understand the point I was making? The "bypass" is that the malware author needs to add "| cat -" on to the end of a "protected" command. Once you get the user to execute the "malware installer", it's over, since that script can now do anything that the executing user can do. If the executing user has the ability to run as root (like having run sudo recently), it's really over.
SELinux can't protect against anything if you are running as root, since root, by definition has to be able to do everything. So, there is some workaround for every SELinux "protection". The only actual protection a *nix system has is the file system protection, and the fact that non-root users can't just write willy-nilly to any file.
Not if they are competent when it comes to security. Mandatory ACLs and auditing are not something most sysadmins who have security concerns want to disable
SELinux doesn't provide mandatory ACLs. Only the file system provides true mandatory protection, as even root can't bypass them (especially ext3 attributes), although they can change them. The fact that I, as a non-root user, can bypass even one SELinux "protection" without having elevated privileges means it isn't "mandatory".
In addition, the only auditing that ever happens is when SELinux prevents something from happening. What about all the things that don't trigger a failure but are "bad"? How do you know they have happened. Oh, yeah, you don't, at least not from SELinux.
It's frightening that Windows has better auditing built in (although sadly not enabled by default) than even "SEcure Linux".
Except that the workaround will require social engineering,
If by "social engineering", you mean "convincing someone to in some way download your malware", then you are correct. But, that's pretty much a given for any malware, so I don't see what extra effort is required by the malware author to infect an SELinux system.
If you download an RPM or DEB and then double-click it from a GUI, it will install, after maybe asking you for a password (depending on the settings for sudo and sudo-like systems...whatever password it is asking for may be cached). If that installation process runs as root, then it can do anything and SELinux won't stop it, as any malware author will have written the install to bypass any SELinux "protection" with trivial hacks. Hell, it could even permanently turn off SELinux as part of the install (by adding "selinux=0" to the kernel command line in the bootloader).
Part of the problem with SELinux is that it really needs some good policies. How about "log every change or attempted change to any file in /bin, /sbin, /usr/bin, /usr/sbin"? With a re-direction of syslog to another machine, that's something that would be hard to get by. Sure, you could still have malware, but at least you'd know about when the change happened.
Or, how about an SHA1 hash of all the binaries and some sort of daily scanner to verify? These are real ways that you can at least know if your system is compromised, and maybe even stop it.
Last, SELinux does nothing to prevent local users from working on exploits, since they can find out exactly what the policy is and not trigger anything.
For home users, SELinux prevents quiet attacks (or should prevent them if the distro policy maintainers are decent, like Dan Walsh)
If Dan Walsh is responsible for the useless policies installed by default in Fedora 10, then your definition of "decent" is far different from mine. All they do is annoy users, while any malware writer will be able to come up with workarounds that allow install of the malware with no red flags being raised.
He's probably IMMENSELY frustrated that they could only release this crap given the building products they have to work with.
So, what you're saying is that no matter how bad the product is, Microsoft feels they must release it to the public.
Makes sense, and it explains Vista quite nicely.
XP home supports a single CPU socket, while XP Pro supports up to two CPU sockets.
Either OS can support a maximum of 32 total cores.
Unless the CPU is 100% loaded, then you won't shouldn't notice DRM affecting actual speed.
This is because a 30 frame-per-second video will play back at 30fps on any machine that is fast enough to handle it. A theoretical quad-core 10GHz processor with a GPU capable of handling 1000x the processing of current units would still only play back that video at 30fps.
The difference is that with DRM, more CPU is used. Even though it might not be enough extra CPU usage to cause an issue, it is something.
And, it's easy to see than the DRM code in Vista takes CPU cycles at times when it shouldn't, like playing back un-protected content. This is partially due to the complete paranoia of the design in that authorizing the content at start was not good enough, so the system has hooks that essentially allows DRM on only select portions of the content, which means it must constantly check to see if the particular frame playing right now is protected, and, if so, what needs to be done.
This reminds me of the Microsoft design for security in Access databases, which checks before each row is read/written to see if the operation is permitted. This means that if you have a query that updates a bunch of rows, there is not one check at the start of the query to see if the operation is permitted, but instead right before the operation is performed on each affected row, the security check is made. This also makes transactions really slow to implement. And, like the ability to enable DRM for a few frames of a video, is just as useless.
This is the idea -- you want to ensure that if something is writing to those files, and it is potentially dangerous, it is something that users need to have some minimum level of knowledge to do.
No, that's stupid, because a malware writer certainly has the requisite level of knowledge to bypass the problem. The "iptables-save" example I gave was something I ran into the first day I used an SELinux-enabled system, and it took me all of 10 minutes to figure out the workaround.
So, now you have a user who thinks that as long as there is no SELinux warning, the system is safe. Well, at least's it's better than the UAC warnings, which allow the user to blindly click and let the malware run.
Add in the fact that most (if not all) of the default policies are just plain stupid (why is it OK to "cp" over a file in /var/lib/dhclient but not "mv" over it?), and you see why the first thing most admins do is disable SELinux.
Without any SELinux policies, the edit could happen quietly, without the user ever knowing it happened.
I think you are a bit confused. Once a malware writer figures the workaround, then there is no SELinux log that anything happened, because SELinux only logs "prevents" by default. And, although you can have it log "permits", nobody has that much disk space.
If you want to say something in Wikipedia, you should be prepared to cite a reliable source verifying what you say. It doesn't matter if it's true and you just know it.
So, basically, if someone wrote a piece of software and thus had inside information about the design of that software, until they had that same information reported by the New York Times online, it couldn't be added to Wikipedia.
Likewise, as long as it's reported by the New York Times online and not refuted by any other "reliable source", it can appear in Wikipedia, even if it is completely untrue.
Of course "reliable" seems to be completely flexible, as it appears that somebody blogging from their garage is generally good enough to be called "reliable", while something that only appears in the New York Times print edition isn't "reliable".
I rant about this because I discovered an article on Wikipedia about something that I was personally involved with creating (along with less than a dozen other people), and there is much I could add to expand on it now that over 10 years have gone by, but unfortunately I'm not allowed to, since the information has never been "published" anywhere else. But, since Steve Jobs stated in a recorded speech that he was born on February 24, 1955, that's "reliable", with no extra fact-checking.
With this sort of completely abitrary definition of "reliable", is it any wonder that there is so much controversy about the Wikipedia policies?
SELinux goes a long way toward containing viruses, as long as the distro maintains decent default policies. For example, only files from the Mozilla packages should be able to modify ~/.mozilla/ or any files in that directory, and Fedora's SELinux policy puts those files in their own context.
So, when I want to use vi to edit one of the text files that are used to configure Firefox, I can't?
Although this might be more secure, I call it just a pain in the ass. Most of the SELinux policies fall into this category, although a few are just a pain in the ass without being any more secure. Add the following to your .bashrc to work around one of them:
iptables-save() {
/sbin/iptables-save $* | cat -
}
If this same sort of hack works with the Mozilla SELinux policy, then all you would need to do is read the files from the ~/.mozilla directory, write out any changes to someplace like /tmp, then "download" the files from /tmp using Firefox and store it in the correct place in ~/.mozilla. I'll bet, though, that all that would be required is the "pipe it through a trusted program" hack would work, too.