Yeah. Like Apache.

If your targets use Windows it would be a real stroke of genius to distribute attacks against Linux, don't you think?

Duh.

What is the *nix equivalent to secure boot? Signed kernel modules? What is the *nix equivalent to Measured Boot and Network Access Protection? How does an organization automatically and immediately detect and isolate potentially infected hosts?

Every operating system out there will experience exploitable vulnerabilities. Applications running on top of the operating systems will experience exploitable vulnerabilities. The most recent severe vulnerabilities that have been mass exploited are *nix vulnerabilities like Heartbleed and Shellshock. No operating system is immune.

That's why defense in depth is important. Windows starts it's defenses before boot, by using Secure Boot. This ensures that only approved bootloaders run. It prevents bootkits. Some Linux distros support a weak form of secure boot (it doesn't protect all types of resources, notably scripts and config files are not digitally signed). Windows loads all kernel components from signed "cabinet" files - protecting all assets used during boot. If a rootkit tampers with any of the files, the system will refuse to boot.

During boot, before loading *any* kernel module, Windows will compute a hash of the module and record it in the TPM hardware module along with name, size, dates and other metadata. Upon successful boot (but before other hosts will accept traffic from the system) the OS asks the TPM for a signed "health" record. The TPM will issue a signed document with all the recorded info that the host can present to a health certificate server. The health cert server can investigate the list of loaded modules and compare against known whitelists and/or blacklists. If everything checks out, the health cert server issues a certificate the booting host must use when communicating with other hosts. Unless it can present such cert, the other hosts will refuse to communicate with the host.

Does 'Nix support such security in depth?

Such targeted attacks will target whatever operating system is being used by the target. Targets must consider the possibility that any host can be breached through an application or OS vulnerability. With that recognition, they must ensure expedient diagnosis and isolation. In that area, a Windows server infrastructure can be set up to become extremely strong.

Source? Or just trolling?

It is not a worm. It is a trojan, i.e. the user has to invite the trojan (the "dropper") inside for it to work.

A worm is an automated infection which propagates automatically from system to system. Like the Shellshock worms, Code Red, Nimda.

Any particular reason you chose to call it a worm, despite that it was described as a trojan in the summary as well as in TFA?

All of the current Windows versions are derived from Windows NT. The security model was developed for Windows NT. It is the very same extensible (through SIDs) model that has later been extended for AD and later for UAC (mandatory Integrity Control) in Windows Vista.

Yes - the "dragnet" attacks tends to go after the most victims. If your attack has a certain chance of succeeding (like a social engineering attack), you'd be stupid to go after the 1% instead of the 90%. Now, in a *targeted* attack where the attacker singled out a specific victim or group of victims - the attacker will go after whatever those targets use.

Nope. The current strain of Windows was created from scratch with the present security model from the get-go. The security model is based on tokens and it was designed to be extensible from the start. Also from the start, the designers envisioned that a process or even a thread could have a token *different* from the user token - i.e. a process could run with permissions/privileges different from the user.

The Windows security model also goes beyond the naive file system-focused model where only file system-like objects were seen as important to secure. In Windows - from the start - all system objects (files, directories, windows, processes, threads, shared memory regions, mutexes, users, groups etc) are accessed through object-oriented handles. When you open a handle you specify the access you request, where each object type has it's own access types. The security check is performed right there when opening the object - instead of on each syscall. If the access you request is granted, a system object is created with a jump table (think virtual method table) where the functions you requested access are mapped to the actual system functions, and the other functions mapped to "denied". The upshot of this is that even though Windows has a much more advanced security model which could make security checks more involved, it will usually perform better because it does *not* have to check security permissions on each syscall.

Contrast that with Unix/Linux where the security model initially only considered file system objects. There were only 2 levels: regular users and root, and a large number of functions could only be performed by root. When it was realized that other system types might also need security descriptors, the existing file system was "adapted" by "mapping" non-file system objects to become file system-like. Talk about bolted on!

The Unix/Linux security model is also the only one with a deliberate drilled hole: The SUID/setuid. Here you have a too limited model where regular users are unable to perform perfectly reasonable functions, like changing their own passwords. So what do you do? You let them run as the only user that *can* perform the function, and pray that the process somehow prevents them from performing any of the other functions root can do while running they are running as root. This is a blatant violation of the least privilege principle, but it is now deeply engraved in all Unix systems. Needless to say that this is the most common path for pwning Unix/Linux systems, going all the way back.

The Unix/Linux model was so bad that NSA had to create SELinux (talk about bolted-on!) which creates it's own competing security "context" (a token). When you want to audit the security of a Unix/Linux system you have to consider 3 competing models: 1) The "original" file-system oriented discretionary model with the SUID hole, 2) the sudoers and 3) SELinux/apparmor or whatever has been bolted on the top.

Especially 1) and 2) are worrying, because it is neigh impossible to audit those sufficiently as long as just a single SUID/sudo command is allowed: How do you (as an auditor) know *what* the SUID/sudo command can actually do? Did *you* install the executable, did *you* monitor the compilation from source? What *other* things can ps or even ping do that you don't know about? If I hold up a file or point to a process on your system as asks "who can access this" - you cannot give me a conclusive answer - because the original file system discretionary permissions may not tell the entire story. There may always be a SUID or sudo utility that can access the file *despite* the discretionary access control.

