It is broken by design because sudo protects the utility used to access the protected resource rather than protecting the resource itself.

Relying on and allowing such a mechanism does two things to your security model:

1) It forces users with otherwise legitimate access to go through specific utilities (actually fire up processes) just to access a they should have access to in the first place.

2) Worse, it takes away your ability to assess who has access to the resource. Since there are multiple SUID root utilities on the system, and multiple sudo utilities with sudoers config, you really have to know the capabilities of each of those utilities to know that they cannot be used by an unauthorized user to access the protected resource.

Had you used a system where the resource was protected and where there were no sudo/SUID bypass mechanism available, you can generate a report of users with access to the resource simply by querying the user/group permissions. As an added benefit, anyone with legitimate access could then access the resource and not be forced fire up a process and to go through a specific utility to access the resource.

Not only is the sudoers 144-page-incomprehensible, the whole idea is broken to begin with:

First, you design a simplistic security model where a single user/group (root) is hardwired to a number of privileges not available to anyone else and where standard users' privileges are inherently too limited.

Then you start drilling *holes* (big holes) because the model clearly does not meet real world requirements. SUID lets users run as root for the duration of the process. A single escape during the processing will allow the otherwise non-privileged user to drop up to a root shell. A single memory corruption may allow the user to run unrestricted as root. And there has been *many* such exploits in all variants of Unix, including Linux, OS X etc.

Because the operating system security model did not allow fine grained access control to resources, someone came up with the idea to protect the *utility* instead of the resource or system function (and took out a patent, no less) . WTF? Why does the OS not protect the syscall to change system time or change password? Why did they design a system where you would need to start a frigging SUID root process to do that?

It is a direct violation of the least privilege principle, one of the core security principles. Every time you let someone invoke sudo you let them run as root and just hope that the utility does not contain vulnerabilities, because the *consequence* of a vulnerability is total system compromise.

sudo is a design flaw in the ActiveX class. In fact, they are really very much alike: In both cases you hand over the keys to the house and cross your fingers that the visitor is well behaved while he is in there.

Once the holes have been drilled, sudo (and SUID roots) make it extremely hard for security auditors to assess whether the security has been set up with meaningful barriers: They can not audit a resource and determine who has access to view or change it. The sudo / SUID model always leave the possibility that some utility allows another access to the resource. I.e. the auditor cannot assess a single resource, rather he must assess the system in its entirety. And when doing that he must also trust that the SUID root utilities and sudo utilities are what they pretend to be, i.e. he must validate the utilities as well; or accept the possibility that one or more of the utilities is actually capable of more than it advertises.

Had the designers opted for a proper model where resources (processes, syscalls, devices, ports) were actually protected by access control lists, the auditor could have audited the security settings and remain confident that there was not some *other* way to access the resource.

The SUID root / sudo idea was a terrible one. It was necessitated because of an woefully inadequate security model. Rather than fixing the model (like e.g. create real tokens with claims) the designers decided to drill holes. Many holes.

man syntax

system responds with 2 topics: about_Command_Syntax and about_Path_Syntax

man command_syntax

system responds with help "about the command syntax".

What are you talking about? PowerShell commands are extremely consistent - not like the different syntax conventions used for ls, find, xargs and dd - just to name a few examples of Nix inconsistencies. PowerShell commands always follow the pattern Verb-Noun. A limited set of verbs are strongly encouraged (to the point where a command author has to bend over to break the convention) and their conventional uses are explained in command author guidelines. While PowerShell commands may take positional parameters they *always* have a name (the position is optional to allow for a short form). Parameter names are *always* specified using dash (like -ParameterName). Parameter names can be shortened as long as they are still unambigious. This is all a feature of the *shell* - parameter parsing is not left to each command, i.e. a command is forced to use the consistent scheme.

From running man command_syntax:

TOPIC
about_Command_Syntax

SHORT DESCRIPTION
Describes the syntax diagrams that are used in Windows PowerShell.

LONG DESCRIPTION
The Get-Help and Get-Command cmdlets display syntax diagrams to help
you construct commands correctly. This topic explains how to interpret
the syntax diagrams.

Syntax Diagrams
Each paragraph in a command syntax diagram represents a valid form
of the command.

