ever use windows? if you did, you'd know about [windows-key]+F. That's how you do all those searches in explorer.
Good point. I almost had forgotten about all those search options.
batch remaing? get a batch rename utility. Difference between windows explorer and bash here: windows doesn't come bundled with the free utility you need to do batch renaming... and its faster and easier.
Ahem. PowerShell is intrinsically part of Windows 7 / Server 2008R2, is available for XP, Server 2003, Vista and Server2008. For the two latter it is intrinsically part of the OS since SP1.
Batch renaming in PowerShell: ls *.txt | ren -n {$_ -replace '.txt$','.text'}
Microsoft used an Israeli company to develop the actual product hardware. This may be the reason why someone could think that MS just "bought" the entire product. Or it could be an opportunity for./ MS haters to create a myth that MS cannot innovate.
The purpose of UAC is the same as sudo, gives you privileges you wouldn't otherwise have. Turning off UAC would mean you couldn't do anything that required any privileges. What most people think
You are seriously mistaken. User Account Control works by *stripping* your the process token of certain "powerful privileges". UAC does NOT elevate your privileges beyond what is already granted to you through group direct assignments or groups memberships. Once you elevate through an UAC prompt it merely gives you those rights back. That is *very* different from Linux/Unix/sudo where you essentially change effective user to the all-powerful, unrestricted root account.
Think about that for a second. Think about the irony that sudo is actually more like ActiveX (handing over the keys to the kingdom and pray that the visitor is well-behaved) than UAC is. In Windows there is no single all-powerfull account. An administrator account still just holds just the privileges and permissions granted to it, and they can be taken away. In Unix/Linux you have syscalls which just checks for euid == 0 and then passes. Worse, in most distros (Fedora the notable exception) you are actually *forced* to run many processes as SUID processes because privileges cannot be granted.
It is true that the UAC prompt cal *also* be used to run a process as a higher privileged user, but that required the full account name and password to be entered, at which point the process will continue with the new users privileges.
On an architectural level Windows has meaningful process tokens where Linux/Unix has a very simplistic (and inadequate) effective-user system. That's right, Windows process tokens are fine-grained and not restricted to any user account. Privileges (identified by SIDs) can be granted or denied in the token. Groups can be added or removed from the token. In Unix/Linux you will need something like grsecurity or SELinux to achieve the same level of expressiveness. And in Windows it is not bolted-on; actually Windows has had that kind of tokens since the NT 3.5 days.
In fact, the idea MS has been working towards is not logging on to the server at all. Using neither GUI nor CLI locally. Instead they have invested heavily in WBEM, and PowerShell remoting.
The Server Manager and the management console add-ins of RSAT (Remote Server Administration Toolkit) have been offering GUI-like remote administration of servers at least since Server 2003. The Server Manager has matured a lot in 2008 and 2008R2.
PowerShell remoting is really powerful: You can already run scripts / script blocks with fan-out remoting, i.e. the same script is executed simultaneously on multiple remote hosts, consolidating the output objects and status responses back to the main script which will automatically synchronize (wait for all hosts to either suceed or fail or timeout before continuing) and consolidate the results with indication of each object's origin.
With Server 8 the Server Manager becomes a tool for administering multiple servers with single operations. The add-ins integrates with PowerShell and you can design fan-out operations right from the user interface, e.g. filter servers by name, selecting a number of servers and add the "webserver" role to all of them at once - which will install the IIS webserver.
If you need to script installations or administration you can use PowerShell. With PowerShell 3 it even comes with workflows (suspendable, resumable on other hosts, scripting across system restarts etc). Still, you can script from a "command server" or workstation through PowerShell remoting or WBEM.
Why has the Linux Foundation not offered an explanation for what went wrong and how the intruders gained access? Specifically, how could the intruders root the servers starting from compromised user credentials as has been alleged?
As I understand it, you can search/filter either XML data streams, or a sequence of.NET objects. Would the way to accomplish this in.NET, then, be to have a commandlet that opens the source file and passes them through as.NET objects?
Indeed. The "extended grep" in PowerShell is the Where-Object (aliases where and ?). It works on a stream of objects; objects in PowerShell's extended type system actually being a superset of.NET objects which can also wrap WMI and COM objects.
The common way in PowerShell to "grep" using where is indeed to read the source as objects. For example to read from an XML document you would cast it to the built-in [xml] type (which is really a wrapper around the.NET System.Xml.XmlDocument type) and then pass select nodes through the where cmdlet.
My sig is an example of a PowerShell command which reads slashdot RSS feed, parses it as xml, selects the "items" xml nodes, filters away the biased postings by kdawson and finally displays the description property in a list.
He probably should have waited until after W8 was released, now they have a chance to patch out all his hard work before anyone gets a chance to make use of it.
Microsoft is already aware of the contents of the entire paper, because he gave it to them.
My guess is that Microsoft is actually quite pleased. It absolutely reinforces their argument *for* UEFI Secure Boot - as this very attack vector is exactly what is being closed by UEFI Secure Boot.
The information *you* are overlooking is that Windows is not tricked into thinking it booted from anywhere. Secure boot is not enforced nor checked by Windows. It is *supported* through its boot loader.
Secure Boot is *supported* by the Windows boot loader by virtue of being digitally signed. No checks from Windows itself.
It is the UEFI firmware which checks the signature of the boot loader. This ensures the integrity of the boot load'er before control is passed to it. The Windows boot load'er in turn checks the integrity of the Windows it is about to boot. This ensures the integrity of Windows before control is passed to it.
This attack is NOT possible with UEFI secure boot. In fact, this is the reason *why* secure boot is necessary.
Windows 8 does not *require* secure boot. Windows 8 does not *require* UEFI. The Windows 8 boot loader is *signed* so that it will support a system with secure boot.
How exactly was this about piracy when Windows 8 can be installed on hardware without UEFI, when Windows 8 can be booted without secure boot, when Windows 8 can be booted through an alternate boot loader?
First, you're missing the whole point. Root kits don't come in through the boot loader. That was the way it was done when DOS was the most used OS. Instead, they either use an exploit against the OS, or simply uses Administrator privileges to hook into the system (many users are still running as Administrator, and those who still have UAC turned on, have no idea when it's ok to click "allow".
You should have followed along then. Windows (the x64 editions) since Vista is using kernel and driver signing. The kernel will *not* load from a cabinet file unless the cabinet is signed with a key trusted by the kernel. Furthermore, the kernel will *not* load a kernel mode driver unless it has been signed using a valid code certificate issued by a trusted issuer (e.g. Verisign).
This means that a rootkit cannot tamper with kernel executable files or cabinet files in order to insert itself during boot. As soon as it changes the content of a cabinet file, the signature will not validate and the kernel will refuse to load it.
So how do one circumvent this? Either by creating a malicious driver and somehow obtain a private key to sign it. One can steal it from an ISV or try to trick the issuer into believing you are a legitimate business. Either of these options rely on a certificate which can be revoked. So, when your malicious code is discovered on a single system, the certificate you used to sign the driver will be revokes and after that your code will not load during boot.
Windows x64 has yet another obstacle: Having your driver with loaded is not enough. You need to hook into the kernel to do your evil thing. But Windows x64 also has online integrity checks. Basically it checksums many/most of its internal tables, and if your driver tampers with them, the periodic integrity checker will halt the system.
Is that someone in the community has realized that even with the ability to import your own keys or switch off secure boot, there is probably a license problem with GPLv3 which will set Linux, BSDs etc at a disadvantage.
To distribute a "signed" GRUB you would be required to make the private key available. Which would undermine the security of Secure Boot and thus there is not a chance that the corresponding public keys could be accepted for distribution with UEFI in new systems.
This is a real security feature, one which will prevent boot sector rootkits which is a threat to *any* operating system. The GPLv3 run afoul of this. This is why FSF wants vendors to implement the draconian "setup mode" scheme.
That is the dirty secret, the taboo: Secure Boot will give a closed source system (or at least a system with secret private keys) a clear security advantage. Rather than coming clean, FSF, Red Hat and Linux Foundation has launched a FUD campaign hoping to stir up enough fear to mandate a considerably worse installation experience for *all buyers* of systems.
In the CSS case the player / player software needed to have the private decryption key. Thus there was always the potential for reverse engineering.
In the case of integrity protection (Secure Boot), the UEFI firmware needs a public key. The corresponding private keys needed for signing the boot loader will live in FIPS certified hardware security modules deep within Microsoft (and other OS / boot loader vendors). A HSM does not allow any private keys to be retrieved, but it will allow signing code/cabinet files if you present the correct number of hardware (USB) keys and passcodes.
He claims that UEFI will magically prevent rootkits from working simply because the BIOS will then be able to detect mangled files. I'm not sure Bott fully understands the purpose of a rootkit, but if one were well designed, UEFI will achieve nothing toward this goal. Indeed, unless UEFI contained signatures for all Windows system files, I'm quite certain that it would be fairly easy for an interested party to circumvent.
Ed Bott is right and you are wrong. You believe "signatures" is hashes (because there is no code signing in Linux?). They are not hashes, code/file signing is based on asymmetric keys for integrity protection and is pretty solid (unless you let Debian developers modify the code for key generation). The UEFI firmware will have a table with approved public keys. Any bootloader and its data will have to be signed with one of the corresponding private keys if secure boot is switched on. The bootload'er vendor can update and distribute a new version as long as he signs the bootload'er. If it works anything like Windows kernel signing (but remember this is a industry UEFI standard not exclusively available to Windows) the signature will protect executable as well as config data etc.
After all, the objective of a rootkit is to hide the rootkit from examination, and running one under UEFI would simply require hooking into the OS at points that the UEFI does not check.
Wrong again. The UEFI secure boot is the last missing link in the secure Windows boot chain. Each step will validate the next one before relinquishing control to it (letting it execute): 1) The UEFI firmware validates the signature of the bootload'er. If the bootload'er has been tampered with UEFI will *not* execute the bootload'er 2) Bootload'er runs, loads OS boot definitions, checks (through signatures again) that they have not been tampered with. If the chosen OS is set to secure boot, the bootload'er checks the OS integrity (through signatures again) before launching the OS. 3) The OS gains control and before loading kernel executables and kernel mode drivers, it checks that they come from signed cabinet files. If they don't the kernel will refuse to load them.
Microsoft did not require that system vendors and motherboard vendors makes it impossible to switch off. Microsoft does not require that their public key is the only one in the system. In order to get the "Designed for Windows 8" sticker they *do* need to 1) enable secure boot by default, 2) pre-register Microsofts public secure boot key, 3) Not provide a programmable interface for switching secure boot on/off and not provide a programmable interface for changing the registered secure boot keys.
There is some FUD speculation about a conspiracy that Microsoft will secretly require the vendors to *enfore* secure boot with Microsofts key exclusively. That would prevent other bootload'ers from loading. This is despite the fact that Microsoft has publicly said that they prefer that vendors do not do this but that they cannot mandate this, as it is ultimately the vendors choice, not Microsofts. In fact, it would hurt Microsoft as it would exclude the enterprise and corporate sector from downgrading to non-secure boot aware OSes like Windows 7, Server 2008/R2 etc.
This issue had the wrong address from the start, and that is what Ed Bott is ranting about. This is about HW vendors, not Microsoft.
Windows 8 will not require secure boot, but will support it. Windows 8 will boot on any machine, secure boot or not. The issue is whether hardware/system vendors will provide the on/off switch *or* allow the key table to be updated by the user. So far not a single hardware vendor has said they will disable the on/off switch, if you disregard the very suspicious claim by Red Hat employees that they "know" one vendor who has "privately and anonymously" declared that they will disallow Linux. Several vendors (Dell, AMI) is now on record for saying that they will allow secure boot to be switched off while others has declared their intention to do so.
Why can't all software do as many of the current web browsers do and remember their state so they can come back up exactly where they were if they are suddenly or even gracefully shut down?
Indeed. There should be some kind of operating system service which could automatically restart any application which were running when the system was shut down. Perhaps it could even interact with them and restore their state such as documents and cursor positions? Oh wait: http://msdn.microsoft.com/en-us/library/aa373524(VS.85).aspx
The restart manager - if used by the application or service - will actually keep track of files which have been scheduled for updating (new version) during restart. If the files are being kept open by an application or service which has registered with Restart Manager, RM can restart the application and avoid a system restart. Note, this replace is transactional - it only replaces a set of files when all files can be closed by restarting processes.
If the processes are closed for some other reason and RM suddenly finds that all the files in a replace set now can be safely replaced, it will proceed to do so. Have you ever noticed that the start menu says that you should restart to install update, only later to find that this notification has mysteriously been removed again? That's Restart Manager jumping in a replacing files.
By what mechanism can a browser know when the memory it has reserved is needed elsewhere in the system? I don't think it works that way.
I don't think that any browsers actually use this, but Windows has since Vista allowed memory to be prioritized. It is used by the various caching algorithms to ensure that even though a memory page has been used for caching, it will be given up instantly when memory is needed by an actual application (allocating with higher priority). When the cache later tries to access the page it will get a page fault. If it then tries to allocate and there is no free or lower-prioritized memory it will simply not allocate more memory. This tends to ensure that the available memory is actually put to good use, without leading to the after-lunch syndrome.
Conceivably a browser or another application which could benefit from caching could take advantage of this system, perhaps choosing a priority for its own cache somewhere between normal memory and the Vista/7 readyboost cache.
So we're back to Windows 1.0 with no overlapping windows? How am I suppose to quickly look at two open applications? or drag and drop items?
The metro UI allows 2 applications, one in a "side strip" mode and another in "full" mode on the screen at the same time. When you hold a tablet in your hands, a swipe from the left edge with your thumb "drag" in the next application (task switching). If you "swipe-and-hold" the next application will not replace the current application, rather it will split the screen and let the new application appear side-by-side with the current. It works remarkably well, actually.
As for the drag and drop items Microsoft has a new take on this which means that you very often will not need to do that in the first place. A swipe from the right edge of the screen towards the center brings in the "charms" panel. This panel contains 5 "charms", one of which is "share". Applications on Windows 8 can register as source or targets or both. If you browse images and want to publish them on Facebook or Flickr, having a Facebook, Flickr or a general "social network" app installed you will see these options when you invoke the "share" charm. What then comes up is a UI driven by the chosen application. This way you can immediately publish images on facebook, email them, MMS them, publish videos on youtube etc.
It works the other way as well. When an application wants to have an image, it can request one. You can then choose to acquire the image from the webcam, from an online site like Flickr or fabebook, from your local harddrive or from a network drive. No need to save the image locally before you can use it.
Windows 8 will *still* offer a "classic" desktop to be used on larger screens. This part is *really* rough around the edges in the preview.
Disclaimer: This was typed on the Samsung tablet issued with Win 8 to attendees of the BUILD conference
The advantage here being...? It sounds like a cool feature, but what would I be doing where I would actually want to have object oriented programming in my shell?
Because you don't need to format as text and parse again. This is cumbersome and brittle process. Scripts based on formatting and reparsing are error prone. All sorts of issues can crop up, like the locale set differently (causing the parsing to misinterpret dates or numbers), distro differences in tool default settings, subtle changes to output formats with new versions or sensitivity to spaces, quotes or other special characters in filenames etc. When you pass objects in PowerShell, datetime values are strongly typed datetime values and consumed as such in the next tool on the pipeline. Filters need not use grep expressions which risk matching more (or less) than intended.
Objects can represent more complex structures, like trees or even graphs of objects. While you *could* come up with a text representation of a tree of objects, in reality only 2 dimensional (rows + columns) are workable with text serialization.
PowerShell is actually intended for more than CLI. The cmdlets pass in-memory objects. Unlike bash, all cmdlets on a PS pipeline execute within the host process can consume, manipulate and produce in-memory objects of the host objects. This is huge, as this enables PS cmdlets and entire pipelines to be the basis of automation in GUI processes. Exchange Server uses this since 2007. In that case it is actually the Exchange Server GUI admin tool which is the PowerShell host. Upon issuing a command in the GUI, it will tell you what the PS pipeline looks like. And you can copy-and-paste it for later execution in a PowerShell CLI.
Most of Windows API is already object-oriented (COM, WMI,.NET). While this is arguably only an advantage on Windows, it does mean that PS can consume and manipulate such objects rather than predominantly monolithic stream-in-out tools. Think how wget can download a page, multiple pages or an entire site, but it is not scriptable during the process. If you want a script to make decisions during the download you will author the script to issue more wget commands based on the output from the previous. If the wget was an object (Net.WebClient in PowerShell) your script can interact with the object while the state is carried over from method invocation to method invocation.
These are just some of the advantages of using objects. There are more, and also some disadvantages, to be sure. But on the whole it allows for much more robust and readable scripting.
Doesn't fucking matter, because theory is not practice.
Windows assigns execute permission based on the last 3 letters by default. It's up to the administrator to change this behavior, which hardly ever happens.
In the world of real computers, execute bits are *completely independent* of the name.
Oh please.
The.exe association is merely a convenience, not a security mechanism which "assigns execute permission" as you put it. It is equivalent to how Linux will attempt to run *anything* when you type the name or double-click it. It is a launching mechanism, not a security mechanism.
Yes, Linux has the x bit. Guess what, Windows ACLs has the Traverse/Execute permission. Remove that permission or set up a deny rule and you will not be able to execute that file or files in that directory. Want to ensure that network shares cannot be used to host executables? Set the permissions on the share to deny execute to everyone and set it to inherit.
Windows has your beloved execute permission. And unlike in Linux you can set up deny rules or allow multiple principals (multiple groups and/or users). Most of us just want it to follow the read permission, because it would never be a security boundary anyway.
And then you completely ignore - no strike that - you try to completely dismiss a very cool security feature in Windows (and OS X): Origin based execution policies. You try to dismiss it because it doesn't look like your x bit. But the fact remains that it works for users: Files downloaded from the internet (through a browser or some other agent) are tainted with the "Internet zone". Files copied from network shares are tainted with "Local intranet zone". And you can set up execution policies to deny or allow execution of such files.
So I have to run AD locally to be able to disallow users to run arbitrary files? Brilliant! Let's f** home users, like we care.
No, that is what Local Security Policy is for. When in a domain, domain GPO takes preference if there are conflicts. But as a home user you can simply use the LSP.
Re:Just so nobody is confused, this post ^^^ is wr
on
Kernel.org Compromised
·
· Score: 2
Second: On Windows it's really hard to disallow users to run any programs but the ones in C:\Windows and C:\Program Files while it's trivially easy in UNIX-like systems.
Ahem.
Start | Administrative tools | Local Security Policy | Software Restriction Policies | New Software Restriction Policy
Was that hard? Btw, an administrator can configure this in a group policy and apply it to select users, groups, computer sets etc. The above was a local policy.
Now you have a policy which by default allows only programs to execute from "program files" and "windows"
You can configure much more, like e.g. whether executables on a given path should be allowed to execute with admin privileges, certificate policies, hash based rules etc.
So using Lambdas and closures as the same thing in conversation makes sense for Java ( and C# ).
Speaking of C#, no, lambdas and closures are definitively *not* the same thing. A C# lambda may be a closure (if it captures any variables from the lexical scope), it may be just a function (if it doesn't close over any variables), or it may be an expression tree which is totally not a closure at all.
Likewise, a closure need not be created through a lambda expression, an anonymous method may also be a closure.
Slashdot Mirror
ever use windows? if you did, you'd know about [windows-key]+F. That's how you do all those searches in explorer.
Good point. I almost had forgotten about all those search options.
batch remaing? get a batch rename utility. Difference between windows explorer and bash here: windows doesn't come bundled with the free utility you need to do batch renaming... and its faster and easier.
Ahem. PowerShell is intrinsically part of Windows 7 / Server 2008R2, is available for XP, Server 2003, Vista and Server2008. For the two latter it is intrinsically part of the OS since SP1.
Batch renaming in PowerShell: ls *.txt | ren -n {$_ -replace '.txt$','.text'}
Project Natal was developed at Microsoft Research Cambridg: http://www.scientificamerican.com/article.cfm?id=microsoft-project-natal
Microsoft used an Israeli company to develop the actual product hardware. This may be the reason why someone could think that MS just "bought" the entire product. Or it could be an opportunity for ./ MS haters to create a myth that MS cannot innovate.
But this was a MSR project all along.
The purpose of UAC is the same as sudo, gives you privileges you wouldn't otherwise have. Turning off UAC would mean you couldn't do anything that required any privileges. What most people think
You are seriously mistaken. User Account Control works by *stripping* your the process token of certain "powerful privileges". UAC does NOT elevate your privileges beyond what is already granted to you through group direct assignments or groups memberships. Once you elevate through an UAC prompt it merely gives you those rights back. That is *very* different from Linux/Unix/sudo where you essentially change effective user to the all-powerful, unrestricted root account.
Think about that for a second. Think about the irony that sudo is actually more like ActiveX (handing over the keys to the kingdom and pray that the visitor is well-behaved) than UAC is. In Windows there is no single all-powerfull account. An administrator account still just holds just the privileges and permissions granted to it, and they can be taken away. In Unix/Linux you have syscalls which just checks for euid == 0 and then passes. Worse, in most distros (Fedora the notable exception) you are actually *forced* to run many processes as SUID processes because privileges cannot be granted.
It is true that the UAC prompt cal *also* be used to run a process as a higher privileged user, but that required the full account name and password to be entered, at which point the process will continue with the new users privileges.
On an architectural level Windows has meaningful process tokens where Linux/Unix has a very simplistic (and inadequate) effective-user system. That's right, Windows process tokens are fine-grained and not restricted to any user account. Privileges (identified by SIDs) can be granted or denied in the token. Groups can be added or removed from the token. In Unix/Linux you will need something like grsecurity or SELinux to achieve the same level of expressiveness. And in Windows it is not bolted-on; actually Windows has had that kind of tokens since the NT 3.5 days.
In fact, the idea MS has been working towards is not logging on to the server at all. Using neither GUI nor CLI locally. Instead they have invested heavily in WBEM, and PowerShell remoting.
The Server Manager and the management console add-ins of RSAT (Remote Server Administration Toolkit) have been offering GUI-like remote administration of servers at least since Server 2003. The Server Manager has matured a lot in 2008 and 2008R2.
PowerShell remoting is really powerful: You can already run scripts / script blocks with fan-out remoting, i.e. the same script is executed simultaneously on multiple remote hosts, consolidating the output objects and status responses back to the main script which will automatically synchronize (wait for all hosts to either suceed or fail or timeout before continuing) and consolidate the results with indication of each object's origin.
With Server 8 the Server Manager becomes a tool for administering multiple servers with single operations. The add-ins integrates with PowerShell and you can design fan-out operations right from the user interface, e.g. filter servers by name, selecting a number of servers and add the "webserver" role to all of them at once - which will install the IIS webserver.
If you need to script installations or administration you can use PowerShell. With PowerShell 3 it even comes with workflows (suspendable, resumable on other hosts, scripting across system restarts etc). Still, you can script from a "command server" or workstation through PowerShell remoting or WBEM.
it is not going away.
Why has the Linux Foundation not offered an explanation for what went wrong and how the intruders gained access? Specifically, how could the intruders root the servers starting from compromised user credentials as has been alleged?
As I understand it, you can search/filter either XML data streams, or a sequence of .NET objects. Would the way to accomplish this in .NET, then, be to have a commandlet that opens the source file and passes them through as .NET objects?
Indeed. The "extended grep" in PowerShell is the Where-Object (aliases where and ?). It works on a stream of objects; objects in PowerShell's extended type system actually being a superset of .NET objects which can also wrap WMI and COM objects.
The common way in PowerShell to "grep" using where is indeed to read the source as objects. For example to read from an XML document you would cast it to the built-in [xml] type (which is really a wrapper around the .NET System.Xml.XmlDocument type) and then pass select nodes through the where cmdlet.
My sig is an example of a PowerShell command which reads slashdot RSS feed, parses it as xml, selects the "items" xml nodes, filters away the biased postings by kdawson and finally displays the description property in a list.
Just wait until Microsoft sees your post and we'll have eeegrep.
No, it would be called Where-Object and have two built-in aliases called where and simply ?.
And then you would be able to write something like ps | ?{$_.cpu -gt 10}
He probably should have waited until after W8 was released, now they have a chance to patch out all his hard work before anyone gets a chance to make use of it.
Microsoft is already aware of the contents of the entire paper, because he gave it to them.
My guess is that Microsoft is actually quite pleased. It absolutely reinforces their argument *for* UEFI Secure Boot - as this very attack vector is exactly what is being closed by UEFI Secure Boot.
The information *you* are overlooking is that Windows is not tricked into thinking it booted from anywhere. Secure boot is not enforced nor checked by Windows. It is *supported* through its boot loader.
Secure Boot is *supported* by the Windows boot loader by virtue of being digitally signed. No checks from Windows itself.
It is the UEFI firmware which checks the signature of the boot loader. This ensures the integrity of the boot load'er before control is passed to it. The Windows boot load'er in turn checks the integrity of the Windows it is about to boot. This ensures the integrity of Windows before control is passed to it.
This attack is NOT possible with UEFI secure boot. In fact, this is the reason *why* secure boot is necessary.
Windows 8 does not *require* secure boot. Windows 8 does not *require* UEFI. The Windows 8 boot loader is *signed* so that it will support a system with secure boot.
How exactly was this about piracy when Windows 8 can be installed on hardware without UEFI, when Windows 8 can be booted without secure boot, when Windows 8 can be booted through an alternate boot loader?
First, you're missing the whole point. Root kits don't come in through the boot loader. That was the way it was done when DOS was the most used OS. Instead, they either use an exploit against the OS, or simply uses Administrator privileges to hook into the system (many users are still running as Administrator, and those who still have UAC turned on, have no idea when it's ok to click "allow".
You should have followed along then. Windows (the x64 editions) since Vista is using kernel and driver signing. The kernel will *not* load from a cabinet file unless the cabinet is signed with a key trusted by the kernel. Furthermore, the kernel will *not* load a kernel mode driver unless it has been signed using a valid code certificate issued by a trusted issuer (e.g. Verisign).
This means that a rootkit cannot tamper with kernel executable files or cabinet files in order to insert itself during boot. As soon as it changes the content of a cabinet file, the signature will not validate and the kernel will refuse to load it.
So how do one circumvent this? Either by creating a malicious driver and somehow obtain a private key to sign it. One can steal it from an ISV or try to trick the issuer into believing you are a legitimate business. Either of these options rely on a certificate which can be revoked. So, when your malicious code is discovered on a single system, the certificate you used to sign the driver will be revokes and after that your code will not load during boot.
Windows x64 has yet another obstacle: Having your driver with loaded is not enough. You need to hook into the kernel to do your evil thing. But Windows x64 also has online integrity checks. Basically it checksums many/most of its internal tables, and if your driver tampers with them, the periodic integrity checker will halt the system.
So, what's left. Contrary to what you believe, the good old bootsector hack is back: http://www.dataprotectioncenter.com/antivirus/sunbelt/how-the-tld4-rootkit-gets-around-driver-signing-policy-on-a-64-bit-machine/. By taking control early on, a rootkit can continuously check for when a know driver/module is loaded and then modify it in memory.
This latter attack vector is precisely what is being addressed by UEFI Secure Boot.
A couple of hardware makers have said they will not be adding an on/off switch.
Yeah? Who?
of Ed Bott being caught lying. You may dislike what he writes and may disagree with his opinions.
But you accused him of *lying*. And you still have to provide evidence of that.
Is that someone in the community has realized that even with the ability to import your own keys or switch off secure boot, there is probably a license problem with GPLv3 which will set Linux, BSDs etc at a disadvantage.
To distribute a "signed" GRUB you would be required to make the private key available. Which would undermine the security of Secure Boot and thus there is not a chance that the corresponding public keys could be accepted for distribution with UEFI in new systems.
This is a real security feature, one which will prevent boot sector rootkits which is a threat to *any* operating system. The GPLv3 run afoul of this. This is why FSF wants vendors to implement the draconian "setup mode" scheme.
That is the dirty secret, the taboo: Secure Boot will give a closed source system (or at least a system with secret private keys) a clear security advantage. Rather than coming clean, FSF, Red Hat and Linux Foundation has launched a FUD campaign hoping to stir up enough fear to mandate a considerably worse installation experience for *all buyers* of systems.
Except common sense, and past experience, which shows that many a vendor will implement as
little of a feature as will get Windows to boot.
Right, so that is why I cannot change BIOS settings. Oh wait...
In the CSS case the player / player software needed to have the private decryption key. Thus there was always the potential for reverse engineering.
In the case of integrity protection (Secure Boot), the UEFI firmware needs a public key. The corresponding private keys needed for signing the boot loader will live in FIPS certified hardware security modules deep within Microsoft (and other OS / boot loader vendors). A HSM does not allow any private keys to be retrieved, but it will allow signing code/cabinet files if you present the correct number of hardware (USB) keys and passcodes.
He claims that UEFI will magically prevent rootkits from working simply because the BIOS will then be able to detect mangled files. I'm not sure Bott fully understands the purpose of a rootkit, but if one were well designed, UEFI will achieve nothing toward this goal. Indeed, unless UEFI contained signatures for all Windows system files, I'm quite certain that it would be fairly easy for an interested party to circumvent.
Ed Bott is right and you are wrong. You believe "signatures" is hashes (because there is no code signing in Linux?). They are not hashes, code/file signing is based on asymmetric keys for integrity protection and is pretty solid (unless you let Debian developers modify the code for key generation). The UEFI firmware will have a table with approved public keys. Any bootloader and its data will have to be signed with one of the corresponding private keys if secure boot is switched on. The bootload'er vendor can update and distribute a new version as long as he signs the bootload'er. If it works anything like Windows kernel signing (but remember this is a industry UEFI standard not exclusively available to Windows) the signature will protect executable as well as config data etc.
After all, the objective of a rootkit is to hide the rootkit from examination, and running one under UEFI would simply require hooking into the OS at points that the UEFI does not check.
Wrong again. The UEFI secure boot is the last missing link in the secure Windows boot chain. Each step will validate the next one before relinquishing control to it (letting it execute): 1) The UEFI firmware validates the signature of the bootload'er. If the bootload'er has been tampered with UEFI will *not* execute the bootload'er 2) Bootload'er runs, loads OS boot definitions, checks (through signatures again) that they have not been tampered with. If the chosen OS is set to secure boot, the bootload'er checks the OS integrity (through signatures again) before launching the OS. 3) The OS gains control and before loading kernel executables and kernel mode drivers, it checks that they come from signed cabinet files. If they don't the kernel will refuse to load them.
Microsoft did not require that system vendors and motherboard vendors makes it impossible to switch off. Microsoft does not require that their public key is the only one in the system. In order to get the "Designed for Windows 8" sticker they *do* need to 1) enable secure boot by default, 2) pre-register Microsofts public secure boot key, 3) Not provide a programmable interface for switching secure boot on/off and not provide a programmable interface for changing the registered secure boot keys.
There is some FUD speculation about a conspiracy that Microsoft will secretly require the vendors to *enfore* secure boot with Microsofts key exclusively. That would prevent other bootload'ers from loading. This is despite the fact that Microsoft has publicly said that they prefer that vendors do not do this but that they cannot mandate this, as it is ultimately the vendors choice, not Microsofts. In fact, it would hurt Microsoft as it would exclude the enterprise and corporate sector from downgrading to non-secure boot aware OSes like Windows 7, Server 2008/R2 etc.
This issue had the wrong address from the start, and that is what Ed Bott is ranting about. This is about HW vendors, not Microsoft.
Windows 8 will not require secure boot, but will support it. Windows 8 will boot on any machine, secure boot or not. The issue is whether hardware/system vendors will provide the on/off switch *or* allow the key table to be updated by the user. So far not a single hardware vendor has said they will disable the on/off switch, if you disregard the very suspicious claim by Red Hat employees that they "know" one vendor who has "privately and anonymously" declared that they will disallow Linux. Several vendors (Dell, AMI) is now on record for saying that they will allow secure boot to be switched off while others has declared their intention to do so.
Why can't all software do as many of the current web browsers do and remember their state so they can come back up exactly where they were if they are suddenly or even gracefully shut down?
Indeed. There should be some kind of operating system service which could automatically restart any application which were running when the system was shut down. Perhaps it could even interact with them and restore their state such as documents and cursor positions? Oh wait: http://msdn.microsoft.com/en-us/library/aa373524(VS.85).aspx
The restart manager - if used by the application or service - will actually keep track of files which have been scheduled for updating (new version) during restart. If the files are being kept open by an application or service which has registered with Restart Manager, RM can restart the application and avoid a system restart. Note, this replace is transactional - it only replaces a set of files when all files can be closed by restarting processes.
If the processes are closed for some other reason and RM suddenly finds that all the files in a replace set now can be safely replaced, it will proceed to do so. Have you ever noticed that the start menu says that you should restart to install update, only later to find that this notification has mysteriously been removed again? That's Restart Manager jumping in a replacing files.
By what mechanism can a browser know when the memory it has reserved is needed elsewhere in the system? I don't think it works that way.
I don't think that any browsers actually use this, but Windows has since Vista allowed memory to be prioritized. It is used by the various caching algorithms to ensure that even though a memory page has been used for caching, it will be given up instantly when memory is needed by an actual application (allocating with higher priority). When the cache later tries to access the page it will get a page fault. If it then tries to allocate and there is no free or lower-prioritized memory it will simply not allocate more memory. This tends to ensure that the available memory is actually put to good use, without leading to the after-lunch syndrome.
Conceivably a browser or another application which could benefit from caching could take advantage of this system, perhaps choosing a priority for its own cache somewhere between normal memory and the Vista/7 readyboost cache.
So we're back to Windows 1.0 with no overlapping windows? How am I suppose to quickly look at two open applications? or drag and drop items?
The metro UI allows 2 applications, one in a "side strip" mode and another in "full" mode on the screen at the same time. When you hold a tablet in your hands, a swipe from the left edge with your thumb "drag" in the next application (task switching). If you "swipe-and-hold" the next application will not replace the current application, rather it will split the screen and let the new application appear side-by-side with the current. It works remarkably well, actually.
As for the drag and drop items Microsoft has a new take on this which means that you very often will not need to do that in the first place. A swipe from the right edge of the screen towards the center brings in the "charms" panel. This panel contains 5 "charms", one of which is "share". Applications on Windows 8 can register as source or targets or both. If you browse images and want to publish them on Facebook or Flickr, having a Facebook, Flickr or a general "social network" app installed you will see these options when you invoke the "share" charm. What then comes up is a UI driven by the chosen application. This way you can immediately publish images on facebook, email them, MMS them, publish videos on youtube etc.
It works the other way as well. When an application wants to have an image, it can request one. You can then choose to acquire the image from the webcam, from an online site like Flickr or fabebook, from your local harddrive or from a network drive. No need to save the image locally before you can use it.
Windows 8 will *still* offer a "classic" desktop to be used on larger screens. This part is *really* rough around the edges in the preview.
Disclaimer: This was typed on the Samsung tablet issued with Win 8 to attendees of the BUILD conference
The advantage here being...? It sounds like a cool feature, but what would I be doing where I would actually want to have object oriented programming in my shell?
These are just some of the advantages of using objects. There are more, and also some disadvantages, to be sure. But on the whole it allows for much more robust and readable scripting.
Doesn't fucking matter, because theory is not practice.
Windows assigns execute permission based on the last 3 letters by default. It's up to the administrator to change this behavior, which hardly ever happens.
In the world of real computers, execute bits are *completely independent* of the name.
Oh please.
The .exe association is merely a convenience, not a security mechanism which "assigns execute permission" as you put it. It is equivalent to how Linux will attempt to run *anything* when you type the name or double-click it. It is a launching mechanism, not a security mechanism.
Yes, Linux has the x bit. Guess what, Windows ACLs has the Traverse/Execute permission. Remove that permission or set up a deny rule and you will not be able to execute that file or files in that directory. Want to ensure that network shares cannot be used to host executables? Set the permissions on the share to deny execute to everyone and set it to inherit.
Windows has your beloved execute permission. And unlike in Linux you can set up deny rules or allow multiple principals (multiple groups and/or users). Most of us just want it to follow the read permission, because it would never be a security boundary anyway.
And then you completely ignore - no strike that - you try to completely dismiss a very cool security feature in Windows (and OS X): Origin based execution policies. You try to dismiss it because it doesn't look like your x bit. But the fact remains that it works for users: Files downloaded from the internet (through a browser or some other agent) are tainted with the "Internet zone". Files copied from network shares are tainted with "Local intranet zone". And you can set up execution policies to deny or allow execution of such files.
So I have to run AD locally to be able to disallow users to run arbitrary files? Brilliant! Let's f** home users, like we care.
No, that is what Local Security Policy is for. When in a domain, domain GPO takes preference if there are conflicts. But as a home user you can simply use the LSP.
Second: On Windows it's really hard to disallow users to run any programs but the ones in C:\Windows and C:\Program Files while it's trivially easy in UNIX-like systems.
Ahem.
Start | Administrative tools | Local Security Policy | Software Restriction Policies | New Software Restriction Policy
Was that hard? Btw, an administrator can configure this in a group policy and apply it to select users, groups, computer sets etc. The above was a local policy.
Now you have a policy which by default allows only programs to execute from "program files" and "windows"
You can configure much more, like e.g. whether executables on a given path should be allowed to execute with admin privileges, certificate policies, hash based rules etc.
So using Lambdas and closures as the same thing in conversation makes sense for Java ( and C# ).
Speaking of C#, no, lambdas and closures are definitively *not* the same thing. A C# lambda may be a closure (if it captures any variables from the lexical scope), it may be just a function (if it doesn't close over any variables), or it may be an expression tree which is totally not a closure at all.
Likewise, a closure need not be created through a lambda expression, an anonymous method may also be a closure.