Because HPUX is funny. Reading the code compatibility requirements for Mozilla with my friends and picking out all the places that special provisions had to be made to address horrendous flaws in HPUX that all other *IX systems are years beyond is much more funny than reading a Dilbert comic.
The right thing to do is to keep the resolution high and increase the font size.
Note that much of this is a problem specific to the Windows API -- it doesn't deal too well with resizing all the fonts. There's too much pixel-level positioning.
When someone goes to a porn site for the first time, I imagine they'd spend a couple hours checking out everything that's there. Imagine if they went over their limit the first time they went to the site? I doubt they'd renew, even after their usage of the site goes down for the rest of the month.
If we're talking about multi-thousand-dollar bandwidth bills going to the porn company on a single account, then there is excess downloading beyond one person just wanting to download a lot of movies. The cap can be high, sure. It might be 500GB/month (which is probably a *lot* more liberal than it needs to be). However, if someone is downloading the equivalent of 400 full length extremely high-quality movies a month, something is definitely wrong. I think that it's possible to be lax enough to allow even the most rabid of downloaders and still solid enough to catch passwords getting posted to major forums like USENET.
Erring on the side of generosity is certainly a good idea -- I just want to point out that some degree of sanity checking on bandwidth is *definitely* a good thing, though you may need to set the caps to taste for the site that you're developing.
Darn, I forgot to include the tidbit that I really *did* want to include, given who you are.
There is a way that Linux packaging could be used to improve security. Current state-of-the-art Linux packaging systems pretty much operate in "install as root". There's a script run that runs as root and has the ability to do anything. It would be helpful if, packages could contain a standard way of denoting the privileges that a package requires to be installed. (A package manager could place restrictions on what is allowed.) Package managers currently provide very minimal or nonexistant sandboxing capabilities.
For example, perhaps I do not want to allow an installer to create any SUID files, since I don't want more floating around on my system. Perhaps I want to prevent an installer from modifying any existing files, and only adding the files specified in the package requirements. Perhaps I want to *require* that all executable files be SUID/SGID a new user with no remote login requirements. Perhaps I want to require that all executables that the package installs be started with a limited set of POSIX capabilities.
Why is this a big deal? Because it's technically possible to produce a sandbox that will let me run and poke at code from a random person on IRC. But no package managers currently do so. It's technically possible to ensure that more SUID binaries don't pop up on my system -- since SUID binaries are one of the few potential security holes on a UNIX system, I'd like to avoid installing any if possible -- but I cannot do so. It's technically possible to force all installed binaries to run SUID/SGID/chrooted. It's possible to ask that packages not touch any system-critical files -- initscripts, PAM, kernel, etc. Basically, when I recieve an RPM currently, I have two choices. I can su to root and install the RPM, giving the install script and package complete and total control over the system. Any malicious stuff in the package or bugs could blow away my system. I can try installing the thing with a different RPM database as a user with different prefixes, but it's a royal pain. I can choose not to install the package. And those are my only real options.
When you have piles of packages (source or binary) hosted on single servers run by the same group of people, you're making yourself a really tempting target.
You know, you probably *are* right -- the FSF's archives didn't get broken into for no reason.
However, I think that other avenues are more appealing.
Think about the number of packages in a typical Linux distro. There are a lot -- I currently have about eleven hundred packages installed. Assume that each project has an average of two people with CVS commit access. Many projects do not have rigorous revies of all commits. If someone can compromise the computer of *any* of these 2200 developers and slip a subtle hole in. If someone can submit a patch with a hard-to-find hole, how likely is it that they can manage to slip it in eventually? If they do an anonymous submission, they can keep hammering software projects with evil patches. I have no idea who maintains, say, gkrellm, but how do I know that he's good at ensuring that UNIX software is secure and back-door-free?
Red Hat probably puts a phenomenal amount of work into securing their distribution servers. A single developer's workstation would be a lot easier to compromise.. Package management is a weakness in that it instroduces a new person with the ability to produce a malicious package -- the packager.
No, the last thing Linux package management needs is more centralization. What we need is *less* centralization.
I cannot agree. Mike, I agree with your technical goals in package management (and respect the work that you've done), but I don't find this to be a security argument. A system such as this is weakest-link. Only one system involved in the production, building, and distribution of software must be compromised for the end user's systems to be compromised. More decentralization means more systems to potentially be a weakest link.
What Linux package management needs to be more secure is for projects to host their own binary packages as they do for source packages. That way if/when breakins occur, the damage is at least limited.
Mmmf. I can't agree. At least with the RH/Fedora model, there is a long (months long) QA process run on the software ahead of time. If software projects have the power to push updates to the masses without QA...they could cause all *kinds* of problems. Currently, they have only the power to push updates to Red Hat.
If software projects provided eDonkey links or similar, so that a cryptographic hash of the file is in the wild, that *would* be one more guarantee of security.
Packagers don't audit the code, you know.
In general, you're right, but RH has pushed security patches to projects before. Bandwidth issues.
Crackers who want a leg up can grab the betas, test in their own labs without revealing their IP addresses to the contest site, keep their results to themselves, and hope nobody else notices the hole before the system is deployed on a few thousand production sites
Their private lab?
Heh.
Do they wear white lab coats, too? And do they have chalkboards? And do they work in half-darkness, and have lots of green blinky lights? Does their lab have a big red hologram projector?
Blanket statements about crackers are impossible to make. Crackers vary as much as people that use computers vary. The technically most competent crackers are probably systems people working in security. There are a lot of hobbyists with a serious interest in security.
Yes, but high-profile cracker contests are easy to sell to PHBs. Heck, I don't care. RH does a decent job WRT basic security, and if this will sway a couple of PHBs from using Windows seats, I say that this marketing campaign will actually have had a positive impact on Internet security.
Folks in the security industry are hardly going to care much one way or another about Red Hat's latest ad campaign. They know how Red Hat has done. They aren't going to be particularly interested in OBSD's "remote root in N years" claim, because, yes, I can make a no remote root system too, by running a minimal box. They know the good points and the bad points of the system *already*, and they frequently aren't the high-profile claims made.
How many car nuts are likely to care what the latest ad campaign for a particular company says? Nothing, because they care about the product, not the ad compaign.
This isn't as common as the ones I've mentioned above, but it's worthwhile in that I suspect fairly security-savvy users might get caught by it (I have, once, in a fortunately benign manner). Windows happens to lock open directories (including those that are current working directories for an application) against movement or deletion. Linux does not do so. 99% of the time, the non-locking this is a really good idea, as the locking has caused all kinds of interesting technical problems. However, access checking takes place at the time one traverses the filesystem into a directory. What this means, among other things, is that if a user has a program with a directory already as its current working directory, and then access control on a parent directory of that directory are changed to prevent a user from entering that directory, the user has already "traversed through" that directory. He will continue to have access, via that program, to the directory in question. So if you decide to remove world access to a directory and then put masses of sensitive files in that directory, and you're a bit paranoid, you might want to run lsof and ensure that nothing already has a subdirectory open.
This usually isn't too bad, but it has an even nastier side effect. *Moving* a directory has a similar effect. If a program moves a CWD into a directory, and that directory is then moved into a chunk of directory structure that the user should not be able to get into, the user can cruise out of the directory and do what he wants with the files on the system.
I ran into this as a rude surprise when I was helping a friend use an FTP server on my system. (Yes, I recommend against FTP use, but it was taking place in a limited environment under closely monitored conditions). I had a directory that he had just entered with his FTP client containing a bunch of files that he was downloading. I moved the directory of stuff back into a subdirectory in my home directory without noticing that he was still logged in and was in the directory with his FTP client. He then went into the parent of the directory he was in. Lo and behold, he had just slipped past my home directory (which had no read or list world privileges), and had free access to all my files. Red Hat maintains a default umask granting read and list privileges to world, probably to make copying files around easy, and so once past the home directory, everything was world-readable and all the directories were world-executable (could be listed).
As I said, this will *probably* not be an issue to most users. However, it is an extremely subtle point that was not immediately apparent to me (and, I suspect, many other people, including security folks with a heavy Windows background). it is very important to any authors of software that might move directories from a world-accessable location to a private location. It is also important to sysadmins that run public UNIX systems.
Lsof is useful for analyzing a box, but you can simply add the -p flag to netstat -- netstat -ntap -- and see the controlling process. Run this command as root, or netstat will only be able to identify the processes you own.
On Red Hat, use chkconfig to set which services start at startup (this is nothing more than a pretty frontend to rename a couple symlinks in/etc/rc.d/rcX.d/).
The first thing you should do on a new box is run whatever update mechanism your distro provider uses. Apt-get update;apt-get upgrade, yum update, whatever. There have probably been holes discovered. If security is more important than fully tested reliability, I'd automatically run the update sequence through cron nightly.
If you're extremely paranoid, run syslog to a second machine. If your main machine gets compromised, you have a nice log.
Major Linux oopses I've seen before:
* When using X11, never ever use "xhost +". )"xhost +local:" is still asking for trouble.) I don't care how much of a good idea it seems like, *don't fucking use it*. Don't even do it if you aren't on a network and don't think anyone will ever connect to you. This disables all authentication to X11, and at one point a lot of university hackers (old school) used this when they wanted to run a program from another system. Do not do this. If you're running su'ed as root and root can't display a window on the local X11 server due to lack of authorization, use "xauth merge ~[username logged into X]/.Xauthority". That'll just grab the magic authorization cookie for this session from the local user's auth file and hand it to root, so that root can continue to work. Note that recent releases of Red Hat (perhaps due to changes in XFree86, perhaps due to something clever in root's login scripts) seem to authorize root to poke at local displays. Without this, anyone on the Internet with any inclination can sniff your keyboard, dump your screen, send input to your programs, and generally has full privileges of anyone that uses the X server.
* When using X11 programs from a remote system, use ssh and use X11 tunneling. If you don't do so, your keystrokes will cruise over the network unencrypted.
* Use ssh protocol 2 in preference to 1 unless you are damn sure that doing so is not a good idea (or you want to use protocol 2 only). This is probably already default for your site.
The above two points can be implemented by adding the following to your ~/.ssh/config -- this is what I use:
Host * Protocol 2,1 ForwardX11 yes
* Don't use FTP. We have scp for a reason. FTP sends passwords in plaintext.
* Don't use plaintext mail authentication. Too many people send out their mail password in plaintext. Someone with a 802.11b-capable laptop and sniffer on a college campus can grab *masses* of email passwords from someone's copy of Outlook trying to grab new mail every ten minutes. Most places with a competent mail admin support at *least* support MD5-hashed passwords (which still exposes your email to anyone listening on your network segment, but is better than nothing in that they can't also get your password). I use fetchmail with SSL enabled.
* (not a vulnerability, just a tip) Most Linux distros today are reasonably secure in terms of enabled services out of box. Used to be, in the Red Hat 5.x era, that finger and telnetd enabled out of box was entirely reasonable. Today, however, many folks don't know how to disable services, and so most distributions ship with things off instead of on.
* Archive your logs (generally, the contents of/var/log). You back up your data, right? (If not, you *will* lose your data one day, and *will* be a sad camper trying to rebuild everything you've ever created that you didn't want to spend thirty cents on a CDR backing up). Include your logs in your backup procedure.
* This isn't a Linux-specific suggestion, but use gpg. Linux is one of the few platforms with free mail clients
Yes, I'd expect it to be a real pain in the ass to get X working. The structure of X is really awful from the standpoint of a secure system. (This is not to say that XFree86 is particularly insecure, but that current implementations of this type of software aren't particularly secure).
Among the other security issues with XFree86:
* Runs as root. On UNIX, this is a big sin. On traditional UNIX systems, and still with most Linux systems (POSIX capabilities are one way around this), root can do anything. If you can compromise XFree, you can compromise anything. Not only that, but XFree does not drop privileges -- the whole damn thing runs with elevated privilege.
* Any user that sits down locally can use the thing. It's easy to interface with.
* By default, most systems listen for incoming connections. If you can exploit the auth system, you control a root daemon remotely.
* There are many ways to authorize to the thing (xauth, xhost, etc). It is easy to turn off authorization, and many people (disturbingly many) do so.
* There are many ways to communicate with the thing (UNIX domain sockets, TCP). XFree is not small and simple and easy to check for flaws.
* XFree talks directly to hardware. Aside from the OS, it mucks with all kinds of things that might be exploitable.
* XFree is a major attack path for monitoring user input.
* XFree is responsible for displaying a login screen (and accepting username and password).
* XFree does not natively encrypt remote connections, though many people now use ssh's tunneling abilities.
* XFree is decidedly vulnerable to traffic analysis.
XFree is pretty bad from a security standpoint, and almost anathema to a trusted system. That's not a stab at XFree -- many decisions have been made in favor of simplicity, stability, and performance, and lots of other remote access systems aren't great from a security standpoint either. If X had been built as a secure system, it'd be a lot less usable for general purpose stuff. It would be the single thing that I would first remove from a system that *must* remain secure.
Theoretically, if common sense were removed from the picture, you could build some nasty contracts using this mechanism. IANAL.
For example, produce a contract where party A gets item 1 from party B and party B gets item 2 from party A. Include a severability clause. Then, include a subtle element in the portion of the contract where party A gets item 1 ensuring that that portion is illegal. Thus, party B would be contractually entitled to item 2 without having to give anything else up.
Sex for any purpose other than reproduction is expressly prohibited by Christianity.
Boy, Christian sects have done an awful job of marketing recently if this is the popular view of 'em.
Maybe in some kind of whacked out Puritanical sects where pleasure is seen as a sin, "sex for any purpose other than reproduction" might be unacceptable, but not in mainstream Christianity. Christianity places restrictions on sex, sure. Adultry is a no-no. Homosexuality is a no-no. Sex for enjoyment? No problem. Hell, one of the fundamental ideas behind the Reformation was that sexual needs need to be recognized. Martin Luther felt that trying to force priests to be celibate was stupid and not working -- you had a Pope that picked up prostitutes and gay Italian priests. Humans have human desires, and trying to suppress them is a dead end.
* Prescedent. This is a biggie, or has at least been cited as a big worry by the industry. What happens if people get *comfortable* pirating media over P2P? It's a social move that would be very, very difficult to reverse (view cigarettes -- extremely difficult to excise from society after having been introduced).
* The elimination of certain forms of marketing-driven sales. One of the largest United States macroeconomic benefits is the world's best marketing system. Yes, engineers like to insult marketers, but when it comes down to it, the fact that we can sell Elvis in Mongolia is why Western-produced products are valued so highly, and why so much wealth has been brought into the United States. In the past, it has been possible to sell relatively poor content very well with effective marketing, because one is able to ensure that people are unfamiliar with the product that they are buying until after they buy it. Furthermore, (for movie companies in particular) controlling the format in which viewers see content for the first time can be very important in shaping impressions and building word-of-mouth. If they see it in a darkened movie theater on a big screen with surround sound, they may weight it more favorably than the things they see on their old Zenith on VHS at home. If someone sees a poor-quality rip of The Matrix and doesn't pick up on all the fine CG detail, they may have a significantly lower opinion of the movie. First impressions translate into word-of-mouth, which translate into sales.
* Control is a big deal. The ability to produce a few higher-priced limited edition releases can be lucrative.
Here, in NYC --that's even if you are really a resident-- won't find bestiality displayed, that's Federal crime we are talking about.
I don't believe that selling beastiality pornography is a crime, though I could be wrong.
The production of such material *could*, depending upon the material, probably get someone nailed for cruelty to animals.
Selling pornography containing underage models, however, *is* a crime (not sure whether it's a federal crime, but if not, it's at least universal across the states).
There are a number of fixes for this. The first is the obvious -- only get crabby about people on different class Cs. Or class Bs. I doubt most providers move people over more than a class B, but a class B is also (under the somewhat bogus assumption of even IP usage distribution) only 1/65536th of the available IPs on the Internet. If a password leaks, it's pretty likely that a lot of people are using it.
You could even be a bit more sophisticated, and do whois queries on the IP addresses (note: cap those queries so you don't beat the daylights out of the WHOIS servers). If things are coming from a different netblock, you could get suspicious.
You can also block based on bandwdith (really, even if it's just one person with an incredibly high bandwidth system, you're still losing money). When you combine this with a system that allows a certain number of out-of-netblock requests each day, I suspect that things aren't that bad.
If you liked getting stomped on by powerful defensive units and the enemy commander and handing the enemy a mass of metal on their doorstep, then yes, you could rush.
Great AI that can actually defend itself a bit. Meaning not stand there and get hammered by artitarrly or soldiers attacking tanks and thanks attacking soldiers.
Yeah, TA wasn't perfect here, though it compares well to what other computer RTSes can do.
True 3D terrain and the use of it. Make hills and valleys important
TA does this. Probably to an unrealistic extent (are future engagements even likely to use artillery?) but it really is more fun with a lot of emphasis placed on terrain.
Large maps. You know I can hardly think of any military engagements in wich it took the soldiers a few minutes to run from one end of the battle field to another.
True, true. TA does this. It'd be interesting to see what it'd be like with even *longer* range weapons. The ranges in TA are *much* larger than in most other RTSes (how many games have weapons that can shoot at things seven screens away?), but it's still, frankly, relative small-scale compared to what a real game would be like. And is there some reason that buildings need to be scaled down? From a gameplay standpoint, it seems like accurately-sized buildings are feasible.
Frontlines. Call me silly but it is usual practive to have rings of defence around the homebase. I want to be able to make a line on the map that troops will defend.
Agreed. I think TA came closest in terms of overarching orders, but I'd still like more. "Defend this area" "Ambush anyone coming through this area", "repair any damaged units in this group when not in combat", "attempt to fall back from any enemy units at 80% health", etc.
Proper artilary. Strange as it may sound artilarry does not target tanks. It targets an area. TA allowed this and it was devastating against the computer as it would constantly march its troops accross the same line and you could just pound any assault with a few guns.
Hmm. I agree, but while not realistic, it may be good for gameplay. Conventionally, it is pretty difficult to maintain the integrity fixed positions, if both sides have advanced weaponry. Buildings are pretty much sitting ducks. Tanks can chew buildings to shreds. TA let bases be *built* and construction occur, which is not realistic for the immediate vicinity of battle, but which is traditional for the RTS genre. Ensuring that buildings are a bit tougher to wipe out than in real life is pretty much necessary -- you wouldn't have your aircraft factory half a mile away from enemy ground units supported by aircraft in real life (or if you did, you wouldn't for long), but TA tries to allow you to do so.
Yeah, Close Combat is fun too. Man, I wish Blizzard had never started the whole micromanagement dumbed-down-gameplay kick. I'd like a slower-moving but more complicated game, closer to a traditional strategy game.
Close Combat having a slower gameplay pace and a more individual unit system,
Somebody else that loves Close Combat? Wow! Not many people seem to play that game...
Just out of curiosity, anyone manage to get Close Combat (any of them) running under any version of WINE? I've come close, and even sat down once to try implementing some missing code, but never finished.
* First, the original game featured characters that were mechanical. They had flat surfaces. They were easy to model well with few polygons. TA:Kingdoms did not, and *nobody* had a computer that could run it well at the time of release (I didn't even *remotely* come close and couldn't even try to play it.J)
* Secondly, nobody seemed to get excited about the game. It's hard to describe. TA matches had someone screaming and laughing at the same time "you *bastard*" as someone pulled off a slick tactical manuver. The people I watched playing TA:Kingdoms just kind of sat there and mechanically clicked away.
The vast unit count, as you pointed out, may have been an issue. The control of sizeable forces was a neat part of TA.
I don't think Starcraft's story was an issue. TA did well, and had little story. It didn't have fleshed out characters, and it didn't have Kerrigan's sultry voice or lots of character art. All the TA production resources went into gameplay-relevant things. The only potential exception was the fantastic John Williamsesque music that got much more frantic and rapid during battles -- but it had so much impact on the mood of players that I'd still call it significant to the in-game enjoyment.
Where are the real RTS players. TA barly was a blink in RTS's players minds. The only ones who remember it fondly are the non-RTS players.
If your definition of "real RTS players" is "group of people who read Blizzard marketing output like fiends", then you are correct.
There were a *lot* of fans of TA. I know not a single person who I have in person mentioned TA to and not recieved a positive "yeah, that was a great game". (Note that this does not apply to the much, much less good TA:Kingdoms.)
TA had no personality.
Not really any way I can argue with that, since that's a pretty contentless argument.
It didn't have Blizzard-style "heroes" if that is what you meant. It was closer to a traditional strategy game, with less focus on cinematics. The sort of people that like Close Combat are the sort of people that liked TA -- the ability to give overarching commands. Blizzard made micromanagement and the ability to micromanage large numbers of units the key skill in their RTSes (and designed an interface that deliberately made it difficult to do so). Tactics, other than straight rock-paper-scissors, were much more limited in Blizzard titles.
It was bland, the games were longs (3h battles due to the insane power of Defence).
If what you mean is that tank rushes didn't work very well in TA...yeah, you might have a point. I suspect that most players viewed that as a good thing.
Tell us TA 2 is coming and you'll get a collective "Meh" from all of us.
I see more fond memories of TA on Slashdot than I do of Starcraft, frankly. TA was significantly more evolved in terms of engine sophistication. Starcraft made height and cover matter very little (simply a straight set of probability modifiers to hit). TA modeled arcs of shots, and required intelligent deployment and construction of bases. The landscape played a more significant role in TA. Games never devolved into simple "I grabbed one more resource at the start than you have, so I've won" matches.
Yes. I've probably spent at least 40 hours (probably much more than that, but I'm pretty comfortable claiming 40 hours) playing Halo on the X-Box, in single player, co-op, and competitive modes.
I have also played it on the PC, though not all the way through.
Oh, and their vehicle control method is utterly broken no matter what version you choose - vaguely steer where the camera is looking - yeah, good one.
I cannot agree. It is very, very different from conventional driving games -- "fly by wire" is not the standard mode of operation for any driving game that I know of -- but while it is very different, it's also quite enjoyable once you've played it a bit.
Slashdot Mirror
Because HPUX is funny. Reading the code compatibility requirements for Mozilla with my friends and picking out all the places that special provisions had to be made to address horrendous flaws in HPUX that all other *IX systems are years beyond is much more funny than reading a Dilbert comic.
The right thing to do is to keep the resolution high and increase the font size.
Note that much of this is a problem specific to the Windows API -- it doesn't deal too well with resizing all the fonts. There's too much pixel-level positioning.
GTK apps tend to do a better job.
When someone goes to a porn site for the first time, I imagine they'd spend a couple hours checking out everything that's there. Imagine if they went over their limit the first time they went to the site? I doubt they'd renew, even after their usage of the site goes down for the rest of the month.
If we're talking about multi-thousand-dollar bandwidth bills going to the porn company on a single account, then there is excess downloading beyond one person just wanting to download a lot of movies. The cap can be high, sure. It might be 500GB/month (which is probably a *lot* more liberal than it needs to be). However, if someone is downloading the equivalent of 400 full length extremely high-quality movies a month, something is definitely wrong. I think that it's possible to be lax enough to allow even the most rabid of downloaders and still solid enough to catch passwords getting posted to major forums like USENET.
Erring on the side of generosity is certainly a good idea -- I just want to point out that some degree of sanity checking on bandwidth is *definitely* a good thing, though you may need to set the caps to taste for the site that you're developing.
Darn, I forgot to include the tidbit that I really *did* want to include, given who you are.
There is a way that Linux packaging could be used to improve security. Current state-of-the-art Linux packaging systems pretty much operate in "install as root". There's a script run that runs as root and has the ability to do anything. It would be helpful if, packages could contain a standard way of denoting the privileges that a package requires to be installed. (A package manager could place restrictions on what is allowed.) Package managers currently provide very minimal or nonexistant sandboxing capabilities.
For example, perhaps I do not want to allow an installer to create any SUID files, since I don't want more floating around on my system. Perhaps I want to prevent an installer from modifying any existing files, and only adding the files specified in the package requirements. Perhaps I want to *require* that all executable files be SUID/SGID a new user with no remote login requirements. Perhaps I want to require that all executables that the package installs be started with a limited set of POSIX capabilities.
Why is this a big deal? Because it's technically possible to produce a sandbox that will let me run and poke at code from a random person on IRC. But no package managers currently do so. It's technically possible to ensure that more SUID binaries don't pop up on my system -- since SUID binaries are one of the few potential security holes on a UNIX system, I'd like to avoid installing any if possible -- but I cannot do so. It's technically possible to force all installed binaries to run SUID/SGID/chrooted. It's possible to ask that packages not touch any system-critical files -- initscripts, PAM, kernel, etc. Basically, when I recieve an RPM currently, I have two choices. I can su to root and install the RPM, giving the install script and package complete and total control over the system. Any malicious stuff in the package or bugs could blow away my system. I can try installing the thing with a different RPM database as a user with different prefixes, but it's a royal pain. I can choose not to install the package. And those are my only real options.
When you have piles of packages (source or binary) hosted on single servers run by the same group of people, you're making yourself a really tempting target.
You know, you probably *are* right -- the FSF's archives didn't get broken into for no reason.
However, I think that other avenues are more appealing.
Think about the number of packages in a typical Linux distro. There are a lot -- I currently have about eleven hundred packages installed. Assume that each project has an average of two people with CVS commit access. Many projects do not have rigorous revies of all commits. If someone can compromise the computer of *any* of these 2200 developers and slip a subtle hole in. If someone can submit a patch with a hard-to-find hole, how likely is it that they can manage to slip it in eventually? If they do an anonymous submission, they can keep hammering software projects with evil patches. I have no idea who maintains, say, gkrellm, but how do I know that he's good at ensuring that UNIX software is secure and back-door-free?
Red Hat probably puts a phenomenal amount of work into securing their distribution servers. A single developer's workstation would be a lot easier to compromise.. Package management is a weakness in that it instroduces a new person with the ability to produce a malicious package -- the packager.
No, the last thing Linux package management needs is more centralization. What we need is *less* centralization.
I cannot agree. Mike, I agree with your technical goals in package management (and respect the work that you've done), but I don't find this to be a security argument. A system such as this is weakest-link. Only one system involved in the production, building, and distribution of software must be compromised for the end user's systems to be compromised. More decentralization means more systems to potentially be a weakest link.
What Linux package management needs to be more secure is for projects to host their own binary packages as they do for source packages. That way if/when breakins occur, the damage is at least limited.
Mmmf. I can't agree. At least with the RH/Fedora model, there is a long (months long) QA process run on the software ahead of time. If software projects have the power to push updates to the masses without QA...they could cause all *kinds* of problems. Currently, they have only the power to push updates to Red Hat.
If software projects provided eDonkey links or similar, so that a cryptographic hash of the file is in the wild, that *would* be one more guarantee of security.
Packagers don't audit the code, you know.
In general, you're right, but RH has pushed security patches to projects before.
Bandwidth issues.
Crackers who want a leg up can grab the betas, test in their own labs without revealing their IP addresses to the contest site, keep their results to themselves, and hope nobody else notices the hole before the system is deployed on a few thousand production sites
Their private lab?
Heh.
Do they wear white lab coats, too? And do they have chalkboards? And do they work in half-darkness, and have lots of green blinky lights? Does their lab have a big red hologram projector?
Blanket statements about crackers are impossible to make. Crackers vary as much as people that use computers vary. The technically most competent crackers are probably systems people working in security. There are a lot of hobbyists with a serious interest in security.
Yes, but high-profile cracker contests are easy to sell to PHBs. Heck, I don't care. RH does a decent job WRT basic security, and if this will sway a couple of PHBs from using Windows seats, I say that this marketing campaign will actually have had a positive impact on Internet security.
Folks in the security industry are hardly going to care much one way or another about Red Hat's latest ad campaign. They know how Red Hat has done. They aren't going to be particularly interested in OBSD's "remote root in N years" claim, because, yes, I can make a no remote root system too, by running a minimal box. They know the good points and the bad points of the system *already*, and they frequently aren't the high-profile claims made.
How many car nuts are likely to care what the latest ad campaign for a particular company says? Nothing, because they care about the product, not the ad compaign.
Warez.phantom.com is one of the largest warez archives around. If you manage to get in, there are some phenomenal goodies waiting for you.
;-)
I'd also suggest taking a look at (try pinging, for instance) the following systems:
0x7f.1
There's a pretty good chance that you might even be able to get pings back from the following system:
0177.031415
IP is a wild and hairy world, and we barely touched on name resolution.
This isn't as common as the ones I've mentioned above, but it's worthwhile in that I suspect fairly security-savvy users might get caught by it (I have, once, in a fortunately benign manner). Windows happens to lock open directories (including those that are current working directories for an application) against movement or deletion. Linux does not do so. 99% of the time, the non-locking this is a really good idea, as the locking has caused all kinds of interesting technical problems. However, access checking takes place at the time one traverses the filesystem into a directory. What this means, among other things, is that if a user has a program with a directory already as its current working directory, and then access control on a parent directory of that directory are changed to prevent a user from entering that directory, the user has already "traversed through" that directory. He will continue to have access, via that program, to the directory in question. So if you decide to remove world access to a directory and then put masses of sensitive files in that directory, and you're a bit paranoid, you might want to run lsof and ensure that nothing already has a subdirectory open.
This usually isn't too bad, but it has an even nastier side effect. *Moving* a directory has a similar effect. If a program moves a CWD into a directory, and that directory is then moved into a chunk of directory structure that the user should not be able to get into, the user can cruise out of the directory and do what he wants with the files on the system.
I ran into this as a rude surprise when I was helping a friend use an FTP server on my system. (Yes, I recommend against FTP use, but it was taking place in a limited environment under closely monitored conditions). I had a directory that he had just entered with his FTP client containing a bunch of files that he was downloading. I moved the directory of stuff back into a subdirectory in my home directory without noticing that he was still logged in and was in the directory with his FTP client. He then went into the parent of the directory he was in. Lo and behold, he had just slipped past my home directory (which had no read or list world privileges), and had free access to all my files. Red Hat maintains a default umask granting read and list privileges to world, probably to make copying files around easy, and so once past the home directory, everything was world-readable and all the directories were world-executable (could be listed).
As I said, this will *probably* not be an issue to most users. However, it is an extremely subtle point that was not immediately apparent to me (and, I suspect, many other people, including security folks with a heavy Windows background). it is very important to any authors of software that might move directories from a world-accessable location to a private location. It is also important to sysadmins that run public UNIX systems.
Lsof is useful for analyzing a box, but you can simply add the -p flag to netstat -- netstat -ntap -- and see the controlling process. Run this command as root, or netstat will only be able to identify the processes you own.
/etc/rc.d/rcX.d/).
/var/log). You back up your data, right? (If not, you *will* lose your data one day, and *will* be a sad camper trying to rebuild everything you've ever created that you didn't want to spend thirty cents on a CDR backing up). Include your logs in your backup procedure.
On Red Hat, use chkconfig to set which services start at startup (this is nothing more than a pretty frontend to rename a couple symlinks in
The first thing you should do on a new box is run whatever update mechanism your distro provider uses. Apt-get update;apt-get upgrade, yum update, whatever. There have probably been holes discovered. If security is more important than fully tested reliability, I'd automatically run the update sequence through cron nightly.
If you're extremely paranoid, run syslog to a second machine. If your main machine gets compromised, you have a nice log.
Major Linux oopses I've seen before:
* When using X11, never ever use "xhost +". )"xhost +local:" is still asking for trouble.) I don't care how much of a good idea it seems like, *don't fucking use it*. Don't even do it if you aren't on a network and don't think anyone will ever connect to you. This disables all authentication to X11, and at one point a lot of university hackers (old school) used this when they wanted to run a program from another system. Do not do this. If you're running su'ed as root and root can't display a window on the local X11 server due to lack of authorization, use "xauth merge ~[username logged into X]/.Xauthority". That'll just grab the magic authorization cookie for this session from the local user's auth file and hand it to root, so that root can continue to work. Note that recent releases of Red Hat (perhaps due to changes in XFree86, perhaps due to something clever in root's login scripts) seem to authorize root to poke at local displays. Without this, anyone on the Internet with any inclination can sniff your keyboard, dump your screen, send input to your programs, and generally has full privileges of anyone that uses the X server.
* When using X11 programs from a remote system, use ssh and use X11 tunneling. If you don't do so, your keystrokes will cruise over the network unencrypted.
* Use ssh protocol 2 in preference to 1 unless you are damn sure that doing so is not a good idea (or you want to use protocol 2 only). This is probably already default for your site.
The above two points can be implemented by adding the following to your ~/.ssh/config -- this is what I use:
Host *
Protocol 2,1
ForwardX11 yes
* Don't use FTP. We have scp for a reason. FTP sends passwords in plaintext.
* Don't use plaintext mail authentication. Too many people send out their mail password in plaintext. Someone with a 802.11b-capable laptop and sniffer on a college campus can grab *masses* of email passwords from someone's copy of Outlook trying to grab new mail every ten minutes. Most places with a competent mail admin support at *least* support MD5-hashed passwords (which still exposes your email to anyone listening on your network segment, but is better than nothing in that they can't also get your password). I use fetchmail with SSL enabled.
* (not a vulnerability, just a tip) Most Linux distros today are reasonably secure in terms of enabled services out of box. Used to be, in the Red Hat 5.x era, that finger and telnetd enabled out of box was entirely reasonable. Today, however, many folks don't know how to disable services, and so most distributions ship with things off instead of on.
* Archive your logs (generally, the contents of
* This isn't a Linux-specific suggestion, but use gpg. Linux is one of the few platforms with free mail clients
Yes, I'd expect it to be a real pain in the ass to get X working. The structure of X is really awful from the standpoint of a secure system. (This is not to say that XFree86 is particularly insecure, but that current implementations of this type of software aren't particularly secure).
Among the other security issues with XFree86:
* Runs as root. On UNIX, this is a big sin. On traditional UNIX systems, and still with most Linux systems (POSIX capabilities are one way around this), root can do anything. If you can compromise XFree, you can compromise anything. Not only that, but XFree does not drop privileges -- the whole damn thing runs with elevated privilege.
* Any user that sits down locally can use the thing. It's easy to interface with.
* By default, most systems listen for incoming connections. If you can exploit the auth system, you control a root daemon remotely.
* There are many ways to authorize to the thing (xauth, xhost, etc). It is easy to turn off authorization, and many people (disturbingly many) do so.
* There are many ways to communicate with the thing (UNIX domain sockets, TCP). XFree is not small and simple and easy to check for flaws.
* XFree talks directly to hardware. Aside from the OS, it mucks with all kinds of things that might be exploitable.
* XFree is a major attack path for monitoring user input.
* XFree is responsible for displaying a login screen (and accepting username and password).
* XFree does not natively encrypt remote connections, though many people now use ssh's tunneling abilities.
* XFree is decidedly vulnerable to traffic analysis.
XFree is pretty bad from a security standpoint, and almost anathema to a trusted system. That's not a stab at XFree -- many decisions have been made in favor of simplicity, stability, and performance, and lots of other remote access systems aren't great from a security standpoint either. If X had been built as a secure system, it'd be a lot less usable for general purpose stuff. It would be the single thing that I would first remove from a system that *must* remain secure.
Can anyone recomend a good lawyer?
No, but there are many effective evil ones.
Theoretically, if common sense were removed from the picture, you could build some nasty contracts using this mechanism. IANAL.
For example, produce a contract where party A gets item 1 from party B and party B gets item 2 from party A. Include a severability clause. Then, include a subtle element in the portion of the contract where party A gets item 1 ensuring that that portion is illegal. Thus, party B would be contractually entitled to item 2 without having to give anything else up.
Sex for any purpose other than reproduction is expressly prohibited by Christianity.
Boy, Christian sects have done an awful job of marketing recently if this is the popular view of 'em.
Maybe in some kind of whacked out Puritanical sects where pleasure is seen as a sin, "sex for any purpose other than reproduction" might be unacceptable, but not in mainstream Christianity. Christianity places restrictions on sex, sure. Adultry is a no-no. Homosexuality is a no-no. Sex for enjoyment? No problem. Hell, one of the fundamental ideas behind the Reformation was that sexual needs need to be recognized. Martin Luther felt that trying to force priests to be celibate was stupid and not working -- you had a Pope that picked up prostitutes and gay Italian priests. Humans have human desires, and trying to suppress them is a dead end.
I think there are other relevant factors:
* Prescedent. This is a biggie, or has at least been cited as a big worry by the industry. What happens if people get *comfortable* pirating media over P2P? It's a social move that would be very, very difficult to reverse (view cigarettes -- extremely difficult to excise from society after having been introduced).
* The elimination of certain forms of marketing-driven sales. One of the largest United States macroeconomic benefits is the world's best marketing system. Yes, engineers like to insult marketers, but when it comes down to it, the fact that we can sell Elvis in Mongolia is why Western-produced products are valued so highly, and why so much wealth has been brought into the United States. In the past, it has been possible to sell relatively poor content very well with effective marketing, because one is able to ensure that people are unfamiliar with the product that they are buying until after they buy it. Furthermore, (for movie companies in particular) controlling the format in which viewers see content for the first time can be very important in shaping impressions and building word-of-mouth. If they see it in a darkened movie theater on a big screen with surround sound, they may weight it more favorably than the things they see on their old Zenith on VHS at home. If someone sees a poor-quality rip of The Matrix and doesn't pick up on all the fine CG detail, they may have a significantly lower opinion of the movie. First impressions translate into word-of-mouth, which translate into sales.
* Control is a big deal. The ability to produce a few higher-priced limited edition releases can be lucrative.
Here, in NYC --that's even if you are really a resident-- won't find bestiality displayed, that's Federal crime we are talking about.
I don't believe that selling beastiality pornography is a crime, though I could be wrong.
The production of such material *could*, depending upon the material, probably get someone nailed for cruelty to animals.
Selling pornography containing underage models, however, *is* a crime (not sure whether it's a federal crime, but if not, it's at least universal across the states).
There are a number of fixes for this. The first is the obvious -- only get crabby about people on different class Cs. Or class Bs. I doubt most providers move people over more than a class B, but a class B is also (under the somewhat bogus assumption of even IP usage distribution) only 1/65536th of the available IPs on the Internet. If a password leaks, it's pretty likely that a lot of people are using it.
You could even be a bit more sophisticated, and do whois queries on the IP addresses (note: cap those queries so you don't beat the daylights out of the WHOIS servers). If things are coming from a different netblock, you could get suspicious.
You can also block based on bandwdith (really, even if it's just one person with an incredibly high bandwidth system, you're still losing money). When you combine this with a system that allows a certain number of out-of-netblock requests each day, I suspect that things aren't that bad.
If you liked getting stomped on by powerful defensive units and the enemy commander and handing the enemy a mass of metal on their doorstep, then yes, you could rush.
Great AI that can actually defend itself a bit. Meaning not stand there and get hammered by artitarrly or soldiers attacking tanks and thanks attacking soldiers.
Yeah, TA wasn't perfect here, though it compares well to what other computer RTSes can do.
True 3D terrain and the use of it. Make hills and valleys important
TA does this. Probably to an unrealistic extent (are future engagements even likely to use artillery?) but it really is more fun with a lot of emphasis placed on terrain.
Large maps. You know I can hardly think of any military engagements in wich it took the soldiers a few minutes to run from one end of the battle field to another.
True, true. TA does this. It'd be interesting to see what it'd be like with even *longer* range weapons. The ranges in TA are *much* larger than in most other RTSes (how many games have weapons that can shoot at things seven screens away?), but it's still, frankly, relative small-scale compared to what a real game would be like. And is there some reason that buildings need to be scaled down? From a gameplay standpoint, it seems like accurately-sized buildings are feasible.
Frontlines. Call me silly but it is usual practive to have rings of defence around the homebase. I want to be able to make a line on the map that troops will defend.
Agreed. I think TA came closest in terms of overarching orders, but I'd still like more. "Defend this area" "Ambush anyone coming through this area", "repair any damaged units in this group when not in combat", "attempt to fall back from any enemy units at 80% health", etc.
Proper artilary. Strange as it may sound artilarry does not target tanks. It targets an area. TA allowed this and it was devastating against the computer as it would constantly march its troops accross the same line and you could just pound any assault with a few guns.
Hmm. I agree, but while not realistic, it may be good for gameplay. Conventionally, it is pretty difficult to maintain the integrity fixed positions, if both sides have advanced weaponry. Buildings are pretty much sitting ducks. Tanks can chew buildings to shreds. TA let bases be *built* and construction occur, which is not realistic for the immediate vicinity of battle, but which is traditional for the RTS genre. Ensuring that buildings are a bit tougher to wipe out than in real life is pretty much necessary -- you wouldn't have your aircraft factory half a mile away from enemy ground units supported by aircraft in real life (or if you did, you wouldn't for long), but TA tries to allow you to do so.
Yeah, Close Combat is fun too. Man, I wish Blizzard had never started the whole micromanagement dumbed-down-gameplay kick. I'd like a slower-moving but more complicated game, closer to a traditional strategy game.
Close Combat having a slower gameplay pace and a more individual unit system,
Somebody else that loves Close Combat? Wow! Not many people seem to play that game...
Just out of curiosity, anyone manage to get Close Combat (any of them) running under any version of WINE? I've come close, and even sat down once to try implementing some missing code, but never finished.
I also bought a copy and then lost my CDs and had to get a copy from a friend.
I went back and played it through (single-player) last month. It's still a blast to play, though I *do* wish they'd update the graphics.
Two things:
* First, the original game featured characters that were mechanical. They had flat surfaces. They were easy to model well with few polygons. TA:Kingdoms did not, and *nobody* had a computer that could run it well at the time of release (I didn't even *remotely* come close and couldn't even try to play it.J)
* Secondly, nobody seemed to get excited about the game. It's hard to describe. TA matches had someone screaming and laughing at the same time "you *bastard*" as someone pulled off a slick tactical manuver. The people I watched playing TA:Kingdoms just kind of sat there and mechanically clicked away.
The vast unit count, as you pointed out, may have been an issue. The control of sizeable forces was a neat part of TA.
I don't think Starcraft's story was an issue. TA did well, and had little story. It didn't have fleshed out characters, and it didn't have Kerrigan's sultry voice or lots of character art. All the TA production resources went into gameplay-relevant things. The only potential exception was the fantastic John Williamsesque music that got much more frantic and rapid during battles -- but it had so much impact on the mood of players that I'd still call it significant to the in-game enjoyment.
Where are the real RTS players. TA barly was a blink in RTS's players minds. The only ones who remember it fondly are the non-RTS players.
If your definition of "real RTS players" is "group of people who read Blizzard marketing output like fiends", then you are correct.
There were a *lot* of fans of TA. I know not a single person who I have in person mentioned TA to and not recieved a positive "yeah, that was a great game". (Note that this does not apply to the much, much less good TA:Kingdoms.)
TA had no personality.
Not really any way I can argue with that, since that's a pretty contentless argument.
It didn't have Blizzard-style "heroes" if that is what you meant. It was closer to a traditional strategy game, with less focus on cinematics. The sort of people that like Close Combat are the sort of people that liked TA -- the ability to give overarching commands. Blizzard made micromanagement and the ability to micromanage large numbers of units the key skill in their RTSes (and designed an interface that deliberately made it difficult to do so). Tactics, other than straight rock-paper-scissors, were much more limited in Blizzard titles.
It was bland, the games were longs (3h battles due to the insane power of Defence).
If what you mean is that tank rushes didn't work very well in TA...yeah, you might have a point. I suspect that most players viewed that as a good thing.
Tell us TA 2 is coming and you'll get a collective "Meh" from all of us.
I see more fond memories of TA on Slashdot than I do of Starcraft, frankly. TA was significantly more evolved in terms of engine sophistication. Starcraft made height and cover matter very little (simply a straight set of probability modifiers to hit). TA modeled arcs of shots, and required intelligent deployment and construction of bases. The landscape played a more significant role in TA. Games never devolved into simple "I grabbed one more resource at the start than you have, so I've won" matches.
Demo some of the controls. God, that game has an awesome command interface I went back and played through it last month. It's *still* a blast to play.
Problem is, chances of them doing a Linux release are nil. Sigh...
Have you tried Halo on the Xbox? No?
Yes. I've probably spent at least 40 hours (probably much more than that, but I'm pretty comfortable claiming 40 hours) playing Halo on the X-Box, in single player, co-op, and competitive modes.
I have also played it on the PC, though not all the way through.
Oh, and their vehicle control method is utterly broken no matter what version you choose - vaguely steer where the camera is looking - yeah, good one.
I cannot agree. It is very, very different from conventional driving games -- "fly by wire" is not the standard mode of operation for any driving game that I know of -- but while it is very different, it's also quite enjoyable once you've played it a bit.