To construct a command, follow the syntax diagram from left to
right. Select from among the optional parameters and provide values for
the placeholders.

Windows PowerShell uses the following notation for syntax diagrams. ....

(explanation of syntax, parameters etc. follows).

You really only have to look for it.

Try typing man. That should get you started. :-)

You can start by knowing only 4 commands. Everything is discoverable through those:
* Get-Help (aliases help, man): Get help for a command or for a topic, e.g. "man ls" gets help for the "ls" command (ls being alias for get-childitem). Try typing man about - that'll give you a list of "about" topics that explain PowerShell quite nicely.
* Get-Command (alias gcm): Lists available commands.
* Get-Member (alias gm): Lists available members on items output from a command, e.g. ls|gm will tell you that ls produces DirectoryInfo and FileInfo objects each with an extensive set of properties such as name, path, length, access time etc.
* Get-Alias (alias "alias"): Lists defined aliases. Several aliases help Nix users get started, e.g. "ls", "ps".

Yes it is. The technique is referred to as "return oriented programming". That is why you need strong ASLR to make DEP/NX effective. Windows and OS X (IIRC) are the only OSes with strong and complete ASLR.

While it is generally true that using the longer versions of cmdlet names and parameter names and using named parameters instead of positional ones increases readability in scripts, this specific "longer version" is just stupid. It has been artificially made longer and more complicated and has actually *lost* readability bc of that process. One can only guess to the intentions behind that "example". It is certainly very, very bad PowerShell.

Yes. In fact, the functions from the NetAdapter module has been automatically created as wrappers from WMI objects.

PowerShell: Get-NetAdapter | select macaddress
Bash: /sbin/ifconfig | grep -Eo ..\(\:..\){5}

Which is shorter?
Which is more readable?
Which is more robust against changes (like new properties/columns)?
Which is more consistent across related commands?
Which is more discoverable?
Which is more extensible?

Note how the PowerShell version does *not* need to engage in string parsing, and how it does *not* need to rely on specific file content formats. The advantages of objects in the pipeline.

Btw, if you want PowerShell to output in the same metadata-stripped format as from bash/ifconfig, you can make the PowerShell command even shorter, without sacrificing readability:
PowerShell: (Get-NetAdapter).macaddress

Sorry, BS. PowerShell is a foundation technology in Windows, unlike VBScript. Since Windows 7, the troubleshooting packs are actually written in PowerShell! The troubleshooting utilities are automatically launched by the system when e.g. network problems occur.

PowerShell is every bit as COM capable as VBScript. PS uses a "unified" type system where multiple object models (COM, .NET, WMI etc) are surfaced as common PS objects.

VBScript is definitively legacy (and deprecated). I will actually wager a bet that there is not a single meaningful VBScript that could not be written shorter and more elegant with PowerShell.

I pasted (18*(567/23))+67 into the powershell prompt:

PS C:\Users\Me> (18*(567/23))+67
510.739130434783

PS C:\Users\Me>

That's brilliant!

Most bashers (no pun intended) miss several aspects of PowerShell simply because they view it as just another shell.

One such aspect is the fact that PowerShell is designed to operate directly with an application's core logic (the object model) whether that application was designed using COM or .NET. Virtually *all* of Window's features and even 3rd party applications for Windows are designed using one of those models. So the barrier to exposing the functionality to the CLI (PowerShell) is really, really low, and even older applications that predates PowerShell or that were never designed for PowerShell (like iTunes) lend themselves to CLI manipulation. Forget about needing to craft a suite of external CLI tools - your app is inherently exposed to command line manipulation.

Another often overlooked aspect is how PowerShell is designed to run in-process within an application. The CLI is just *one* possible host for PowerShell. Alas, you can add the PowerShell engine to your app and immediately leverage existing commands to manipulate the in-process memory objects of your application. So not only is it *easy* to expose your application to automation, you can actually take advantage of the PowerShell engine to save work for your own in-application automation. With workflow engine integration in PowerShell 3.0 (it is now at 4.0) this is a great way to orchestrate workflows activities in an easy-to-manage way.

It has been available for several years now. It is used in App-V to access applications running on a server but displaying it'a GUI in windows on the local machine. I don't think you can use app-based RDP in a client Windows to client Windows configuration, though.