On Windows there are no deliberate holes in the security boundary: If an auditor points to a file or a process or any other object type, you can give a conclusive answer to who can access the object with what access level. It is all in the ACL. If a user is not in that ACL - he cannot access the object.

When considering the desktop it is even worse: Windows actually has meaningful user interface privilege isolation. On Unix/Linux there is *no* isolation. X is about as promiscuous as can be: Any process and snoop on *any* other process keyboard, mouse moves etc. Which means that is an attacker slips by and get to run his code in e.g. Firefox - he can snoop on *anything* you type in *any* window - including terminal where you type sudo or root passwords. Go figure. Windows security model (since Vista) prohibits lower-integrity processes from snooping on higher-integrity processes. Even a normal integrity process cannot snoop on other normal-integrity processes unless a number of conditions are met (it has to declare it's intention in the manifest, it has to be installed in Program Files or System32 etc). And then there's the stupid password caching for sudo...

Shellshock, Heartbleed, ...

Not to mention that a common reason to run Linux is LAMP - The P of which is PHP - the swiss cheese monoculture of web programming languages.

Ahem. It works. Sorta. It's slow, mildly confusing and it totally screws up if you use subrepositories. Looking forward to VS2015.

Question: PowerShell is implemented using .NET. Will we see PowerShell on Linux?

.NET does not rely on the registry, except for some of the COM that will not be ported. In .NET the config files are XML files, e.g. a program called MyStuff.exe will have a config file called MyStuff.exe.config - which must contain XML configuration according to the (extensible) schema. Pretty sweet, actually, if only they would modernize it a bit. I'm hearing that they are doing exactly that - making the config system even more "pluggable".

Config files for server applications can "inherit" base config files: First, the base config file is applied and then the more specific config file. The specific config file can remove, replace, change or add items from configured collections/items, unless explicitly forbidden by the base file.

I'm not the GP and I'm a self-proclaimed C# fan, but: The Java collections seems to have been more well thought out from the beginning with abstract types (interfaces) for different types of collections, such as bag, list, set, stack, queue, vector etc and then concrete implementations with separate characteristics, such as hashed, sorted etc. .NET is catching up, especialy in the 4.x versions, but Java (IIRC) still has proper priority queues that has no equivalent in .NET.

Agreed.

I always found the Java collections a bit stronger conceptually. For instance, it really bothered me that there was no hashed set (there is now), and I had to play tricks with HashTable by using the same value for key and value to mimic a set. It was particularly annoying as I went from C++ to Java to C#. Java seemed to have lifted the collections from STL where they seemed to have been very well designed. C# collections always stroke me as having been "thrown in there". Thankfully they have improved a lot since then.

LINQ cannot be overestimated. Large parts of code is actually manipulating collections, and LINQ is just awesome. Also the fact that C#/.NET generic collections were always properly reified, unlike Javas fake generics (type erasure) which causes all kinds of strange corner cases and problems. C# generic collections allow primitive types to be used for type parameters, and always without performance loss due to runtime downcasting like in Java.

They are: Promissory estoppel. It is like a one-sided contract - i.e. one that you do not have to sign for it to be legally binding for Microsoft.

There is no tide to speak of in Denmark. I'm not sure that we'd classify the sea between the islands (Denmark is basically an island nation) as "oceans". The tides are usually 1m or less, most pronounced in the eastern part facing the North Sea, much less pronounced in the western parts that sits in the Baltic Sea.

But the flat topology and the fact that most of Denmark is islands, there's a *lot* of coastline, and wind is a much preferred as renewable energy source here. I don't think people realize how much it is blowing here. Damned wind!

It is correct that generating most energy from wind runs the risk that prolonged periods with high pressure (which means little wind and clear skies == frezzing cold during winter) can not generate enough wind to meet the demand.

Another problem is that in large parts of Denmark (e.g. the entire Copenhagen metropolitan area) most households get their heating from centralized "surpluss" heat from electricity production - burning coal at the moment.

It is commendable not to waste heat,and as you can probably imagine, Denmark has a huge investment in this centralized heat distribution system.

But I'd like to know, where will we get the heating from once electricity is produced from wind and solar?

Good points. But while the API may not coerce you into writing performant code like (perhaps) the alternatives, it does not make it impossible or practically unobtainable. I will readily admit that I know very little about 3D programming, shaders and the like.

However, modern games are all built upon some form of game engine that in turn is typically used in multiple games. Few game developers write to the API anyway, so if the few (relative to number of games they support) game engines were optimized, wouldn't this difference go away?

Which brings us back to the developers of the game engines: If the developers of the game engines would invest the effort to create engines with high performance on Linux, multiple games would benefit from it immediately. OTOH, if the game engine developers *do not* optimize their code for Linux, there is very, very little actual game developers can do about it, short of creating their own game engine. Which is a monumental task.

Since you so dishonestly quoted text from an article without linking back to it, here is the link: http://www.theguardian.com/wor...

This concerns the "Prism" program - which since the initial bruhaha has been revealed to be little more than an automated way to comply with (presumably) lawful requests from law enforcement agencies. (Note: I strongly disagree with the constitutionality of having a secret court issuing secret orders; it totally undermines the democracy)

The participation in the automated system (aka Prism) does not require a company to comply with more FISA requests, nor does non-participation allow a company to *not* comply with FISA requests. It simply has no bearing on it.

Importantly, the automated system does NOT(!) allow the agencies more access to users' data. Each FISA request will STILL have to be considered on a
case-by-case basis, and lawyers for the company will STILL have to review all material sent to the agency through PRISM before hitting the "send" button.

And conspicuously absent from your quote is the fact that while Microsoft was mentioned in the title, Skype, Apple, Google, Facebook and Yahoo were also mentioned.

Little information is available on the actual design of PRISM, and basically all of the speculation was based on this single slide from the Snowden leak: https://en.wikipedia.org/wiki/...

From that slide you can see that Microsoft was indeed the first company to comply with FISA orders through PRISM, but that Yahoo, Google, Facebook, Paltalk(?), YouTube, Skype, AOL and Apple all followed.

So you are grossly misrepresenting facts, being dishonest and out lying about the information in a transparent attempt to taint Microsoft while letting Google of the hook. Now, why would you do that? Anonymous cowardly liar.

Not to nitpick, but danes refer to that centralized production as "surplus heat". The "surplus" heat is heat generated as a bi-effect from producing electricity.... - from coal. So, when the electricity all comes from wind, the danes need to find some other way to heat their houses during winter.