You totally missed the point of PowerShell, then. PowerShell is much more than a CLI; it is a model for automating applications. Applications such as Exchange and VMWare expose commands as PowerShell cmdlets. But unlike bash which cannot operate in-process, PowerShell can actually be used to automate in-application tasks.
In other words, you can create common commands (think GoF command pattern) which can be used on a command line, but which *also* can be used as the backing model commands of a administrative user interface. Because PowerShell is designed so that cmdlets operate in process, integrating cmdlets in a host application and using them to manipulate in-process (in-memory) objects is dead simple.
You cannot do that with bash. Sure, you could create some CLI tools which could operate on serialized objects but using such tools to implement the logic layer of a UI application would be painful - to say the least.
That is an often overlooked point of PowerShell: You do not have to create the same actions twice to support both a UI and a CLI. If you do it right (like VMWare did) you get the benefit of both for the price of one (almost).
As a long-time developer I know a a thing or 2 about Windows API (I started out using Borland OWL and later MFC for those who remember what those were).
I am really impressed with PowerShell and it's reach - the way it can use multiple object-oriented technologies (.NET, WMI and COM) seamlessly to reach into the system. Even as a developer I have had to concede that PowerShell is often a better solution when you want to automate system tasks.
So I am curious: What intended purposes have you tried to use PowerShell for where it fell short?
Unless Im mistaken, powershell is really only being pushed for server use. Its not even bundled with the desktop, you have to install it extra. On the server from 2008 and on, its built in.
PowerShell is an integrated part of Windows since Windows 7. You cannot even uninstall it, since other core functionality depends on it.
The automated troubleshooters, as an example, are written using PowerShell. When the system determines a problem with a NIC it will ask you if it should perform automated troubleshooting and attempt repair. The analysis and repair is a PowerShell script.
I'm sure that the cybercriminals gather at bi-annual conferences and calibrates their attacks to OS market shares: "Ok - OS X is now at 10% so we need 1 out of every 10 attack to target OS X"
Get real.
Nowadays attacks are created for financial gain - not for personal breast-thumping like in the MacOS and DOS/early Windows days.
Imagine the attacker at a shooting range. He can choose between two targets of equal size (equally hard to hit). Each time he hits target A he receives $10. Each time he hits target B he receives $90. He has 100 shots.
What does the attacker do? 1. Targets A with all 100 shots because that's the cool thing to do? 2. Targets B with all 100 shots because that'll maximize his ROI? 3. Take 10 shots at A and 90 shots at B because that's more fair to the targets?
Even if target B is moved further away he will *still* target B each time until it gets 9 times harder to hit than A. Because that's how he maximizes his ROI.
There is no secret sauce in neither OS X nor Linux which prevents attacks. Indeed, battle-hardened Windows sports many more and more efficient anti-exploit features than any of them.
The old "but Windows users still run as administrators" hasn't been true since Vista, and even before that it was really only true for home users. Nowadays even if you log in using your administrator account you are still not running as an administrator. Unlike Linux/OS X Windows actually has fine-grained user and process tokens and when you log in a special token is created for you which is stripped of admin privileges. All processes you start will by default run with such a stripped token. What happens when you "elevate" (the UAC prompt) is that your non-stripped token is associated with the process being elevated.
This is what most OS X and Linux users don't get about Windows: Even when you log in as an administrator you are still not running as an administrator.
As with many things with Windows, it seems that the problem of restarts after updates is a problem that Microsoft are aware of, and indeed have provided a solution to...but for some reason people (and Microsoft themselves!) don't seem to use it.
You said it.
Although at least Word, Excel, Outlook, IE do use it. Access 2007 half-way.
Chrome (my favorite browser) also seems to support it.
More importantly most system services use it to restart the service instead of the full system following an update which means that network drivers, graphics drivers etc. are updated without reboots and without stopping GUI applications.
That said, I feel that such "update" functionality could have been integrated deeper into the system, for instance using snapshots instead of the "pending renames/moves" functionality which replaces files during boot.
Seems to me adding features to the package system that can determine and possibly correct such things (ie, closing Firefox or Thunderbird) would be the better way to go rather than force me to have to reboot.
In the case of Firefox it may seem simple to just stop/start the application when updating. But what about an application which is more rich on transient state, uncommitted/unsaved state such as word processors, drawing programs, accounting/invoicing etc. Wouldn't it be nice if the state was not lost just because of an update, or at least restored after the update?
Only the application knows what state it holds in memory and how to save it. I believe that the "during-boot" point of installation is due to the fact that the state of applications at that time is very, very well-defined (and in none). It is the second best solution, but barring a higher-level OS service like the Windows Restart Manager (and applications which adhere to those conventions) the at-boot installation may the the only way to guarantee installations not disrupting system state.
ToasterMonkey is correct: The reason that you usually do not need to restart the system or applications on Linux is the fact that the potential problems of *not* restarting are simply *ignored* on Linux. It's a head-in-the-sand solution.
Most of the time this does not present a problem. It is only when some application uses dynamic or delayed loading (and the suddenly loads an updated and binary incompatible library), uses on-demand loaded resources (what Firefox does) or have other types of dependencies between what sits in memory and what sits on disk.
But there is no secret or magic sauce in Linux which makes this not a pronlem. It is simply assumed that it's not a big problem. But in the case of Firefox this is a regular occurrence. And we all what updating glibc can lead to.
Java will also delay/demand load classes/libraries. Updating to the next version of a Java application while it is running may very well set the running application up for a crash. If a library/class has not yet been loaded (or has been evicted), the risk is that updating the disk files will lead to an incompatible class being loaded when it is required. While designing with backwards-compatibility in mind is good style, it is not reasonable to expect that the developer foresees all of the problems and complexities this can lead to.
The same situation exists for binary modules and other types of runtime environments. As software is getting more complicated techniques such as dynamically or delay loaded libraries/resources, object serialization which depend on a specific binary format, pre-compiled scripts etc. all risk running afoul of the head-in-the-sand mentality.
What is needed is a way for applications or services to register that they depend on certain files. The application may very well be able to survive (or even encourage) updating some of the files during normal operating (think plug-ins). But other files are expected to *not change* beneath the application. This is a reasonable expectation, but only the application (developer) can tell the update process which files it is ok to change on the fly and which files really only should be changed while the application or system is offline.
At this time there is no way for applications or background processes to tell the Linux system or an installer what it should do prior to and after updating certain files. Individual updates may be written to look for certain processes it considers in-risk - but that is really getting it backwards.
Windows has had the Restart Manager (http://msdn.microsoft.com/en-us/library/windows/desktop/cc948910(v=vs.85).aspx) since Vista. Applications, device drivers, system services etc can now register with the RM (for instance all of the files in its directory and certain system wide libraries) and tell it that certain files should not be clobbered during an update/installation if the application is running. When an installer wants to replace a file which has been registered with RM, it can ask (default if using MSI installers) the RM to ask applications with a registered interest if it would be ok to save their state and close. If all applications/services agrees, the RM will then send the actual save+close message to the applications/services. The RM will then relinquish control to the installer which will replace the files. After the installation, the installer invokes the RM again to let it restart all of the applications.
When saving their state the applications/services can register how they want to be restarted to re-establish the state they left, i.e. Word and Excel opens the same documents, Chrome opens the same tabs re-establishing scroll positions etc.
When the RM determines that a file is being held locked by an application which is *not* registered with the RM it backs off and does not ask any apps to stop (it wouldn't know how to ask them to restart). Instead the installer schedules *all* of the files to be replaced "off-line", i.e. you will not have a situation where some of the files have be
...and come to that, the mere fact that a normal user can turn it off suggests it isn't proper security.
regular users CAN NOT turn off UAC. Only administrators can turn it off. When you log in as an administrator (but without admin privileges because UAC stripped those from your token) you can *elevate* (get your admin privileges back) and turn it off. But regular users CAN NOT turn it off. You will be prompted for administrator credentials if you try.
No, UAC doesn't actually stop you doing anything, it just moans about it when you try, and then lets you after it asks if your'e sure. You click yes and carry on. There's a big difference to that and proper security.
If you don't accept the elevation, your token will not hold administrative privileges and the regular Windows security system will stop you from taking any action which require such privileges. Like changing OS files. You seem to miss the fact that UAC is more than just the UAC *prompt*. You naively assume that is all there is to it, while under the hood it is actually quite sophisticated. For instance, the UAC elevation prompt and several of the control panel applets run in high integrity mode, meaning other lower integrity processes CAN NOT send messages (e.g. controlling the mouse or stuffing keyboard buffer) to the high integrity level process.
How would you feel about UAC being the only thing protecting your checking account? "I see you're not the account holder. Are you REALLY sure you want to transfer its entire balance to another account?"
What a stupid question. How do you feel about Linux only protecting the *tools* and not the actual operations? How do you feel about Linux actually *caching* your sudo password so that *any operation* following the first one can silently take advantage of your credentials? How do you feel about a tool secretly launching and transferring your money out of your account, even without a prompt? Just because it could use cached credentials?
The only thing I did was turn UAC off because its (still) so stupidly annoying any right-minded person cant live with it on.
And then you proceed you to complain that Windows doesn't stop you from modifying OS files? UAC was designed to let *you* be the administrator but not *run* as an administrator unless you explicitly consent to do so.
Switching UAC off is stupid. You can certainly do so, but then you lose any right to complain about the "missing" security. It is like complaining that running under a limited account gives you access denied to OS files and then insist on running as an administrator. And then complain that you can now do anything.
If you had just [b]left Windows in it's default state[/b] it would have stopped you from modifying OS files. yet you *change* the default and proceed to proclaim that Windows "Windows by default" doesn't stop you?
You as a normal windows user by default have sufficient rights to modify or delete files in the OS.
Not true for Windows. Since the very first version of Windows/NT regular users never had rights to modify or delete OS files. That was a Windows 9x problem. The problem with desktop versions of Windows (for home users) was that the *default account* was an *administrator* account - not a "normal windows user" as per your claim.
In the context of this discussion you have to consider Windows deployed in *enterprise* settings. In enterprises users log on with normal user accounts and *do not* hold rights to change the OS.
Since Windows Vista, even logging in with an administrator account, the token is *stripped* of admin rights and the such a user does *not* have the right to modify or delete OS files. By going through UAC elevation, a new process can be created without the stripping of admin power rights. Unlike Linux/Unix this elevation does not grant the process more rights than what was originally assigned to the account (but stripped at log-on).
A sudo "elevation" in Linux/Unix is based on SUID root and runs *totally unrestricted*. At that point it is the executable that is the barrier for total system compromise, not the rights system. The braindead SUID design is probably the single feature most responsible for root compromises on Linux/Unix. Linux Foundation and kernel.org has not been forthcoming with actual post-mortems and explanations for how their systems could become thoroughly *rooted*. It has been speculated that a user password was compromised, but that does still not explain how a system can go from a compromised user account to actually having a rootkit installed. I would bet money on some kind of SUID vulnerability at play.
When you install an application in windows it ususaly drops files all over everywhere, adds stuff the the registry etc. so ususally extends the operating system itself. There is no partitioning.
No, not true. Applications install in Program Files or Program Files x86. I am not aware of a single, recently modern application which "drops files all over everywhere".
It is true that applications usually also write to the registry as well. But you write as though the registry is a monolith. It is not. Just like the file system there are places where applications write their stuff. There are a number of "root keys": current user (HKCU), users (HKU), classes_root (HKCR), local machine (HKLM), performance data (HKPD) and current config (HKCC). Think of them as root directories of a file system. Everything has its place.
The registry has full ACL security on every single key - much more granular then text config files - and there are large parts where applications can not write or modify.
Furthermore the registry is not a single file. Rather, it is a number of "hives". For instance, Windows only load the current users hive under HKU. Other users hives are not loaded by default, but can be loaded on-demand under HKU. The registry is a very efficient hierarchical database with transactional support and redundancy and fail-over built in.
1. Proper CLI. Enough is enough, just fucking give up and port zsh and ship the OS with a suite of unix-like CLI tools.
Ahem, zsh doesn't hold a candle to PowerShell. PowerShell being truly object oriented ties in much better with Windows than any unix-like shell ever could. Already it is much more powerful than even the feature-rich zsh. Instead of special case galore, PowerShell has more generic features and very high consistency.
Examples of generic features: Commands do not have switches or options to control their output, like e.g. ls or ps. Instead PowerShell includes a few "formatting", output and conversion cmdlets such as Format-List, Format-Table, ConvertTo-Csv, Out-GridView. You know, back to the "commands should do one thing good and one thing only". Why would commands to navigate the file system need to have output options?
Another example of how PowerShell simplifies through generic features: Through providers external hierarchies can be mapped to a PowerShell "drive" where you can then use the very same cmdlets to navigate and manipulate it (cd, ls, rm). This is not the Unix "map everything to a file" idea; the items in the hierarchy are still very much their own types which may expose their own properties and methods and often have their own access control. Yes, you can now "cd" into the registry or the cert store and manipulate the objects using familar and consistent commands.
And Windows 8 will come with PowerShell 3 which sports workflows. This allows robust, suspendable and resumable scripts which can even script across machine restarts. This is not the Unix "suspend process" - this is actually suspending to disk and resumed days later or may be even resumed on a *different* machine, still picking up the state, variables and progress from when it was suspended.
While they're at it, kill the drive letters and switch to using slashes in paths.
Uhm. Between Libraries and PowerShell that's pretty much done. After libraries drive letters don't really matter any more. And PowerShell allows both backwards and forward slashes.
2. Full blown native PDF support, like in Linux and Mac OS X.
Yeah, well.
3. SSH
OpenSSH exists for Windows. You can use PowerShell across SSH, but PowerShells built-in remoting features (based on WinRM) are much more powerful, for instance multiple remote sessions (not just piping to/from a remote shell but actually marshalling stuff such as return codes, exceptions, progress and events back to the controlling console so that it can be meaningfully scripted), fan-out remoting (executing same script block on multiple remote hosts simultaneously and consolidating the results back to the controlling console), implicit remoting (importing commands of a remote session to create "local" commands which will implicitly execute on the remote host) etc.
If you're using.NET (any.NET language) MSDN Document Writers will fall from the sky to assassinate you if you write an SQL query without using SqlCommand and Parameters.
I wouldn't dream of using SqlCommand any more. I've always hated how verbose those are, how you have to "add" the parameters. They actually make writing secure code harder (exatctly like PHP) and will lead some developers to just fall back to string concatenation (PHP is a little worse in this regard as it makes synthesizing the string *much* easier with string interpolation).
In.NET one should use LINQ. Use Entity Framework - even if you will not build up an entire model. Or use NHibernate. Just use something where you can query using LINQ.
Aaa.... No it's not. There is a defensive termination clause(I will be corrected if I'm wrong...) in Microsoft's grant, but not in Oracle's.
There is a termination clause:
If you file, maintain, or voluntarily participate in a patent infringement lawsuit against a Microsoft implementation of any Covered Specification, then this personal promise does not apply with respect to any Covered Implementation made or used by you.
I.e. you can sue Microsoft for infringement of your own patents by SQL Server or Windows, but if you sue claiming that one of the specifications/implementations covered under the open specification promise infringes your patents, Microsoft reserved their right to countersue you for infringement of the same specifications.
This is a standard defensive mechanism. Sun/Oracle has one as well:
b. With respect to any patent claims owned by Sun and covered by the license granted under subparagraph 2, whether or not their infringement can be avoided in a technically feasible manner when implementing the Specification, such license shall terminate with respect to such claims if You initiate a claim against Sun that it has, in the course of performing its responsibilities as the Specification Lead, induced any other entity to infringe Your patent rights.
c. Also with respect to any patent claims owned by Sun and covered by the license granted under subparagraph 2 above, where the infringement of such claims can be avoided in a technically feasible manner when implementing the Specification such license, with respect to such claims, shall terminate if You initiate a claim against Sun that its making, having made, using, offering to sell, selling or importing a Compliant Implementation infringes Your patent rights.
If you were to rely on these specifications for a product you are building, it actually benefits you that there is a defensive mechanism in there to deter against crippling lawsuits.
So, not much difference. Standard defensive mechanism in the common interest of the users of the products.
Generics: C#/.NET has reified generics which are validated at class load time and (unlike Java) does not require typecasts at runtime. That's performance advantage every time a generic method is used. Furthermore, generics can be realized using primitive/value types which will. That will add up to a performance advantage when using generics with primitive/value type parameters because of 1) one level of indirection saved and 2) less pressure on the garbage collector.
Arrays: C# has true rectangular arrays in addition to arrays-of-arrays. Java only has arrays-of-arrays. True rectangular arrays will in *some* cases with high random access usage offer a performance advantage over the array-of-arrays model. In other cases rectangular arrays will be slower, so the developer has to consider pros/cons. As with generics, arrays support *value types* - i.e. arrays of simple (struct) types which are allocated inline with the array rather than the arrays containing references to class instances. The latter incurs a performance overhead when dereferencing array items compared to inlined items. Depending on the size of the structs and the usage patterns (how much they are copied around) it may allow for performance gains as well.
Pointers: Unsafe code directly manipulating pointers (pointer arithmetic). Can allow substantial performance gains at the expence of type safety.
I will add myself:
P/Invoke - especially when creating a layer directly on top of an OS which will frequently need to use that OS - allows for a much more direct path to system functions. P/Invoke. Much less glue code and fewer rituals are needed when invoking base platform functions.
Since Windows uses a common event queue to post information to all windows, and that event queue goes all the way to the bone in the OS (it is the same event queue that, say, asynchronous IO events are returned with), the windows cannot be de-realized, they can only be hidden.
Yes, that is a problem. In Windows 95. Time to hone up on your skills. The NT line has always had separate queues for each process.
I haven't written any code using these functions (I doubt many people have) but they are there.
Correct. It is used by Windows itself for the logon/lock screen, for the "switch user" (since XP) feature and since Vista for the elevation prompt. The latter is a security feature designed to isolate the prompt so that processes cannot trick the user into clicking the "ok" button.
I've actually used that API to create a program which could restrict my sons computer usage. When 3hrs had passed the desktop would switch to a "warning desktop" telling him his time was up. It could then switch back to his game with only minimal interruption, allowing him to conclude before the "block" desktop turned up and/or the computer shut down. (As it turns out I never actually deployed it as I believe more in offering alternative quality time and brokering agreements. It worked much better. But the geek in me needed to explore it).
You will also notice that it allocates "the desktop" from "the shared heap common to all desktops". This is an example of how the Window archetecture useses common intermingled resources all the way to the bone, as I stated. One of hte reasons that Wndows is so poor at security is that these common resource pools let programs "peek over the fence" or "toss data over the fence" at each other.
You need to read up on Windows handles. Like other operating systems (yes, Linux, Unix, OS X) the operating system is responsible for allocating certain types of resources. In kernel space. Some of these types are to central that they are allocated from a *pool*.
However, that does NOT mean that other processes automatically gain access to other processes' resources. The Windows API is built around *handles*, not pointers, to objects. A handle carries with it the access level for the *owner* of the handle. A handle bridges user space and kernel space. In kernel space it actually just indexes the memory location of the object along with a jump table specific to the owner (process) of the handle.
Each type of kernel object has a number of actions/methods which can be used to interact with it, like switch to a desktop or write to a file. Access level for a process is determined at the time where the handle is created by opening/creating the object or by duplicating another handle. The process asks for fine-grained access level - sometimes object type specific operations. In the kernel, the operations are represented by methods on the object and what results is a handle in kernel space where some method entries of the jump table point to the actual operations where other method entries point to "access denied". Note how the same kernel object may be referenced by multiple handles each with its own separate jump table (a virtual method table in C++ parlance)
This allows much finer grained security than Linux/Unix while at the same time offers very low overhead from access checks: Access checks are performed when an object is opened, *not* on every invocation like in Linux/Unix. Windows is actually object-oriented to the core. When a Windows handle has been established the access check is merely the kernel following a pointer indirection.
Contrary to your assertion, there is no "peeking" in other processes' objects. The handle table is specific to each process. You invoke a Windows API function by passing the handle to the object on which you want to operate. Windows looks up the handle in the process handle table, looks up the function pointer of the API function and jumps to it. A user level process has no way of injecting other memory pointers into the handle table.
But Windows does allow some neat tricks because of handles. Handles can be passed explicitly to another process (where a new handle is created). For instance, a file can be opened by a parent process with both read and write access. It can then spin up another process running as a restricted user (or lower integrity level) and pass in the handle. The child process which would normally have no way to open that file now receives read/write access from the parent. As you can imagine this is rather neat when trying to contain a process in a sandbox. No need to *elevate* the child process or to temporarily run as root or another more privileges effective user. No shared memory. Just nicely restricted access.
As soon as you release a patch fixing a problem you've given the black hats enough to exploit it if it is exploitable. A simple binary diff should be enough to figure out what was changed and then it's all over. Releasing actual exploit code only lowers the barrier to entry but a small amount.
The Microsoft security partners may also receive actual proof-of-concept code to make it easier for them to create signatures which will help recognize an attack. By receiving actual PoC code the would-be attackers don't even need to reverse engineer anything.
A number of MAPP partners are chinese companies. Given that this was circulating on chinese sites, the chinese MAPP partners should anticipate an upcoming security audit from MS.
What I'm interested in is how well Powershell's object-based architecture works. It seems like the best thing Microsoft could have done under the circumstances, but is there an advantage there? Has anyone here done any serious PS scripting? From what I understand there are constraints on what programs will accept as input, a tradeoff of flexibility for consistency and reliability I suppose. Is that something that linux should adopt?
PowerShell works really, really well (and yes even as a developer I have done some serious PS scripting). The object-oriented pipes are a stroke of genius. But one has to rethink the concept of a "command". We are used to a command being something which reads and/or writes streams of text (or bytes). While such commands are still supported (they are adapted to become commands which read/write sequences of strings), PowerShell define a new command type called cmdlets.
What is usually overlooked entirely when comparing to traditional shells is the fact that cmdlets are executed in-process and the objects being passed through the pipelines are actual memory objects, not serialized objects (although a serialization will happen automatically when using PowerShells remoting features). Why is this important? Because it allows developers to create PowerShell cmdlets for the actions of their application and readily use those cmdlets to implement a GUI.
PowerShell is arguably a good fit for Windows, given that so much of the Windows API and 3rd party applications is exposed through object-oriented APIs (COM,.NET, WMI).
I doubt a similar shell would gain traction in a *nix world where a common object-oriented model does not exist. It would be like playing LEGO without the bricks.
Slashdot Mirror
Only because you don't have bash.
You totally missed the point of PowerShell, then. PowerShell is much more than a CLI; it is a model for automating applications. Applications such as Exchange and VMWare expose commands as PowerShell cmdlets. But unlike bash which cannot operate in-process, PowerShell can actually be used to automate in-application tasks.
In other words, you can create common commands (think GoF command pattern) which can be used on a command line, but which *also* can be used as the backing model commands of a administrative user interface. Because PowerShell is designed so that cmdlets operate in process, integrating cmdlets in a host application and using them to manipulate in-process (in-memory) objects is dead simple.
You cannot do that with bash. Sure, you could create some CLI tools which could operate on serialized objects but using such tools to implement the logic layer of a UI application would be painful - to say the least.
That is an often overlooked point of PowerShell: You do not have to create the same actions twice to support both a UI and a CLI. If you do it right (like VMWare did) you get the benefit of both for the price of one (almost).
As a long-time developer I know a a thing or 2 about Windows API (I started out using Borland OWL and later MFC for those who remember what those were).
I am really impressed with PowerShell and it's reach - the way it can use multiple object-oriented technologies (.NET, WMI and COM) seamlessly to reach into the system. Even as a developer I have had to concede that PowerShell is often a better solution when you want to automate system tasks.
So I am curious: What intended purposes have you tried to use PowerShell for where it fell short?
Unless Im mistaken, powershell is really only being pushed for server use. Its not even bundled with the desktop, you have to install it extra. On the server from 2008 and on, its built in.
PowerShell is an integrated part of Windows since Windows 7. You cannot even uninstall it, since other core functionality depends on it.
The automated troubleshooters, as an example, are written using PowerShell. When the system determines a problem with a NIC it will ask you if it should perform automated troubleshooting and attempt repair. The analysis and repair is a PowerShell script.
I'm sure that the cybercriminals gather at bi-annual conferences and calibrates their attacks to OS market shares: "Ok - OS X is now at 10% so we need 1 out of every 10 attack to target OS X"
Get real.
Nowadays attacks are created for financial gain - not for personal breast-thumping like in the MacOS and DOS/early Windows days.
Imagine the attacker at a shooting range. He can choose between two targets of equal size (equally hard to hit). Each time he hits target A he receives $10. Each time he hits target B he receives $90. He has 100 shots.
What does the attacker do?
1. Targets A with all 100 shots because that's the cool thing to do?
2. Targets B with all 100 shots because that'll maximize his ROI?
3. Take 10 shots at A and 90 shots at B because that's more fair to the targets?
Even if target B is moved further away he will *still* target B each time until it gets 9 times harder to hit than A. Because that's how he maximizes his ROI.
There is no secret sauce in neither OS X nor Linux which prevents attacks. Indeed, battle-hardened Windows sports many more and more efficient anti-exploit features than any of them.
The old "but Windows users still run as administrators" hasn't been true since Vista, and even before that it was really only true for home users. Nowadays even if you log in using your administrator account you are still not running as an administrator. Unlike Linux/OS X Windows actually has fine-grained user and process tokens and when you log in a special token is created for you which is stripped of admin privileges. All processes you start will by default run with such a stripped token. What happens when you "elevate" (the UAC prompt) is that your non-stripped token is associated with the process being elevated.
This is what most OS X and Linux users don't get about Windows: Even when you log in as an administrator you are still not running as an administrator.
As with many things with Windows, it seems that the problem of restarts after updates is a problem that Microsoft are aware of, and indeed have provided a solution to...but for some reason people (and Microsoft themselves!) don't seem to use it.
You said it.
Although at least Word, Excel, Outlook, IE do use it. Access 2007 half-way.
Chrome (my favorite browser) also seems to support it.
More importantly most system services use it to restart the service instead of the full system following an update which means that network drivers, graphics drivers etc. are updated without reboots and without stopping GUI applications.
That said, I feel that such "update" functionality could have been integrated deeper into the system, for instance using snapshots instead of the "pending renames/moves" functionality which replaces files during boot.
Seems to me adding features to the package system that can determine and possibly correct such things (ie, closing Firefox or Thunderbird) would be the better way to go rather than force me to have to reboot.
You mean something like this?
In the case of Firefox it may seem simple to just stop/start the application when updating. But what about an application which is more rich on transient state, uncommitted/unsaved state such as word processors, drawing programs, accounting/invoicing etc. Wouldn't it be nice if the state was not lost just because of an update, or at least restored after the update?
Only the application knows what state it holds in memory and how to save it. I believe that the "during-boot" point of installation is due to the fact that the state of applications at that time is very, very well-defined (and in none). It is the second best solution, but barring a higher-level OS service like the Windows Restart Manager (and applications which adhere to those conventions) the at-boot installation may the the only way to guarantee installations not disrupting system state.
ToasterMonkey is correct: The reason that you usually do not need to restart the system or applications on Linux is the fact that the potential problems of *not* restarting are simply *ignored* on Linux. It's a head-in-the-sand solution.
Most of the time this does not present a problem. It is only when some application uses dynamic or delayed loading (and the suddenly loads an updated and binary incompatible library), uses on-demand loaded resources (what Firefox does) or have other types of dependencies between what sits in memory and what sits on disk.
But there is no secret or magic sauce in Linux which makes this not a pronlem. It is simply assumed that it's not a big problem. But in the case of Firefox this is a regular occurrence. And we all what updating glibc can lead to.
Java will also delay/demand load classes/libraries. Updating to the next version of a Java application while it is running may very well set the running application up for a crash. If a library/class has not yet been loaded (or has been evicted), the risk is that updating the disk files will lead to an incompatible class being loaded when it is required. While designing with backwards-compatibility in mind is good style, it is not reasonable to expect that the developer foresees all of the problems and complexities this can lead to.
The same situation exists for binary modules and other types of runtime environments. As software is getting more complicated techniques such as dynamically or delay loaded libraries/resources, object serialization which depend on a specific binary format, pre-compiled scripts etc. all risk running afoul of the head-in-the-sand mentality.
What is needed is a way for applications or services to register that they depend on certain files. The application may very well be able to survive (or even encourage) updating some of the files during normal operating (think plug-ins). But other files are expected to *not change* beneath the application. This is a reasonable expectation, but only the application (developer) can tell the update process which files it is ok to change on the fly and which files really only should be changed while the application or system is offline.
At this time there is no way for applications or background processes to tell the Linux system or an installer what it should do prior to and after updating certain files. Individual updates may be written to look for certain processes it considers in-risk - but that is really getting it backwards.
Windows has had the Restart Manager (http://msdn.microsoft.com/en-us/library/windows/desktop/cc948910(v=vs.85).aspx) since Vista. Applications, device drivers, system services etc can now register with the RM (for instance all of the files in its directory and certain system wide libraries) and tell it that certain files should not be clobbered during an update/installation if the application is running. When an installer wants to replace a file which has been registered with RM, it can ask (default if using MSI installers) the RM to ask applications with a registered interest if it would be ok to save their state and close. If all applications/services agrees, the RM will then send the actual save+close message to the applications/services. The RM will then relinquish control to the installer which will replace the files. After the installation, the installer invokes the RM again to let it restart all of the applications.
When saving their state the applications/services can register how they want to be restarted to re-establish the state they left, i.e. Word and Excel opens the same documents, Chrome opens the same tabs re-establishing scroll positions etc.
When the RM determines that a file is being held locked by an application which is *not* registered with the RM it backs off and does not ask any apps to stop (it wouldn't know how to ask them to restart). Instead the installer schedules *all* of the files to be replaced "off-line", i.e. you will not have a situation where some of the files have be
...and come to that, the mere fact that a normal user can turn it off suggests it isn't proper security.
regular users CAN NOT turn off UAC. Only administrators can turn it off. When you log in as an administrator (but without admin privileges because UAC stripped those from your token) you can *elevate* (get your admin privileges back) and turn it off. But regular users CAN NOT turn it off. You will be prompted for administrator credentials if you try.
No, UAC doesn't actually stop you doing anything, it just moans about it when you try, and then lets you after it asks if your'e sure. You click yes and carry on. There's a big difference to that and proper security.
If you don't accept the elevation, your token will not hold administrative privileges and the regular Windows security system will stop you from taking any action which require such privileges. Like changing OS files. You seem to miss the fact that UAC is more than just the UAC *prompt*. You naively assume that is all there is to it, while under the hood it is actually quite sophisticated. For instance, the UAC elevation prompt and several of the control panel applets run in high integrity mode, meaning other lower integrity processes CAN NOT send messages (e.g. controlling the mouse or stuffing keyboard buffer) to the high integrity level process.
How would you feel about UAC being the only thing protecting your checking account? "I see you're not the account holder. Are you REALLY sure you want to transfer its entire balance to another account?"
What a stupid question. How do you feel about Linux only protecting the *tools* and not the actual operations? How do you feel about Linux actually *caching* your sudo password so that *any operation* following the first one can silently take advantage of your credentials? How do you feel about a tool secretly launching and transferring your money out of your account, even without a prompt? Just because it could use cached credentials?
The only thing I did was turn UAC off because its (still) so stupidly annoying any right-minded person cant live with it on.
And then you proceed you to complain that Windows doesn't stop you from modifying OS files? UAC was designed to let *you* be the administrator but not *run* as an administrator unless you explicitly consent to do so.
Switching UAC off is stupid. You can certainly do so, but then you lose any right to complain about the "missing" security. It is like complaining that running under a limited account gives you access denied to OS files and then insist on running as an administrator. And then complain that you can now do anything.
If you had just [b]left Windows in it's default state[/b] it would have stopped you from modifying OS files. yet you *change* the default and proceed to proclaim that Windows "Windows by default" doesn't stop you?
I mean, how clueless can you be? Sheesh!
You as a normal windows user by default have sufficient rights to modify or delete files in the OS.
Not true for Windows. Since the very first version of Windows/NT regular users never had rights to modify or delete OS files. That was a Windows 9x problem. The problem with desktop versions of Windows (for home users) was that the *default account* was an *administrator* account - not a "normal windows user" as per your claim.
In the context of this discussion you have to consider Windows deployed in *enterprise* settings. In enterprises users log on with normal user accounts and *do not* hold rights to change the OS.
Since Windows Vista, even logging in with an administrator account, the token is *stripped* of admin rights and the such a user does *not* have the right to modify or delete OS files. By going through UAC elevation, a new process can be created without the stripping of admin power rights. Unlike Linux/Unix this elevation does not grant the process more rights than what was originally assigned to the account (but stripped at log-on).
A sudo "elevation" in Linux/Unix is based on SUID root and runs *totally unrestricted*. At that point it is the executable that is the barrier for total system compromise, not the rights system. The braindead SUID design is probably the single feature most responsible for root compromises on Linux/Unix. Linux Foundation and kernel.org has not been forthcoming with actual post-mortems and explanations for how their systems could become thoroughly *rooted*. It has been speculated that a user password was compromised, but that does still not explain how a system can go from a compromised user account to actually having a rootkit installed. I would bet money on some kind of SUID vulnerability at play.
When you install an application in windows it ususaly drops files all over everywhere, adds stuff the the registry etc. so ususally extends the operating system itself. There is no partitioning.
No, not true. Applications install in Program Files or Program Files x86. I am not aware of a single, recently modern application which "drops files all over everywhere".
It is true that applications usually also write to the registry as well. But you write as though the registry is a monolith. It is not. Just like the file system there are places where applications write their stuff. There are a number of "root keys": current user (HKCU), users (HKU), classes_root (HKCR), local machine (HKLM), performance data (HKPD) and current config (HKCC). Think of them as root directories of a file system. Everything has its place.
The registry has full ACL security on every single key - much more granular then text config files - and there are large parts where applications can not write or modify.
Furthermore the registry is not a single file. Rather, it is a number of "hives". For instance, Windows only load the current users hive under HKU. Other users hives are not loaded by default, but can be loaded on-demand under HKU. The registry is a very efficient hierarchical database with transactional support and redundancy and fail-over built in.
1. Proper CLI. Enough is enough, just fucking give up and port zsh and ship the OS with a suite of unix-like CLI tools.
Ahem, zsh doesn't hold a candle to PowerShell. PowerShell being truly object oriented ties in much better with Windows than any unix-like shell ever could. Already it is much more powerful than even the feature-rich zsh. Instead of special case galore, PowerShell has more generic features and very high consistency.
Examples of generic features: Commands do not have switches or options to control their output, like e.g. ls or ps. Instead PowerShell includes a few "formatting", output and conversion cmdlets such as Format-List, Format-Table, ConvertTo-Csv, Out-GridView. You know, back to the "commands should do one thing good and one thing only". Why would commands to navigate the file system need to have output options?
Another example of how PowerShell simplifies through generic features: Through providers external hierarchies can be mapped to a PowerShell "drive" where you can then use the very same cmdlets to navigate and manipulate it (cd, ls, rm). This is not the Unix "map everything to a file" idea; the items in the hierarchy are still very much their own types which may expose their own properties and methods and often have their own access control. Yes, you can now "cd" into the registry or the cert store and manipulate the objects using familar and consistent commands.
And Windows 8 will come with PowerShell 3 which sports workflows. This allows robust, suspendable and resumable scripts which can even script across machine restarts. This is not the Unix "suspend process" - this is actually suspending to disk and resumed days later or may be even resumed on a *different* machine, still picking up the state, variables and progress from when it was suspended.
While they're at it, kill the drive letters and switch to using slashes in paths.
Uhm. Between Libraries and PowerShell that's pretty much done. After libraries drive letters don't really matter any more. And PowerShell allows both backwards and forward slashes.
2. Full blown native PDF support, like in Linux and Mac OS X.
Yeah, well.
3. SSH
OpenSSH exists for Windows. You can use PowerShell across SSH, but PowerShells built-in remoting features (based on WinRM) are much more powerful, for instance multiple remote sessions (not just piping to/from a remote shell but actually marshalling stuff such as return codes, exceptions, progress and events back to the controlling console so that it can be meaningfully scripted), fan-out remoting (executing same script block on multiple remote hosts simultaneously and consolidating the results back to the controlling console), implicit remoting (importing commands of a remote session to create "local" commands which will implicitly execute on the remote host) etc.
If you're using .NET (any .NET language) MSDN Document Writers will fall from the sky to assassinate you if you write an SQL query without using SqlCommand and Parameters.
I wouldn't dream of using SqlCommand any more. I've always hated how verbose those are, how you have to "add" the parameters. They actually make writing secure code harder (exatctly like PHP) and will lead some developers to just fall back to string concatenation (PHP is a little worse in this regard as it makes synthesizing the string *much* easier with string interpolation).
In .NET one should use LINQ. Use Entity Framework - even if you will not build up an entire model. Or use NHibernate. Just use something where you can query using LINQ.
t = (symbol,)
c.execute('SELECT * FROM stocks WHERE symbol=?', t)
Or
var t = "string";
db.Stocks.Where( s => s.symbol == t );
Simple, concise, strongly typed, safe, LINQ
It's about marketshare.
No it is not. It is about yield.
Two things have been happening over the past years
* OS X has increased in market share
* Windows and apps running on Windows have grown
Aaa.... No it's not. There is a defensive termination clause(I will be corrected if I'm wrong...) in Microsoft's grant, but not in Oracle's.
There is a termination clause:
I.e. you can sue Microsoft for infringement of your own patents by SQL Server or Windows, but if you sue claiming that one of the specifications/implementations covered under the open specification promise infringes your patents, Microsoft reserved their right to countersue you for infringement of the same specifications.
This is a standard defensive mechanism. Sun/Oracle has one as well:
If you were to rely on these specifications for a product you are building, it actually benefits you that there is a defensive mechanism in there to deter against crippling lawsuits.
So, not much difference. Standard defensive mechanism in the common interest of the users of the products.
I'm not the GP but he may have been referring to
Generics: C#/.NET has reified generics which are validated at class load time and (unlike Java) does not require typecasts at runtime. That's performance advantage every time a generic method is used. Furthermore, generics can be realized using primitive/value types which will. That will add up to a performance advantage when using generics with primitive/value type parameters because of 1) one level of indirection saved and 2) less pressure on the garbage collector.
Arrays: C# has true rectangular arrays in addition to arrays-of-arrays. Java only has arrays-of-arrays. True rectangular arrays will in *some* cases with high random access usage offer a performance advantage over the array-of-arrays model. In other cases rectangular arrays will be slower, so the developer has to consider pros/cons. As with generics, arrays support *value types* - i.e. arrays of simple (struct) types which are allocated inline with the array rather than the arrays containing references to class instances. The latter incurs a performance overhead when dereferencing array items compared to inlined items. Depending on the size of the structs and the usage patterns (how much they are copied around) it may allow for performance gains as well.
Pointers: Unsafe code directly manipulating pointers (pointer arithmetic). Can allow substantial performance gains at the expence of type safety.
I will add myself:
P/Invoke - especially when creating a layer directly on top of an OS which will frequently need to use that OS - allows for a much more direct path to system functions. P/Invoke. Much less glue code and fewer rituals are needed when invoking base platform functions.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa374177(v=vs.85).aspx
Group Policies is what sets IE apart from other browsers in the enterprise. But the Group Policy API is open and available to anyone.
You are not suggesting that Microsoft should write GPO plugins for *other* browsers, are you?
I do not believe you are correct regarding Windows.
Indeed. He is dead wrong. His info is more than a decade out of date.
Since Windows uses a common event queue to post information to all windows, and that event queue goes all the way to the bone in the OS (it is the same event queue that, say, asynchronous IO events are returned with), the windows cannot be de-realized, they can only be hidden.
Yes, that is a problem. In Windows 95. Time to hone up on your skills. The NT line has always had separate queues for each process.
I haven't written any code using these functions (I doubt many people have) but they are there.
Correct. It is used by Windows itself for the logon/lock screen, for the "switch user" (since XP) feature and since Vista for the elevation prompt. The latter is a security feature designed to isolate the prompt so that processes cannot trick the user into clicking the "ok" button.
I've actually used that API to create a program which could restrict my sons computer usage. When 3hrs had passed the desktop would switch to a "warning desktop" telling him his time was up. It could then switch back to his game with only minimal interruption, allowing him to conclude before the "block" desktop turned up and/or the computer shut down. (As it turns out I never actually deployed it as I believe more in offering alternative quality time and brokering agreements. It worked much better. But the geek in me needed to explore it).
You will also notice that it allocates "the desktop" from "the shared heap common to all desktops". This is an example of how the Window archetecture useses common intermingled resources all the way to the bone, as I stated. One of hte reasons that Wndows is so poor at security is that these common resource pools let programs "peek over the fence" or "toss data over the fence" at each other.
You need to read up on Windows handles. Like other operating systems (yes, Linux, Unix, OS X) the operating system is responsible for allocating certain types of resources. In kernel space. Some of these types are to central that they are allocated from a *pool*.
However, that does NOT mean that other processes automatically gain access to other processes' resources. The Windows API is built around *handles*, not pointers, to objects. A handle carries with it the access level for the *owner* of the handle. A handle bridges user space and kernel space. In kernel space it actually just indexes the memory location of the object along with a jump table specific to the owner (process) of the handle.
Each type of kernel object has a number of actions/methods which can be used to interact with it, like switch to a desktop or write to a file. Access level for a process is determined at the time where the handle is created by opening/creating the object or by duplicating another handle. The process asks for fine-grained access level - sometimes object type specific operations. In the kernel, the operations are represented by methods on the object and what results is a handle in kernel space where some method entries of the jump table point to the actual operations where other method entries point to "access denied". Note how the same kernel object may be referenced by multiple handles each with its own separate jump table (a virtual method table in C++ parlance)
This allows much finer grained security than Linux/Unix while at the same time offers very low overhead from access checks: Access checks are performed when an object is opened, *not* on every invocation like in Linux/Unix. Windows is actually object-oriented to the core. When a Windows handle has been established the access check is merely the kernel following a pointer indirection.
Contrary to your assertion, there is no "peeking" in other processes' objects. The handle table is specific to each process. You invoke a Windows API function by passing the handle to the object on which you want to operate. Windows looks up the handle in the process handle table, looks up the function pointer of the API function and jumps to it. A user level process has no way of injecting other memory pointers into the handle table.
But Windows does allow some neat tricks because of handles. Handles can be passed explicitly to another process (where a new handle is created). For instance, a file can be opened by a parent process with both read and write access. It can then spin up another process running as a restricted user (or lower integrity level) and pass in the handle. The child process which would normally have no way to open that file now receives read/write access from the parent. As you can imagine this is rather neat when trying to contain a process in a sandbox. No need to *elevate* the child process or to temporarily run as root or another more privileges effective user. No shared memory. Just nicely restricted access.
Currently SSH and VPNs are not known to have this weakness.
Currently, RDP doesn't have this weakness either. It was patched, remember? And SSH has had serious vulns in the past. Not much difference there.
As soon as you release a patch fixing a problem you've given the black hats enough to exploit it if it is exploitable. A simple binary diff should be enough to figure out what was changed and then it's all over. Releasing actual exploit code only lowers the barrier to entry but a small amount.
The Microsoft security partners may also receive actual proof-of-concept code to make it easier for them to create signatures which will help recognize an attack. By receiving actual PoC code the would-be attackers don't even need to reverse engineer anything.
A number of MAPP partners are chinese companies. Given that this was circulating on chinese sites, the chinese MAPP partners should anticipate an upcoming security audit from MS.
What I'm interested in is how well Powershell's object-based architecture works. It seems like the best thing Microsoft could have done under the circumstances, but is there an advantage there? Has anyone here done any serious PS scripting? From what I understand there are constraints on what programs will accept as input, a tradeoff of flexibility for consistency and reliability I suppose. Is that something that linux should adopt?
PowerShell works really, really well (and yes even as a developer I have done some serious PS scripting). The object-oriented pipes are a stroke of genius. But one has to rethink the concept of a "command". We are used to a command being something which reads and/or writes streams of text (or bytes). While such commands are still supported (they are adapted to become commands which read/write sequences of strings), PowerShell define a new command type called cmdlets.
What is usually overlooked entirely when comparing to traditional shells is the fact that cmdlets are executed in-process and the objects being passed through the pipelines are actual memory objects, not serialized objects (although a serialization will happen automatically when using PowerShells remoting features). Why is this important? Because it allows developers to create PowerShell cmdlets for the actions of their application and readily use those cmdlets to implement a GUI.
PowerShell is arguably a good fit for Windows, given that so much of the Windows API and 3rd party applications is exposed through object-oriented APIs (COM, .NET, WMI).
I doubt a similar shell would gain traction in a *nix world where a common object-oriented model does not exist. It would be like playing LEGO without the bricks.
COM
WMI