I sincerely apologize for the harsh tone. That was uncalled for, and I shot off without reading what I wrote and how it comes across. Again, I apologize.

Like you I have some "triggers". One of my triggers is blanket dismissal. I think what I perceived as your blanket dismissal was what triggered. You are correct about Ruby-on-Rails. It turned out that it was not up to the job. But at the same time it *did* popularize the "web-MVC" pattern in a way that Java frameworks (e.g. Struts) never achieved.

When someone praises a new technology as the new "best thing since sliced bread", we should approach it with a healthy portion of skepticism. However, we must also keep our minds open to new advances.

Reactive Programming is not an alternative to OO or FP. It complements both, and at the same time it promises to make certain aspects much more manageable, like e.g. asynchronous and parallel processing.

You get the machine *and* a $10000 for the first machine/browser to fall. While Apple machines are nice, $10000 will buy you a few *very* nice Apple kits, even if you exploit Windows first. Given $10000 for 1st price, $5000 for second, you'd expect the contestants to go for the easy one first. They knocked OS X over in a matter of minutes.

I'd take the $10000 rather than risking a 2nd place with $5000, thank you.

yes: http://technet.microsoft.com/en-us/library/hh750618(v=sql.10).aspx

That's the danger: Relying on your own lack of imagination to support your argument. If you cared to google a little you would realize that there are many other areas where RP could be relevant.

Erik Meijer who pioneered the RP push at Microsoft and which lead to the Reactive Extensions for C# and JavaScript (on which the current implementations in Java are based) wrote an article with a thoughtful title: "Your mouse is a database". I could as "so is your finger".

The idea is that a mouse is a series of "rows" with mouse positions and button states. Instead of viewing them as series of *events*, RP views them as streams of objects. That allows you to apply filters, actions, transformations etc.

Suddenly, the events become *composable*.

Think of a touch interface. The touch surface fires events. But if you view the events as streams of objects you can define filters and transforms which let only certain "events" through, like a stream which accepts objects starting/resetting at the "touch" but only accepts messages as long as they describe an ever longer diatance in a certain direction until the finger is lifted again. Now you have a composable stream of "flicks". You can define similar streams which will filter/generate circular moves, pinching with 2, 3 or 4 fingers.

Think of the problem of cache eviction. You can define sweeping/eviction algorithms as (simple) streams.

Think of asynchronous programming in a web browser. Parred with web sockets (or in .NET the awesome SignalR which uses web sockets but automatically falls back to other channels when web sockets are not available) you can build responsive, asynchronous interfaces where you *declare* what should happen as server messages are received.

Think of a dealer system where the dealer wants to track certain papers, positions, rates. RP enables you to build a chained, composable filter where alarms are raised (alarms being messages on streams) when a rate changes more than a certain percentage within a given time period.

Sure. Haven't we all?

Not neccesarily . In .NET, Reactive Extensions are integrated with LINQ. As a supplement to IObservable, Reactive Extensions also define IQbservable (a *queryable* observable). Analogous to LINQ for IQueryable, LINQ applied to a IQbservable is actually capable of combine criterias and transformations "up the chain" all the way to the source. I.e. if the "event" source is capable of filtering/transforming - like a SQL database or a RSS based web feed is - LINQ for Reactive Extensions can apply the filter very early in the chain and avoid uneccesary progression of objects which would be masked later anyway.

It is not just you. There a scores of other people out there who have always done it before 20 years ago.

Grow up. Sometimes Computer Science does see advanced. Realizations. Erik Meijer did an awesome job with Reactive Programming. He found a *duality* between actively "pulling" objects from sequences and reactively receiving "pushed" objects from a source. Given the mathematical duality he even managed to find places where the LINQ pull model was not complete yet.

Reactive Programming is not new. Nor was OO when it really took off. OO actually was don back in the 1970ies with Simula (IIRC). But now RP has *matured* as is ready to go mainstream. It is an interesting approach with combines beautifully with both OO and FP.

So please spare us the "I've done that for years" chest thumping. When you at the same time demonstrate lack of imagination and lack of understanding of the topic, you just come off as an ignoramus.