I mentioned Balmer because he is the main head of the Hydra that Microsoft is. I'm sorry for laying the blame squarely at the feet of the CEO, in future I'll lay the blame a the feet of the guys working in the call centre. Or maybe the lawyers they buy for a dime a dozen.
If you have an issue with the statement, you could mention the statement and the lawyer who it is attributed to, Richard Boscovich. That would suffice. You did not even have to read the article, the name was right there in the (inflammatory) summary.
If you wanted to hand off access to a new process, which had ALL of the permissions of another process, this would work. However, if there were ANY differences at all, you'd have to create a new account, then set up permissions on all of the system resources to match your new desired access for the new account, and then pass along information via inter-process pipes, shared files, etc.
No, not on Windows. Windows has a per-process token and the privileges of that token does not have to match any account at all. The token consists of a list of SIDs which can represent groups (which in turn appear in ACLs) *or* the SIDs represent privileges, e.g. setting time zone, restarting the system, log on as batch service etc. You do *not* need to set up an account with the desired privileges. You just need to prune the token itself.
On Linux there are also "Linux Capabilities" which are a few number of bits which represent capabilities that are not linked to any specific resource. These can even be considered "mini tokens" as they appear in the process descriptor as well. They are poorly implemented, though, and woefully underused.
What you cannot do with Windows process token is represent more advanced (parameterized) privileges such as CPU quota.
It is unfortunate that it's necessary to try to overload an existing term with a new, slightly different definition, but that's what has happened here.
Capabilities in a capability based system (cabsec for short) are fine grained access rights to things like single files, a directory, etc. They are explicitly granted at run time to a process, they are not persistent
Interesting. So one would not be able to implement capsec through a process token? Because it still sounds a lot like Windows Privileges/Linux Capabilities except that those privileges/capabilities are binary (has the privilege or has not) and you gave examples of privileges which would need to be parameterized (cpu load, target IP addresses, target urls).
In Windows a process token may differ from a user token. Not so in Unix/Linux where the effective uid refers to a, well, uid. The fact that the system can change a process token to have fewer privileges allows a process to run with fewer privileges than the user account or parent process. Sounds like the concept of process token is not just a requirement for capsec but may also be half-way there when you consider capabilities to be represented by SIDs
Even Windows could support it, with current apps, but then Microsoft wouldn't be able to use it to push Office 2020.
Ahem. Windows does support "capabilities". They are called privileges in Windows. Unlike in Linux/Unix where you need to elevate to the all-powerful root, Windows actually allows delegation of privileges, such as shutting down/restarting, back up, change system time, change timezone etc.
There was actually a push to create a POSIX standard for "capabilities". Unfortunately it was abandoned/retracted. Still, Linux does actually support a number of "Linux Capabilities" - but they are woefully underused. Theoretically they should allow programs such as ping to *not* be of the dangerous setuid root variety, but as it stands I don't think that even a single system utility actually use/respect Linux capabilities. Windows is way ahead here.
Parent is completely right. Windows registry is one of the biggest examples of this problem, but even on Linux any program can modify nearly any other file of any other program the user has access to.
What? The Windows registry is securable per key - as in each key has its own (but usually inherited from its container) ACL. To have the equivalent in Linux where most configuration is kept in text files you would have to be able to assign an ACL to each line of the file. The Windows registry also supports mandatory integrity control (MIC) which does not allow a lower-integrity process to write to a higher-integrity key even if the user account it runs under formally has write-permission.
It sound like you believe that you can only be granted access to the registry on a full-registry or hive-level only. If so, you are mistaken. It goes as granular as you want it to. And this level of control is also being used by the operating system, utilities and most 3rd party software (although the latter type can usually ignore it as long as values are stored in the user-private hive - HKCU).
That MS is about to axe Silverlight or.NET is FUD spread by an unholy alliance between click-whoring bloggers and individuals suffering from bad cases of Microsoft Hate Disease.
If you look at what MS has been doing with the browser HTML5 and JavaScript for tiles makes a lot of sense: Look at how IE9 integrated with the taskbar. Look at webslices introduced with IE7 (iirc). This will be about websites having an easy path to have tiles on the Windows 8 desktop. Not just as shortcuts to the front pages, but tiles which (like web slices) actually display live information directly from the sites. And don't be surprised if they are made using simple markup just like web slices.
MS is trying to blur the lines between apps, applications and internet sites.
But for application development.NET nor Silverlight are going away any time soon. On the contrary, Silverlight is very much at the core of Windows Phone 7/8. There are still tons of things you can do with.NET and not with HTML / JavaScript, like true threads and task oriented parallelism which will be *huge* going forward.
silverlight is gone. if i suggested it a month ago, i would be modded down. look at how it turned out recently...
No it is not. It is still Internet FUD spread by the likes of you. Silverlight is at the core of Microsoft mobile strategy. Will you come back here and eat crow when that is confirmed? Or will you then go into full spin FUD mode and claim that is just Microsoft saying it is at the core of the strategy, but they will be doing something else?
Silverlight has very good bindings to JavaScript. Silverlight can still do a lot of stuff that JavaScript and HTML5 cannot do. Stuff which is important to the Metro Phone UI.
I believe it does have a leg up, but only in the sense that Unix in general has a leg up because the starting point was so different. Unix, Linux and the like have always had a leg up in that respect just by their nature. It's not trolling, it's simply fact. Windows has got much better in recent years - Win 7 is actually really good, and the instances of viruses is going down.
Yes you are trolling. You are repeating unsubstantiated claims based on hyperbole and wishful thinking. You and others are repeating these claims without ever - like you this time - offering any justification for what it factually *is* that gives it a leg up. Like all good FUD it has a little piece of truth on which it can embellish: DOS and the Windows 9x family were very much single-user in the design mindset. But Windows NT was not built upon DOS and neither Windows 9x. Windows NT was developed ground-up as a multi-user networked operating system. Unix was built mainly in a "friendly" academic environment at a time where saving a single could make the difference.
There is no magical component of Unix or OS X. There is the basic me-us-everyone granularity in access control, with ACLs bolted on as an afterthought. The NSA actually had to develop SELinux for Linux - otherwise it would not be possible to certify Linux for use in sensitive government areas. Windows NT met those requirements from the beginning. Proper ACLs were in Windows NT from the very beginning.
Unix security model is still centered around the file system. Windows allows all kinds of objects - also in-memory objects to be secured through the use of handles. A process in Windows can create a handle for an object, strip rights from it and then pass it to another process or thread which can then access the same in-memory object but only with the restricted rights. Windows designers actually *thought* about securing individual objects and how to pass them to another process.
Only with exensions such as SELinux (and only if you actually enable and actually use such an extension) did *nix processes actually gain meaningful tokens - describing what the process is allowed to do. Until then it was always about the user running the process. Windows always had a per-process token which was initialized from the user token but which was always separate from it. Thus restricting what a process can do (sandbox style) came natural to Windows. It is not that the Windows way is superior to the current *nix state when you consider the extensions. But there was nothing inherently more secure about *nix. On the contrary.
Unix style user and group identification is integer-based. What happens to integers when you go out on the network and meet other systems? The clash. User ID were not designed with wide-scale networks in mind. How are users identified in Windows? With universal unique security identifiers (SIDs). The integer restrictions can (now) be easily overcome. But there never was such a restriction with Windows.
Unix security model is on the basic level much simpler than Windows. So simple that the concept of privileges beyond rights to access files were not thought of. Accessing certain functionality is considered restricted and only root can access it. Rather than being able to grant such access to individual users (that would require privileges) Unix went for a system with setuid and setgid bits. Basically, if you run a setuid executable (a setuid "server") you are then running as the owner of that executable. Pretty smart, until you realize what will happen when there's a bug in in that executable, e.g. a buffer overflow, an injection vulnerability etc. Then the attacker not only gains the privilege which was the purpose of the setuid server he is running as root with all of root's privileges - i.e. everything. Many vulnerabilities have been found in setuid servers over the years and many systems have fallen because of this. This is a design flaw because a setuid
Ok, people spout it all the time because it *IS* seriously superior to Windows. To put it another way, the Unix model isn't special, but the Windows model is especially bad.
Still just hand-waiving. Empty claims. What *is* it that is so superior?
I'll tell you what, take a fresh Windows machine, and connect it directly to the internet, and see how long it runs without getting infexted.
Since XP SP1 Windows TCP stack has been protected by default by the built-in firewall. You are a decade late. I can take any Vista or Windows 7 and hook it up - it will not get infected even though it has not been patched at all.
Even when you compare Windows 7 with a recent version of Mac OS or Linux, the result is similar, though not as drastic.
Citation needed
On the server side, there is Trusted BSD, SE Linux, and Mac OS has a similar sandbox system. windows? Nothing officially supported, last I checked.
When did you last check? 2002? Windows Service Hardening (see for instance http://technet.microsoft.com/en-us/magazine/2007.01.securitywatch.aspx) has been standard for services since Server 2003. Windows always (the NT line) had proper fine-grained tokens per process - unlike the bit-security in *nix and Linux which had to have SELinux or comparable solutions bolted on afterwards (you do realize that *nix security model is *still* centered around merely securing the file system, right?)
Service hardening uses the fact that each process has a full token and created a security identifier (SID) per service. The resulting privilege list is the union between the actual account the service executes under *and* the service account. Which means that hardened services by default are sandboxed - they can only use resources for which they are explicitly granted access - regardless of whether they run under the Local System account (root). All access to resources - even in-memory objects through handles - already checked the security token. This is just one example of the opposite of your claims: Windows security model was (and still is) more advanced and capable than *nix.
What you need apparmor and loadable security modules for was always possible in Windows.
On top of that, because you can *grant* privileges in Windows (unlike in *nix where you have to *be* root to access certain parts of the OS/kernel), more services can actually run with lower-privileges users. The accounts Local Service and Network Service which runs most services are actually "local users" in terms of privileges.
This reasoning backfires when one considers that Apache is by far the most popular web server software on the Internet. According to the September 2004 Netcraft web site survey, [1] 68% of web sites run the Apache web server. Only 21% of web sites run Microsoft IIS. If security problems boil down to the simple fact that malicious hackers target the largest installed base, it follows that we should see more worms, viruses, and other malware targeting Apache and the underlying operating systems for Apache than for Windows and IIS.
Windows was more insecure because Microsoft designed it to be be scriptable with com/dcom objects that apps can use to integrate into one another for app embedding. ActiveX are just objects that are designed from the ground up to be mix win32 applets inside IE.
COM/DCOM is a binary object model for creating object oriented API. A COM API is just an API following some specific conventions. The convention describes how an "object" must point to a type which must have a jump table. Nothing is more or less secure about it.
It is correct that ActiveX is a COM model for extending the browser (and other types of applications). As such you can compare it to extension APIs such as NSAPI in other browsers. Nothing inherently more secure or insecure about that. Now, MS *also* billed ActiveX for websites to extend the user experience because they needed a good response to Suns Java applets. In other words they encouraged websites to embed ActiveX controls into the sites and they made IE accept those controls.
The area to which ActiveX was applied was wholly unsuitable for binary components. It would be the equivalent of letting websites calling the Linux kernel API directly from the website after aking the user if that would be ok. COM or ActiveX as technologies were never the problem, indeed very few bugs have ever been found in the COM infrastructure. COM exists to this day and still forms a critical part of Windows infrastructure. But as it is just an API it doesn't make it more or less secure for that.
The whole object model is based upon using proprietary win32 code and api's so the programmers do not have to code as much. This was designed for lock in and accessibility everywhere with no security in mind..
With no security in mind? It is just an API. The methods being called are supposed to handle access control. If you implement an API an expose it as a plain old C API or as a COM API, you *still* has to consider security and access control. If anything, COM allows you to *better* secure your system because you can do so more fine-grained.
Unfortunately, this meant I can write some VB 6 app to call win32 functions to wipe your hard drive
As you can with a C API. It is just an API model. Nothing more or less secure about that.
and I can just copy the dll over as an activeX object in IE. If you have IE 5 or earlier all you would have to do is visit my webpage and it would run automatically on your computer and it would be trash.
No it would *not* run automatically on my computer. It never did that. You *always* had to accept a new control. Was it still a stupid model for extending websites? Yes. But stop lying about how it worked.
The iloveyou worm that hit it big in Outlook was a simple VBA script that copied the string and did a simply call to the user's address book.
Yes, a script which could call an API. The script should never have executed. That was a failure of Outlook, not a failure of Windows or COM. If another mail client allowed a mail message to execute scripts (e.g. bash) you would still be toast. You seems to be confused about what exactly are OS, API and applications.
Most of the win32 api was designed for Windows95 built on Dos which had no concept of user rights. Only the security API for Windows NT had that modern concept. These api's were ported over to WindowsXP.
So many things are wrong with these statements that I don't even know where to begin. But ok: Win32 API was built around the concept of handles and "objects". This is a model which quite easily supports securing the objects very fine-grained and has served Windows well. While Win9x didn't have much in the security department, the model is much more potent than a plain pointer API like in *nix.
When you want to call a method on an Win32 object you go through the handle. The handle internally p
And only valid for 10 days. No updates, have to re-download the whole thing to have the new definitions. It's *bigger* than most AV software...
What the heck MS ????
Maybe it was not intended to be "AV software"? From the front page of Microsoft Safety Scanner (emphasis mine):
The Microsoft Safety Scanner is a free downloadable security tool that provides on-demand scanning and helps remove viruses, spyware, and other malicious software. It works with your existing antivirus software.
...
The Microsoft Safety Scanner is not a replacement for using an antivirus software program that provides ongoing protection.
For real-time protection that helps to guard your home or small business PCs against viruses, spyware, and other malicious software, download Microsoft Security Essentials.
Though it doesn't name it in TFA, I'm betting that this also has something to do with the Malicious Software Removal Tool that is a part of normal Windows updates. This is downloaded and installed and run by default if you let Windows Update do its thing without manually configuring which update to install and which to ignore.
If you had bothered to read just the first 2 paragraphs of the computerworld article linked to you would have noticed this:
Microsoft cited that statistic and others from data generated by its new Safety Scanner, a free malware scanning and scrubbing tool that re-launched May 12.
And if you follow the link to the actual software, Microsoft Safety Scanner, this is the introduction:
Microsoft Safety Scanner
Do you think your PC has a virus?
The Microsoft Safety Scanner is a free downloadable security tool that provides on-demand scanning and helps remove viruses, spyware, and other malicious software. It works with your existing antivirus software.
Note: The Microsoft Safety Scanner expires 10 days after being downloaded. To rerun a scan with the latest anti-malware definitions, download and run the Microsoft Safety Scanner again.
The Microsoft Safety Scanner is not a replacement for using an antivirus software program that provides ongoing protection.
So no, this is *not* based on reporting back from MSRT. This is reporting from a tool which is labelled as a diagnostics one-off tool (works for 10 days) for users who think that their computers *may* be infected. Drawing any conclusion about infection rates from a self selected population is stupid if not outright dishonest. Timothy who wrote the hit-paragraph about the time2pwn of an unpatched XP box is most certainly being deliberately dishonest as a slashdot editor should be able to display a minimum of common consideration.
As usual the headlines are skewed by editors trying to drum up clicks and thus advertising revenue. The *text* of the original article is actually fair to the point that this is a self-selection and never claims what is in the headline. The CW editor obviously took a little liberty on the title. The title used at the front page and on slashdot is even more skewed with no basis at all, not in the article and not in reality.
MacOS is by design, with a greater degree of privilege and OS/Application separation, more resistant to attack than Microsoft Windows has been.
Could you describe that "design", please? I mean a few more specifics beyond the "it builds upon Unix" as if that is in itself a design. What separation are you referring to?
Yes I have, and it's an attempt to retro-fit a useful security model to a system not designed to have such security from the beginning.
No, UAC uses the already user and process tokens which were in Windows NT from the get-go to strip any token of certain rights. Compared to OS X and unix whic were borne with 12 bits of security, the Windows model is much more granular. The fact that Windows model is built to secure any OS object - not just filesystem objects - makes it more suitable in this exact scenario. The *nix idea of allowing setuid or setgid "servers" to "drop from root" is thoroughly broken and has been the source of numerous vulnerabilities and exploits. Setuid is necessary because *nix does not have sufficiently granular privileges.
UAC is using capabilities which were already there, thanks to the initial design using tokens and handles.
On the other hand, I detest the "Windows way" where every configuration setting is a GUI option, and the command-line tools are barely sufficient to get a GUI working after a failure.
I want the best of both. I want a powerful command line, and an easy-to-learn GUI.
That "Windows way" is all about GUI is merely a./ misconception. Most hardcore Unix'ers don't realize that there is an alternative to text config files, or they refuse to accept so. Windows has a powerful built-in firewall which supports both incoming and outgoing rules, rules based on ports and/or applications. It is easily managed from the GUI and doesn't require reboot or even restart of any service after a rule has been changed/added/deleted.
But Windows has also for the longest time exposed all such functionality through COM APIs, and the firewall service is no exception. To list the rules from the CLI, drop to PowerShell and type:
$fw = new-object -com HNetCfg.FwPolicy2 $fw.rules
Each rule listed is actually an active object with settable properties. To see exactly what can be set for each rule (or entered as new rules) type
$fw.rules | gm
This will pipe the rules through the Get-Member cmdlet which will reflect exactly which properties, methods and events are available. These are the available properties: Action, ApplicationName, Description, Direction, EdgeTraversal, EdgeTraversalOptions, Enabled, Grouping, IcmpTypesAndCodes, Interfaces, InterfaceTypes, LocalAddresses, LocalPorts, Name, Profiles, Protocol, RemoteAddresses, RemotePorts, serviceName.
Having to use a COM object to configure a firewall from the CLI may at first seem more cumbersome than using a text file. But then you realize that there is also a number of advantages:
The changes can take effect immediately as you are really talking to the service/daemon and not changing its configuration beneath it. There is no need to force it to re-read the configuration by restarting the service/daemon.
The configuration format can be allowed to change without breaking existing scripts. Multiple interfaces may exist at the same time, the current one and a number of "legacy" interface. Changing a configuration file schema while scripts may rely on specific constructs through their use of text processing tools is error prone.
The interfaces provides implementation abstraction. Other providers which implement the same interface can be plugged in and work with the scripts.
The config changes can be more readily automated in a safe manner. Each interaction with the service is validated. With text files you can break the schema and prevent the service/daemon from restarting (think Apache, X etc.).
Other than that, Jared Smith if factually wrong. Windows has for years supported dynamic configuration of the firewall, and Windows is certainly a "mainstream" operating system, even if he wishes it wasn't so.
However, there is a few obvious but important differences between "everything is a file" and "everything is an object": Encapsulation and reflection. In PowerShell ps produces a sequence of System.Diagnostics.ProcessInfo objects. This type has methods like Kill (terminate the process), Refresh (refresh the properties for CPU usage, mem usage etc), WaitForExit, WaitForInputIdle etc. When the objects are self-discoverable (reflective) it alleviates the need for specific external commands.
Consider how the COM object Excel.Application comes with methods for manipulating workbooks/sheets, calculating etc. This allows you to directly use the very same objects and methods as used internally by Excel:
Also consider how the objects can be designed for use within an application as well as on the command line. Although not obvious at first, this is a major point which will help drive automation and scriptability. Exchange has since version 2007 used used the very same "command" objects within the GUI as are scriptable on the command line. Because the commands are handling in-memory objects with no text/JSON/xml serialization when combined they are suitable for applications as well as CLIs.
Is the "concurrent it is not" an implementation detail, or is something that they could change without breaking (too many) cmdlets by running them in multiple threads or something like that?
That would be an implementation detail. I believe I saw an interview with Jeffrey Snower (principal architect on PowerShell) where he said they were looking into parallel processing. Of course, if the passed objects are not thread safe themselves (or rather the methods/properties of the passed objects), cmdlets which passes on objects but also manipulates them after they have been passed may run into thread issues.
Now, Wikipedia's comparison of command shells does have PS down as "objects/concurrent" for how the pipes work, so assuming that's accurate and not misleading (because it, for instance, has sequential object pipes but concurrent text pipes), that doesn't actually arise in practice.
"objects/progressive" would be more accurate. Commands of the PowerShell pipeline are not running in separate concurrent processes. Rather, the cmdlets (usually) all run on the same thread within the PowerShell host. Objects are "pushed" through the pipeline in a depth-first manner, i.e. when a cmdlet produces an output object it is immediately pushed into the processing of the following cmdlet.
Some cmdlets (like e.g. group/sort) do not produce output objects until the "end" stage. Cmdlets live through 3 stages: begin, processing, end. When a pipeline is set up the cmdlets are initialized (the "begin" stage) from the last towards the first. During this set-up a cmdlet is allowed to produce output objects as the following cmdlet has already gone through its own begin stage. When all cmdlets are initialized (the first command of the pipeline completed its begin stage), the processing stage is invoked on the first command of the pipeline. This may produce output objects which are then immediately pushed onto the next cmdlet as input. When there are no more "input" objects the process stage ends and the "end" stage is invoked from the first command through the last. During this stage objects may also be produced. As the following cmdlets are still in the "processing" stage the output objects can be safely pushed through the pipeline.
Oh... so you mean it's something like this and this.
Nope. Nothing like that at all. I believe you misunderstand what automation is about. It is not about controlling an application user interface. That is brittle and error prone. Rather, automation is about accessing and controlling the model of the application and performing the actions directly.
Trouble is Redmond didn't innovate. Powershell is a weak copy of IBM OS/2 Workplace Shell / System Object Model (SOM).
IBM OS/2 Workplace Shell is nothing at all like PowerShell. Did you see the word "object" and just assumed it had to be the same thing or a copy of it?
Is it because you cannot tolerate the mere thought that somebody at Redmond actually came up with a cool innovation over the traditional shells?
here you go. Try typing "ls -" then push tab twice. magic!
While cool, bash completion still only works for commands for which the completion has been defined. In PowerShell cmdlets, functions, aliases and even script files inherently interact with the shell to provide metadata about parameters, types, defaults etc so that
tab-completion is defined by the very same declarations that drive parameter parsing. As soon as you declare a parameter for a command, function or even your own script file, tab completion is working
help is integrated and will document the parameters using the same declarations, regardless of whether you actually provide textual descriptions for the paraneters (help documentation is integrated and you can document parameters with a simple comment convention - which goes for both cmdlets, functions and script files).
tab-completion will also *dynamically* reflect on the actual objects if invoked for a.NET, COM or WMI object.
Slashdot Mirror
I mentioned Balmer because he is the main head of the Hydra that Microsoft is. I'm sorry for laying the blame squarely at the feet of the CEO, in future I'll lay the blame a the feet of the guys working in the call centre. Or maybe the lawyers they buy for a dime a dozen.
If you have an issue with the statement, you could mention the statement and the lawyer who it is attributed to, Richard Boscovich. That would suffice. You did not even have to read the article, the name was right there in the (inflammatory) summary.
If you wanted to hand off access to a new process, which had ALL of the permissions of another process, this would work. However, if there were ANY differences at all, you'd have to create a new account, then set up permissions on all of the system resources to match your new desired access for the new account, and then pass along information via inter-process pipes, shared files, etc.
No, not on Windows. Windows has a per-process token and the privileges of that token does not have to match any account at all. The token consists of a list of SIDs which can represent groups (which in turn appear in ACLs) *or* the SIDs represent privileges, e.g. setting time zone, restarting the system, log on as batch service etc. You do *not* need to set up an account with the desired privileges. You just need to prune the token itself.
On Linux there are also "Linux Capabilities" which are a few number of bits which represent capabilities that are not linked to any specific resource. These can even be considered "mini tokens" as they appear in the process descriptor as well. They are poorly implemented, though, and woefully underused.
What you cannot do with Windows process token is represent more advanced (parameterized) privileges such as CPU quota.
It is unfortunate that it's necessary to try to overload an existing term with a new, slightly different definition, but that's what has happened here.
Capabilities in a capability based system (cabsec for short) are fine grained access rights to things like single files, a directory, etc. They are explicitly granted at run time to a process, they are not persistent
Interesting. So one would not be able to implement capsec through a process token? Because it still sounds a lot like Windows Privileges/Linux Capabilities except that those privileges/capabilities are binary (has the privilege or has not) and you gave examples of privileges which would need to be parameterized (cpu load, target IP addresses, target urls).
In Windows a process token may differ from a user token. Not so in Unix/Linux where the effective uid refers to a, well, uid. The fact that the system can change a process token to have fewer privileges allows a process to run with fewer privileges than the user account or parent process. Sounds like the concept of process token is not just a requirement for capsec but may also be half-way there when you consider capabilities to be represented by SIDs
Even Windows could support it, with current apps, but then Microsoft wouldn't be able to use it to push Office 2020.
Ahem. Windows does support "capabilities". They are called privileges in Windows. Unlike in Linux/Unix where you need to elevate to the all-powerful root, Windows actually allows delegation of privileges, such as shutting down/restarting, back up, change system time, change timezone etc.
There was actually a push to create a POSIX standard for "capabilities". Unfortunately it was abandoned/retracted. Still, Linux does actually support a number of "Linux Capabilities" - but they are woefully underused. Theoretically they should allow programs such as ping to *not* be of the dangerous setuid root variety, but as it stands I don't think that even a single system utility actually use/respect Linux capabilities. Windows is way ahead here.
Parent is completely right. Windows registry is one of the biggest examples of this problem, but even on Linux any program can modify nearly any other file of any other program the user has access to.
What? The Windows registry is securable per key - as in each key has its own (but usually inherited from its container) ACL. To have the equivalent in Linux where most configuration is kept in text files you would have to be able to assign an ACL to each line of the file. The Windows registry also supports mandatory integrity control (MIC) which does not allow a lower-integrity process to write to a higher-integrity key even if the user account it runs under formally has write-permission.
It sound like you believe that you can only be granted access to the registry on a full-registry or hive-level only. If so, you are mistaken. It goes as granular as you want it to. And this level of control is also being used by the operating system, utilities and most 3rd party software (although the latter type can usually ignore it as long as values are stored in the user-private hive - HKCU).
That MS is about to axe Silverlight or .NET is FUD spread by an unholy alliance between click-whoring bloggers and individuals suffering from bad cases of Microsoft Hate Disease.
If you look at what MS has been doing with the browser HTML5 and JavaScript for tiles makes a lot of sense: Look at how IE9 integrated with the taskbar. Look at webslices introduced with IE7 (iirc). This will be about websites having an easy path to have tiles on the Windows 8 desktop. Not just as shortcuts to the front pages, but tiles which (like web slices) actually display live information directly from the sites. And don't be surprised if they are made using simple markup just like web slices.
MS is trying to blur the lines between apps, applications and internet sites.
But for application development .NET nor Silverlight are going away any time soon. On the contrary, Silverlight is very much at the core of Windows Phone 7/8. There are still tons of things you can do with .NET and not with HTML / JavaScript, like true threads and task oriented parallelism which will be *huge* going forward.
silverlight is gone. if i suggested it a month ago, i would be modded down. look at how it turned out recently ...
No it is not. It is still Internet FUD spread by the likes of you. Silverlight is at the core of Microsoft mobile strategy. Will you come back here and eat crow when that is confirmed? Or will you then go into full spin FUD mode and claim that is just Microsoft saying it is at the core of the strategy, but they will be doing something else?
Silverlight has very good bindings to JavaScript. Silverlight can still do a lot of stuff that JavaScript and HTML5 cannot do. Stuff which is important to the Metro Phone UI.
I believe it does have a leg up, but only in the sense that Unix in general has a leg up because the starting point was so different. Unix, Linux and the like have always had a leg up in that respect just by their nature. It's not trolling, it's simply fact. Windows has got much better in recent years - Win 7 is actually really good, and the instances of viruses is going down.
Yes you are trolling. You are repeating unsubstantiated claims based on hyperbole and wishful thinking. You and others are repeating these claims without ever - like you this time - offering any justification for what it factually *is* that gives it a leg up. Like all good FUD it has a little piece of truth on which it can embellish: DOS and the Windows 9x family were very much single-user in the design mindset. But Windows NT was not built upon DOS and neither Windows 9x. Windows NT was developed ground-up as a multi-user networked operating system. Unix was built mainly in a "friendly" academic environment at a time where saving a single could make the difference.
There is no magical component of Unix or OS X. There is the basic me-us-everyone granularity in access control, with ACLs bolted on as an afterthought. The NSA actually had to develop SELinux for Linux - otherwise it would not be possible to certify Linux for use in sensitive government areas. Windows NT met those requirements from the beginning. Proper ACLs were in Windows NT from the very beginning.
Unix security model is still centered around the file system. Windows allows all kinds of objects - also in-memory objects to be secured through the use of handles. A process in Windows can create a handle for an object, strip rights from it and then pass it to another process or thread which can then access the same in-memory object but only with the restricted rights. Windows designers actually *thought* about securing individual objects and how to pass them to another process.
Only with exensions such as SELinux (and only if you actually enable and actually use such an extension) did *nix processes actually gain meaningful tokens - describing what the process is allowed to do. Until then it was always about the user running the process. Windows always had a per-process token which was initialized from the user token but which was always separate from it. Thus restricting what a process can do (sandbox style) came natural to Windows. It is not that the Windows way is superior to the current *nix state when you consider the extensions. But there was nothing inherently more secure about *nix. On the contrary.
Unix style user and group identification is integer-based. What happens to integers when you go out on the network and meet other systems? The clash. User ID were not designed with wide-scale networks in mind. How are users identified in Windows? With universal unique security identifiers (SIDs). The integer restrictions can (now) be easily overcome. But there never was such a restriction with Windows.
Unix security model is on the basic level much simpler than Windows. So simple that the concept of privileges beyond rights to access files were not thought of. Accessing certain functionality is considered restricted and only root can access it. Rather than being able to grant such access to individual users (that would require privileges) Unix went for a system with setuid and setgid bits. Basically, if you run a setuid executable (a setuid "server") you are then running as the owner of that executable. Pretty smart, until you realize what will happen when there's a bug in in that executable, e.g. a buffer overflow, an injection vulnerability etc. Then the attacker not only gains the privilege which was the purpose of the setuid server he is running as root with all of root's privileges - i.e. everything. Many vulnerabilities have been found in setuid servers over the years and many systems have fallen because of this. This is a design flaw because a setuid
Ok, people spout it all the time because it *IS* seriously superior to Windows.
To put it another way, the Unix model isn't special, but the Windows model is especially bad.
Still just hand-waiving. Empty claims. What *is* it that is so superior?
I'll tell you what, take a fresh Windows machine, and connect it directly to the internet, and see how long it runs without getting infexted.
Since XP SP1 Windows TCP stack has been protected by default by the built-in firewall. You are a decade late. I can take any Vista or Windows 7 and hook it up - it will not get infected even though it has not been patched at all.
Even when you compare Windows 7 with a recent version of Mac OS or Linux, the result is similar, though not as drastic.
Citation needed
On the server side, there is Trusted BSD, SE Linux, and Mac OS has a similar sandbox system. windows? Nothing officially supported, last I checked.
When did you last check? 2002? Windows Service Hardening (see for instance http://technet.microsoft.com/en-us/magazine/2007.01.securitywatch.aspx) has been standard for services since Server 2003. Windows always (the NT line) had proper fine-grained tokens per process - unlike the bit-security in *nix and Linux which had to have SELinux or comparable solutions bolted on afterwards (you do realize that *nix security model is *still* centered around merely securing the file system, right?)
Service hardening uses the fact that each process has a full token and created a security identifier (SID) per service. The resulting privilege list is the union between the actual account the service executes under *and* the service account. Which means that hardened services by default are sandboxed - they can only use resources for which they are explicitly granted access - regardless of whether they run under the Local System account (root). All access to resources - even in-memory objects through handles - already checked the security token. This is just one example of the opposite of your claims: Windows security model was (and still is) more advanced and capable than *nix.
What you need apparmor and loadable security modules for was always possible in Windows.
On top of that, because you can *grant* privileges in Windows (unlike in *nix where you have to *be* root to access certain parts of the OS/kernel), more services can actually run with lower-privileges users. The accounts Local Service and Network Service which runs most services are actually "local users" in terms of privileges.
From that ancient (2004) article:
This reasoning backfires when one considers that Apache is by far the most popular web server software on the Internet. According to the September 2004 Netcraft web site survey, [1] 68% of web sites run the Apache web server. Only 21% of web sites run Microsoft IIS. If security problems boil down to the simple fact that malicious hackers target the largest installed base, it follows that we should see more worms, viruses, and other malware targeting Apache and the underlying operating systems for Apache than for Windows and IIS.
Ugh. Which operating system are the most compromised (2010): http://www.zone-h.org/news/id/4737
Linux 1.126.987
Windows 2003 197.822
FreeBSD 46.992
Win 2008 15.083
F5 Big-IP* 14.000
Unknown 7.840
Win 2000 6.097
Which servers?
Apache 1.095.982
IIS/6.0 195.154
nginx 40.640
LiteSpeed 37.795
Zeus 14.111
Seems reality caught up with that conjecture.
Windows was more insecure because Microsoft designed it to be be scriptable with com/dcom objects that apps can use to integrate into one another for app embedding. ActiveX are just objects that are designed from the ground up to be mix win32 applets inside IE.
COM/DCOM is a binary object model for creating object oriented API. A COM API is just an API following some specific conventions. The convention describes how an "object" must point to a type which must have a jump table. Nothing is more or less secure about it.
It is correct that ActiveX is a COM model for extending the browser (and other types of applications). As such you can compare it to extension APIs such as NSAPI in other browsers. Nothing inherently more secure or insecure about that. Now, MS *also* billed ActiveX for websites to extend the user experience because they needed a good response to Suns Java applets. In other words they encouraged websites to embed ActiveX controls into the sites and they made IE accept those controls.
The area to which ActiveX was applied was wholly unsuitable for binary components. It would be the equivalent of letting websites calling the Linux kernel API directly from the website after aking the user if that would be ok. COM or ActiveX as technologies were never the problem, indeed very few bugs have ever been found in the COM infrastructure. COM exists to this day and still forms a critical part of Windows infrastructure. But as it is just an API it doesn't make it more or less secure for that.
The whole object model is based upon using proprietary win32 code and api's so the programmers do not have to code as much. This was designed for lock in and accessibility everywhere with no security in mind..
With no security in mind? It is just an API. The methods being called are supposed to handle access control. If you implement an API an expose it as a plain old C API or as a COM API, you *still* has to consider security and access control. If anything, COM allows you to *better* secure your system because you can do so more fine-grained.
Unfortunately, this meant I can write some VB 6 app to call win32 functions to wipe your hard drive
As you can with a C API. It is just an API model. Nothing more or less secure about that.
and I can just copy the dll over as an activeX object in IE. If you have IE 5 or earlier all you would have to do is visit my webpage and it would run automatically on your computer and it would be trash.
No it would *not* run automatically on my computer. It never did that. You *always* had to accept a new control. Was it still a stupid model for extending websites? Yes. But stop lying about how it worked.
The iloveyou worm that hit it big in Outlook was a simple VBA script that copied the string and did a simply call to the user's address book.
Yes, a script which could call an API. The script should never have executed. That was a failure of Outlook, not a failure of Windows or COM. If another mail client allowed a mail message to execute scripts (e.g. bash) you would still be toast. You seems to be confused about what exactly are OS, API and applications.
Most of the win32 api was designed for Windows95 built on Dos which had no concept of user rights. Only the security API for Windows NT had that modern concept. These api's were ported over to WindowsXP.
So many things are wrong with these statements that I don't even know where to begin. But ok: Win32 API was built around the concept of handles and "objects". This is a model which quite easily supports securing the objects very fine-grained and has served Windows well. While Win9x didn't have much in the security department, the model is much more potent than a plain pointer API like in *nix.
When you want to call a method on an Win32 object you go through the handle. The handle internally p
And only valid for 10 days. No updates, have to re-download the whole thing to have the new definitions. It's *bigger* than most AV software...
What the heck MS ????
Maybe it was not intended to be "AV software"? From the front page of Microsoft Safety Scanner (emphasis mine):
The Microsoft Safety Scanner is a free downloadable security tool that provides on-demand scanning and helps remove viruses, spyware, and other malicious software. It works with your existing antivirus software.
...
The Microsoft Safety Scanner is not a replacement for using an antivirus software program that provides ongoing protection.
For real-time protection that helps to guard your home or small business PCs against viruses, spyware, and other malicious software, download Microsoft Security Essentials.
Though it doesn't name it in TFA, I'm betting that this also has something to do with the Malicious Software Removal Tool that is a part of normal Windows updates. This is downloaded and installed and run by default if you let Windows Update do its thing without manually configuring which update to install and which to ignore.
If you had bothered to read just the first 2 paragraphs of the computerworld article linked to you would have noticed this:
Microsoft cited that statistic and others from data generated by its new Safety Scanner, a free malware scanning and scrubbing tool that re-launched May 12.
And if you follow the link to the actual software, Microsoft Safety Scanner, this is the introduction:
Microsoft Safety Scanner
Do you think your PC has a virus?
The Microsoft Safety Scanner is a free downloadable security tool that provides on-demand scanning and helps remove viruses, spyware, and other malicious software. It works with your existing antivirus software.
Note: The Microsoft Safety Scanner expires 10 days after being downloaded. To rerun a scan with the latest anti-malware definitions, download and run the Microsoft Safety Scanner again.
The Microsoft Safety Scanner is not a replacement for using an antivirus software program that provides ongoing protection.
So no, this is *not* based on reporting back from MSRT. This is reporting from a tool which is labelled as a diagnostics one-off tool (works for 10 days) for users who think that their computers *may* be infected. Drawing any conclusion about infection rates from a self selected population is stupid if not outright dishonest. Timothy who wrote the hit-paragraph about the time2pwn of an unpatched XP box is most certainly being deliberately dishonest as a slashdot editor should be able to display a minimum of common consideration.
As usual the headlines are skewed by editors trying to drum up clicks and thus advertising revenue. The *text* of the original article is actually fair to the point that this is a self-selection and never claims what is in the headline. The CW editor obviously took a little liberty on the title. The title used at the front page and on slashdot is even more skewed with no basis at all, not in the article and not in reality.
So here's the question:
Why won't task manager show hidden processes?
Why do I have to rely on a third party (Sysinternals) now bought by Microsoft, just so I have the ability to see these things?
What are you talking about? Task manager shows the same processes as process explorer. Did you miss the "show processes for all users" button?
Windows Defender is add-on software because the OS itself doesn't provide enough defense.
No. It is add-on because MS cannot bundle such application for anti-trust concerns. Same with security essentials.
MacOS is by design, with a greater degree of privilege and OS/Application separation, more resistant to attack than Microsoft Windows has been.
Could you describe that "design", please? I mean a few more specifics beyond the "it builds upon Unix" as if that is in itself a design. What separation are you referring to?
Yes I have, and it's an attempt to retro-fit a useful security model to a system not designed to have such security from the beginning.
No, UAC uses the already user and process tokens which were in Windows NT from the get-go to strip any token of certain rights. Compared to OS X and unix whic were borne with 12 bits of security, the Windows model is much more granular. The fact that Windows model is built to secure any OS object - not just filesystem objects - makes it more suitable in this exact scenario. The *nix idea of allowing setuid or setgid "servers" to "drop from root" is thoroughly broken and has been the source of numerous vulnerabilities and exploits. Setuid is necessary because *nix does not have sufficiently granular privileges.
UAC is using capabilities which were already there, thanks to the initial design using tokens and handles.
On the other hand, I detest the "Windows way" where every configuration setting is a GUI option, and the command-line tools are barely sufficient to get a GUI working after a failure.
I want the best of both. I want a powerful command line, and an easy-to-learn GUI.
That "Windows way" is all about GUI is merely a ./ misconception. Most hardcore Unix'ers don't realize that there is an alternative to text config files, or they refuse to accept so. Windows has a powerful built-in firewall which supports both incoming and outgoing rules, rules based on ports and/or applications. It is easily managed from the GUI and doesn't require reboot or even restart of any service after a rule has been changed/added/deleted.
But Windows has also for the longest time exposed all such functionality through COM APIs, and the firewall service is no exception. To list the rules from the CLI, drop to PowerShell and type:
$fw = new-object -com HNetCfg.FwPolicy2
$fw.rules
Each rule listed is actually an active object with settable properties. To see exactly what can be set for each rule (or entered as new rules) type
$fw.rules | gm
This will pipe the rules through the Get-Member cmdlet which will reflect exactly which properties, methods and events are available. These are the available properties: Action, ApplicationName, Description, Direction, EdgeTraversal, EdgeTraversalOptions, Enabled, Grouping, IcmpTypesAndCodes, Interfaces, InterfaceTypes, LocalAddresses, LocalPorts, Name, Profiles, Protocol, RemoteAddresses, RemotePorts, serviceName.
Having to use a COM object to configure a firewall from the CLI may at first seem more cumbersome than using a text file. But then you realize that there is also a number of advantages:
Other than that, Jared Smith if factually wrong. Windows has for years supported dynamic configuration of the firewall, and Windows is certainly a "mainstream" operating system, even if he wishes it wasn't so.
Very good points. Plan9 is certainly interesting.
However, there is a few obvious but important differences between "everything is a file" and "everything is an object": Encapsulation and reflection. In PowerShell ps produces a sequence of System.Diagnostics.ProcessInfo objects. This type has methods like Kill (terminate the process), Refresh (refresh the properties for CPU usage, mem usage etc), WaitForExit, WaitForInputIdle etc. When the objects are self-discoverable (reflective) it alleviates the need for specific external commands.
Consider how the COM object Excel.Application comes with methods for manipulating workbooks/sheets, calculating etc. This allows you to directly use the very same objects and methods as used internally by Excel:
$app = new-object -com Excel.Application
$app.DisplayAlerts = $false
$wb = $app.Workbooks.Add()
$ws = $wb.Worksheets.Item(1)
$ws.Cells.Item(1,1) = "Life, the Universe and Everything?"
$ws.Cells.Item(1,2) = "=6*7"
$ws.Calculate()
$question = $ws.Cells.Item(1,1).Text
$answer = $ws.Cells.Item(1,2).Text
$app.Quit()
echo "$question $answer!"
Also consider how the objects can be designed for use within an application as well as on the command line. Although not obvious at first, this is a major point which will help drive automation and scriptability. Exchange has since version 2007 used used the very same "command" objects within the GUI as are scriptable on the command line. Because the commands are handling in-memory objects with no text/JSON/xml serialization when combined they are suitable for applications as well as CLIs.
Is the "concurrent it is not" an implementation detail, or is something that they could change without breaking (too many) cmdlets by running them in multiple threads or something like that?
That would be an implementation detail. I believe I saw an interview with Jeffrey Snower (principal architect on PowerShell) where he said they were looking into parallel processing. Of course, if the passed objects are not thread safe themselves (or rather the methods/properties of the passed objects), cmdlets which passes on objects but also manipulates them after they have been passed may run into thread issues.
ps|?{$_.vm -gt 800mb}|kill
Now, Wikipedia's comparison of command shells does have PS down as "objects/concurrent" for how the pipes work, so assuming that's accurate and not misleading (because it, for instance, has sequential object pipes but concurrent text pipes), that doesn't actually arise in practice.
"objects/progressive" would be more accurate. Commands of the PowerShell pipeline are not running in separate concurrent processes. Rather, the cmdlets (usually) all run on the same thread within the PowerShell host. Objects are "pushed" through the pipeline in a depth-first manner, i.e. when a cmdlet produces an output object it is immediately pushed into the processing of the following cmdlet.
Some cmdlets (like e.g. group/sort) do not produce output objects until the "end" stage. Cmdlets live through 3 stages: begin, processing, end. When a pipeline is set up the cmdlets are initialized (the "begin" stage) from the last towards the first. During this set-up a cmdlet is allowed to produce output objects as the following cmdlet has already gone through its own begin stage. When all cmdlets are initialized (the first command of the pipeline completed its begin stage), the processing stage is invoked on the first command of the pipeline. This may produce output objects which are then immediately pushed onto the next cmdlet as input. When there are no more "input" objects the process stage ends and the "end" stage is invoked from the first command through the last. During this stage objects may also be produced. As the following cmdlets are still in the "processing" stage the output objects can be safely pushed through the pipeline.
But concurrent it is not.
Oh... so you mean it's something like this and this.
Nope. Nothing like that at all. I believe you misunderstand what automation is about. It is not about controlling an application user interface. That is brittle and error prone. Rather, automation is about accessing and controlling the model of the application and performing the actions directly.
Trouble is Redmond didn't innovate. Powershell is a weak copy of IBM OS/2 Workplace Shell / System Object Model (SOM).
IBM OS/2 Workplace Shell is nothing at all like PowerShell. Did you see the word "object" and just assumed it had to be the same thing or a copy of it?
Is it because you cannot tolerate the mere thought that somebody at Redmond actually came up with a cool innovation over the traditional shells?
here you go. Try typing "ls -" then push tab twice. magic!
While cool, bash completion still only works for commands for which the completion has been defined. In PowerShell cmdlets, functions, aliases and even script files inherently interact with the shell to provide metadata about parameters, types, defaults etc so that