The good and the bad in Hyper-V's PowerShell As the great virtual war between Microsoft, VMware and various also-rans has rumbled on, many column inches have been devoted to Microsoft's Hyper-V Server. You can light up a cluster of 64 nodes and 8,000 virtual machines if you choose, it is said. Hyper-V server is free, you don't have to pay Microsoft a dime. That's a …
Is how it is so much more than just a shell. Unlike e.g. bash and other general CLI shells, PS has been designed with a hostable engine. A admin application can easily host a PS engine and let the cmdlets operate directly on the application in-memory objects. With a traditional text based shell that is not possible because the "objects" manipulated by the shell are not sharable in memory and the shell runs in its own process isolated from other running apps.
What this means is that vendors of servers/devices that need to be expose a management interface can implement the manageability *once* as PowerShell cmdlets. *Then* they can create a GUI admin module or admin website which merely uses the cmdlets through a hosted PowerShell engine. That is what Exchange does. That is what the new Server Manager in Server 2012 does.
No need to implement manageability twice, one or CLI and one for GUI. Simply implement cmdlets and build the GUI on top of the cmdlets. You have both scriptability, CLI and GUI. The fact that a vendor can follow this pattern and achieve two management interfaces means that we will continue to have both options: Concise and scriptable CLI as well as guided and exploratory GUI interfaces.
Is how it is so much more than just a shell. Unlike e.g. bash and other general CLI shells
Yeah, just like "IE, so can't completely remove it from the Windows OS, the latter won't simply run"
PS has been designed with a hostable engine.
What is it supposed to be? Host is an ancient root of Hindo-European origin and might mean many different things. hostable -- a derivative of host, hostage; hospitable or hostile, or is it a hospital?
the cmdlets operate directly on the application in-memory objects. I beg your pardon, if an app/process needs you to access it it has it's own interface for it. Have you heard of the server/client paradigm? A process is often listening to a specific port, you can send your commands/messages to. Alternatively, "ps -ex -o cmd,pid,ppid | grep 'my process' " will be your friend. Would you need to reinvent the MS wheel yet again?
Yes, everyone is happy that MS had finally got one Unix idea (after so many years of booing it). It dawned in Redmond as late as 2005, as I remember correctly (while GNU Bash was already bourn in 1989). So, what is so special about PS again, except for the ugliness of the command syntax and the fact that it is available on only one OS?
"A admin application can easily host a PS engine and let the cmdlets operate directly on the application in-memory objects"
So let me get this straight - a developer wants to use some external functionality so he'll embed an entire powershell engine in it which then calls out to a seperate program to run inside the engine which then manipulates the memory in his app?
Errr, riiight.
I'm sorry , but could you explain how exactly thats better than just loading a a 3rd party dll and calling someFunction() other than allowing crap developers to do things they otherwise wouldn't know how to do?
(In the same way some unix "coders" just use system() all over the place because the Posix API is apparently too complicated for them to grok)
So let me get this straight - a developer wants to use some external functionality so he'll embed an entire powershell engine in it which then calls out to a seperate program to run inside the engine which then manipulates the memory in his app?
Errr, no.
Look here: http://msdn.microsoft.com/en-us/library/windows/desktop/ee706610(v=vs.85).aspx
It is more like:
1. A developer creates cmdlets which constitutes management of his server application like e.g. setting permissions for users, configuring rules, setting failover policies etc. Now he can manage his application through CLI and scripts.
2. Then the developer wants to create an GUI for easy guided management. He starts to create a management GUI application. He realizes that he already has the functionality, only in a GUI you often use concepts such as lists with current/selected items etc. The developer creates the list views by calling his Get-UserPermission, Get-Rule, Get-FailoverPolicy cmdlets. Those cmdlets return objects which has methods and properties. Properties become list columns and methods are candidates for actions, as are his cmdlets such as New-UserPermission, New-Rule etc. The GUI application databinds to the properties and methods. So the management GUI application ends up as a simple shell around the cmdlets.
As a bonus(!) the GUI application can even tell the user what the actions look like when executed. If the user wants to he can copy-paste the command and later execute it from the command line. This is what Exchange does.
Had the cmdlets been traditional "external commands" of a shell that would be a *really* bad idea because external commands run in their own process and have a very narrow input/output channels where you have to serialize all input/output to/from text. But these are cmdlets and you can pass the very objects that was used to data-bind the lists. Cmdlets can manipulate the objects and/or produce new objects as result. Objects can have events so when the objects are changed by the cmdlets, the changes create notification events which the GUI app listens to and uses to update/synchronize the lists.
The cmdlets are the Command Object of the common Command design pattern.
I'm sorry , but could you explain how exactly thats better than just loading a a 3rd party dll and calling someFunction() other than allowing crap developers to do things they otherwise wouldn't know how to do?
Well, loading a 3rd party DLL is exactly what is going on. The PowerShell engine is itself a DLL - not an entire process. You simply load the System.Managent.Automation.dll in your application. When you initialize the engine you tell it which modules it should load from the start. You tell it to load your managtement module (a DLL) with your cmdlets. Cmdlets are really .NET classes where the parameters are public properties.
(In the same way some unix "coders" just use system() all over the place because the Posix API is apparently too complicated for them to grok)
No - not the same way. system() calls have an incredibly narrow communication channel and your host application cannot easily share objects with the processes it spawns this way. That makes that approach brittle and error prone. Still, because of the limited security model in *nix where some syscalls can only be run as root, developers are sometimes *forced* to do this. Sometimes it is a choice between system() to run a SUID utility or demand that your app has *root* privileges. The PowerShell cmdlets run in-process and the host application can simply share .NET objects with the cmdlets. If the host application subscribes to events from objects it passes to cmdlets it is notified about changes and can update active views accordingly.
"Well, loading a 3rd party DLL is exactly what is going on"
Except with a couple of pointless layers of bloat inbetween.
"your host application cannot easily share objects with the processes it spawns this way."
Well it could in theory by passing a shared memory key on the command line but its hardly ever done because if you need such close coupling you'd use a library, not a seperate program.
"Still, because of the limited security model in *nix where some syscalls can only be run as root"
And you think thats a BAD thing?? The MS kool aid has certainly done its job on you!
"The PowerShell cmdlets run in-process"
Oh excellent. So something someone else has written has admin priviledges running inside your process. I can see that ending well. Not.
Well it could in theory by passing a shared memory key on the command line but its hardly ever done because if you need such close coupling you'd use a library, not a seperate program.
The problem is that the shared memory key does not tell the receiver much about the object being passed. There is no ubiquitous object model available in *nix. A type-safe object model with runtime type information - like .NET or Java (or even COM) - makes passing objects orders of magnitudes easier.
Lacking a common object model, the sender and receiver need to have very specific knowledge about the objects being exchanged.
That is why PowerShell is a very good fit for Windows (and not for *nix) and why a flat-stream shell like bash is a better fit on *Nix than it is on Windows. PowerShell can leverage the objects already exposed through the Windows API (.NET, WMI, COM).
And you think thats a BAD thing?? The MS kool aid has certainly done its job on you!
Nah. I just think that being able to delegate the actual privileges my app needs would be awesome.
Why would my service have to become an all-powerful God just to configure a printer? In *nix you don't delegate privileges. The syscalls are not protected by a granular security model; only root can invoke certain privileged syscalls. Anyone who wants to call a privileged syscall has to become all-powerful root and gain privileges far beyond what is needed. Because that is an unmanageable security risk, SUID (setuid) tools are created and access to *those* are restricted. Internally they run as root but only a limited set of users are allowed to invoke the tools.
That design has (at least) 2 problems: 1. It requires you to invoke the functionality through system() calls because the functionality is exposed exclusively through tools (unless you are root). 2. The tool is *still* running in God mode. A single vulnerability in such a utility can allow an attacker unlimited access to the system. Thankfully a number of Linux distros have started to use more fine-grained Linux capabilities. Which are uncannily similar to privileges in Windows.
Oh excellent. So something someone else has written has admin priviledges running inside your process. I can see that ending well. Not.
I was not talking about code "someone else" had written. I was talking about a developer first creating a scriptable management interface (in a library) and then leveraging that library to *also* create a management GUI.
Under Windows you do not run your own services/websites with admin privileges. If the service needs some admin capabilities one can delegate those privileges to the service account. Just like you generally try to avoid running daemons as root on *nix.
In *nix you don't delegate privileges. The syscalls are not protected by a granular security model
I think you're confusing something here. Su and sudo do delegate the privileges if allowed. Actually, sudo does it more secure without changing the profile of the user.
What about groups and users, what about sudo (/etc/sudoers)?
Anyone who wants to call a privileged syscall has to become all-powerful root and gain privileges far beyond what is needed.
Not true. Many daemons are run under their own uid's and gid's (usually locked account). Root, or admin group can access them. If you think you can allow your users joe and kate to handle printers, you make them members of the lpadmin group. You can run your script with something like "sudo -g lpadmin" it won't have the root nor any other privileges.
I think you're confusing something here. Su and sudo do delegate the privileges if allowed.
I'm not confused. Sudo is itself a setuid/SUID utility. The tools that are executed with sudo are executed with effective user 0 (root). They can do *anything* they want.
Su and sudo do not delegate privileges at all. They execute with root as effective user, which is *not* delegation. During the execution you are *root* and any vulnerability in the tool can allow an attacker root access *even* if you restricted his access through sudoers.
The protection you have with sudo is that it checks the sudoers list first to see if you are allowed to execute the utility through sudo. The privileged syscalls still only checks to see if you are root.
If you want to execute a privileges syscall from your own app/daemon you will have to become root *or* make a system() call to sudo if you try to manage privileges that way.
Uffer, sorry, but this is not right.
First sudo can be executed "as another user" by an allowed user, not necessarily a root. BTW, both sudo and su when used with a username option ("sudo -u anotheruesr") don't get the uid=0 if that user is not root. Yes, you gotta provide the root password for su.
You won't be allowed to become a superuser out of "ordinary" account with sudo if you're not in a certain group listed in sudoers.
But as was mentioned earlier, you can always make a user a member of a certain group containing the owner of a daemon/service/file and thus granting him/her the necessary rights. This mechanism is much simpler than "granular permissions" used by the Windows. KISS is a universal principle, not only a *nix thing. Linux and other *nixes do have a more sophisticated account control utility acl.
BTW, on Adroid every app runs under its own uid by a user without user being an admin, moreover, root is locked on devices that are not rooted.
First sudo can be executed "as another user" by an allowed user, not necessarily a root
You are the one who is confused. sudo runs as root but can be invoked by an allowed user. Allowed users are listed in sudoers, but during execution sudo is definitively running with root as the effective user (euid==0). Really!
sudo and su when used with a username option ("sudo -u anotheruesr") don't get the uid=0 if that user is not root.
Correct. But "anotheruser" cannot invoke privileged syscalls. Only root can. To invoke privileged syscalls you need to have root as effective user. And when doing so you receive privileges far beyond what is needed for any single operation. Standard users cannot change time on a *nix system.
For instance, look at this BSD function: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/sys/settimeofday.c?rev=1.3
Clearly requires euid==0 to succeed when setting time. No other user can do it. You *need* to be root (as effective user) to be able to make that syscall.
To be fair, Linux has introduced Linux capabilities: http://linux.die.net/man/7/capabilities
As you can read from that page:
For the purpose of performing permission checks, traditional UNIX implementations distinguish two categories of processes: privileged processes (whose effective user ID is 0, referred to as superuser or root), and unprivileged processes (whose effective UID is nonzero).
But also note:
15) Where is the standard on which the Linux capabilities are based?
There used to be a POSIX draft called POSIX.6 and later POSIX 1003.1e.
However after the committee had spent over 10 years, POSIX decided
that enough is enough and dropped the draft. There will therefore not
be a POSIX standard covering security anytime soon.
There is no standard *nix way of describing capabilities. While some Linux distros certainly support SUID with capabilities instead of simply root, this is by no means universal and in general other *nix (including a large number of Linux distros) implementations still SUID root on a number of utilities.
Take a look here: http://aplawrence.com/Basics/sudo.html:
The sudo program itself is a setuid binary. If you examine its permissions, you will see:
---s--x--x 1 root root 81644 Jan 14 15:36 /usr/bin/sudo
So sudo *will* run as root. Every time. You may be able to instruct it to drop to another user before invoking a utility/tool. But sudo is most often invoked exactly because you want to invoke privileged syscalls. So dropping to another standard user rather defeats the purpose.
But "anotheruser" cannot invoke privileged syscalls.
anotheruser cannot invoke kernel privileged syscalls. And that is justified, this is security. What else do you mean by the "privileged syscalls"?
---s--x--x 1 root root 81644 Jan 14 15:36 /usr/bin/sudo
Strange policy, why root can't write on it?
On my Debian system:
-rwsr-sr-x 1 root root 116920 Jun 28 2012 /usr/bin/sudo
So sudo *will* run as root. Every time.
The reason it needs to have setuid root is that sudoers (and /etc/shadow) are only readable to root:
$ ls -l /etc/{sudoers,shadow}
-rw-r----- 1 root shadow 1270 Mar 30 18:08 /etc/shadow
-r--r----- 1 root root 669 Jan 30 2012 /etc/sudoers
This setuid thing is more subtle concept than you're trying to convey with it to be. No, sudo doesn't do anything else besides what it is supposed to. There is no security threat, unless a vulnerability gets there. Well, both sudo and su (polkit), especially the former is cleanly and simply designed, that is why vulnerabilities are rarely found.
Here is an example:
sudo -u postgres id
[sudo] password for eulampios:
uid=116(postgres) gid=126(postgres) groups=126(postgres),114(ssl-cert)
Nothing is done for root, except for reading the /etc/sudoers and maybe /etc/shadow
"No, it only reads some system files and writes logs into some system, files as root which is impossible to non root user. It doesn't grant you the root privileges, as mentioned above."
So it RUNS as root as stated several times now above. Otherwise how does it read / write 'root only' access files, unless Linux has an even more broken security model than the above already exposes?
how does it read / write 'root only' access files,
A user can start many processes that have to run as root. If you try to logout-login, for example, why? What else should be responsible for such an important and vulnerable task? If on Windows the same logout-login process, runas are not not controlled by the system and the password hashes are accessible to every user, so worse for Windows.
Linux has an even more broken security model than the above already exposes?
Yes, Linux has broken security model, Windows security model is great, forget all the malware you constantly scan your system for, look online how to get rid of this annoying virus, reinstall Microsoft Windows system. Forget on XP when many games and apps were to be run as root, because the the great model was not comprehended by the developers.
As a matter of fact, mechanism or utility like sudo is absent on MS Windows. Runas is more of an su. So it will always ask you to authenticate yourself for a user you're trying to be, not for the user you currently are. Take a look at how simple yet sophisticated a permission system could be made with sudo.
As a matter of fact, mechanism or utility like sudo is absent on MS Windows. Runas is more of an su.
That is correct. So how does Windows do it? It has proper delegatable rights and privileges:
http://technet.microsoft.com/en-us/library/bb457125.aspx
One of the most important security principles is called Principle of least privilege.
http://en.wikipedia.org/wiki/Principle_of_least_privilege
SUID/setuid tools like sudo is a violation of that principle. The utilities run with sudo will run with root effective user and thus have privileges far beyond what is needed for the specific operation.
In Windows, if a user or a service need to be able to backup the entire system, you can delegate that specific privilege to that user or to the service account. That does not mean that the user gains system-wide root privileges, not even briefly.
In Windows, the administrator and the administrators group have privileges not because they are hardwired into the system, but because the privileges have been granted to the administrators group. Those privileges can be removed and/or delegated to other users/groups. There is no account which inherently bypasses all security checks and auditing. This adheres to the Principle of least privilege.
So it will always ask you to authenticate yourself for a user you're trying to be, not for the user you currently are.
Yes, if you use runas. Runas is not an attempt to create a sudo. Sudo is not needed on Windows. Instead you assign privileges directly to the users that need them. Security bracketing is achieved through UAC prompt: If you have actually been granted powerful privileges, Windows strips those privileges from your token when you log on. When you go through the UAC prompt you are *not* becoming administrators as many - especially those with *nix background - seem to believe. Instead the original privileges are simply restored to the token for the duration of the specific process. So instead of assigning God privileges to the user, it merely assigns the privileges already granted to the user.
Take a look at how simple yet sophisticated a permission system could be made with sudo.
That is anything but simple - especially from a security administrators viewpoint. How is the SA supposed to audit privileges of a user when he has to consider text files on each and every system and multiple concurrent and competing security mechanisms (file permissions, file permissions of pseudo files, apparmor or SELinux security descriptors and then sudoers) that may bypass anything?
Tell me, how do I generate a report of the rights/privileges of a certain user?
The utilities run with sudo will run with root effective user and thus have privileges far beyond what is needed for the specific operation.
You keep repeating this, but this is wrong! There is no way you ever get uid=0 automatically by just running sudo. By some reason you think that the "setuid root bit" is equated to "becoming root" If this would be the case the setuid bits would never be invented by Dennis Ritchie ( the guy that was behind C, Unix and other great things) Why bother? No the -s- part for the root owner is needed because sudo should authenticate you (shadow) and verify if you are allowed to receive the privileges you're asking for. You can only "exploit" it by some virtual buffer overrun vulnerability, that barely had ever happened.
If Windows would allow an ordinary user to read shadow and sudoers bringing two much more imminent security threats to the table.
That is anything but simple
They are simple to me. BTW, as a rule the sudoers file looks even more simple than that. By default you just specify which group can be root. With sudo you can completely lock the root account (You can't do it with su).
file permissions
Extremely easy to handle and understand. First layer of Unix security. Say, unlike Windows you don't have to forbid execution on a directory you just make sure your potentially vuln. apps would strip the x permissions from a file.
apparmor or SELinux
MAC systems, they are competing products. AppArmor is actually an extension of the Unix file perms. SELinux uses a little different approach. You also forgot about the acl utility and different mount options (in fstab or via fuser, just like umask and similar).
You can make all or some of them to complement each other (most of the time sudo is used to lock root, e.g.) AppArmor would have some default profiles set up for web browser, document viewer and so on.
Tell me, how do I generate a report of the rights/privileges of a certain user?
Depends how much info you want. I'd suggest running id command :
uid=1000(eulampios) gid=1000(eulampios) groups=1000(eulampios),4(adm),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),113(lpadmin),120(sambashare)
You could take a look at /etc/passwd and groups. There is also a gui utility users-admin on mate, gnome and others. There might be more, I should look.
You keep repeating this, but this is wrong! There is no way you ever get uid=0 automatically by just running sudo.
(sigh). Try typing "sudo whoami" or "sudo id". So, what did it answer? On my system it says "root"!
So who am I when I run a command through sudo? Answer: root.
More proof: "sudo bash" and in the new shell do a "ps -aux|grep bash". What processes are listed? Which user do they indicate they run as? On my system it says that "sudo bash" and one "bash" process run as root.
When will you get this? sudo is a setuid/SUID tool. A setuid tool runs with the owner of the file as the effective user of the process. You may restrict *who* can call sudo in the sudoers file, but you *cannot* change the fact that sudo starts as root.
By some reason you think that the "setuid root bit" is equated to "becoming root"
Yes! yes! If you have execute permission to the file then you are becoming root when you execute it. Not "equated" to becoming root. You become root. Plain and simple. This is basic Unix/Linux stuff and I shouldn't have to explain this to a Linux advocate. Something is wrong with this picture...
Q:Tell me, how do I generate a report of the rights/privileges of a certain user?
A: Depends how much info you want. I'd suggest running id command :
Proving my point. The id tool does *not* generate a report of what a user can do when what you can do can be bypassed by sudo! The owner of a resource has no way of determining who has access to his resource, when tools with setuid root may just bypass. To correctly assess users that could access your resource you'll have to figure out which setuid tools exist on the system, who has execute right on the setuid root tools, what tools are allowed to execute through sudo and which users have access to those tools through sudo, and finally (and crucially!) knowledge about what each of these tools can do. Some tools, like "find" can actually execute commands(!) and other tools (editors) allow you to start new shells/processes. Such tools are very dangerous when allowed through sudo.
sudo whoami, sudo id
That is justthe default behavior!!! BTW, It has nothing to do with the setuid root of sudo! If you're not specifying, who you want to be , sudo thinks it is root, i.e., "sudo whoami"="sudo -u root whoami". From the man sudo:
The -u (user) option causes sudo to run the specified command as a user other than root.
The same goes with su. As well, "su"="su root", "su johnny" !="su" (asks for johnny's password, not root or your own). However, when you run "sudo -u postgres whoami" produces "postgres". Never does it let you be a root or anything else of you ask and what you're allowed to be. Moreover, the default sudoers would usually list the group that is allowed to be a superuser (wheel, admin or sudo).
A setuid tool runs with the owner of the file as the effective user of the process. You may restrict *who* can call sudo in the sudoers file, but you *cannot* change the fact that sudo starts as root.
Okay, than tell us how to effectively exploit this "vulnerability"? A lot of user actions might trigger starting a few root/system processes, say rsyslog, dmesg, kernel events etc Userland and system must communicate somehow. Your misinterpretation of setuid bits and the default options of sudo and su makes you believe your own argument.
If on your system you have two regular users and know passwords for each one you can jump from one user to the other via "su anotheruser". Notice, you never become a root here. If you don't know the root password running su won't let you be root, if root is locked it won't let you be one as well. Similar with sudo, if you are not a member of the group sudo on my Debian machine, but sudoers has this
uffe mydebian = (postgres) /usr/bin/psql
you'll be allowed to run "sudo -u postgres" only on mydebian machine, with your own password and would be able to become superuser of the postgresql database, not the whole system, as far as the psql shell is concerned, nothing else beyond that shell. You won't be able to stop or start the daemon/server of postgresql, nor anything else besides that. It's not "sudo", moreover you can get yourself in trouble, since sudo will tell on you to the administrator, so you gotta run "sudo -l" to see what you can and can't. That would give some statistics for you in the sudo system without the ability to see the complete sudoers file, BTW.
In that case, notice that never did sudo start as root!!!
Here's another example to explain the -s- bits. Consider the at utility of scheduling jobs at specified time (non on the regular basis, otherwise, it is similar to crontab):
ls -l $(which at)
-rwsr-sr-x 1 daemon daemon 55456 Jun 9 2012 /usr/bin/at
As you can see it does have the setuid for daemon, both group and user. However, when you run (as user eulampios):
at 12:00
warning: commands will be executed using /bin/sh
at> /usr/bin/id | /usr/bin/mutt -F /home/eulampios/.mutt/muttrc4 eulampios@localhost
at> <EOT>
You'll get a mail with "uid=1000(eulampios) gid=1000(eulampios)...." not "uid=1(daemon) gid=1(daemon) groups=1(daemon)", like the output "sudo -u daemon" would produce. Despite the daemon setuid and setgid bits, never does it let you be daemon. Is it clear now?
So again, you're confusing the default setup and the setuid bits concept, making baseless conclusions therein.
Proving my point.
And what is your point? MS devised a more secure system than any Linux or Unix ever did. Are you sure? What about all that malware that runs on MS Windows systems without the user's consent (and that is apart from the insecure repository models or the lack of thereof). What about XP, where many user apps could not even run without the admin rights? BTW, the homogeneous approach is always much an easier target than a heterogeneous one. So having many complementary (sometimes overlapping) highly customizable things is better than a single one.
That is justthe default behavior!!! BTW, It has nothing to do with the setuid root of sudo!
It has EVERYTHING to do with setuid root of sudo! It is the very way setuid works! Sudo may be instructed to *drop* to another user (-u option), but it starts as root (because the owner is root) and that is the default.
You may want to read this instructive article:
http://www.techrepublic.com/blog/security/understand-the-setuid-and-setgid-permissions-to-improve-security/2857
At the end you will find this "The general rule of thumb for setuid and setgid should always be, “Don’t Do It.” It is only in rare cases that it is a good idea to use either of these file permissions, especially when many programs might have surprising capabilities that, combined with setuid or setgid permissions, could result in shockingly bad security".
Nice.
Let me repeat. The operating system sees that the executable has the setuid flag. It then launches the process with the owner as the effective user. If the owner is root - then the process is running as root. A root process can drop to another user (seteuid http://man7.org/linux/man-pages/man2/setegid.2.html). Sudo will do that prior to executing the specified tool if the -u option is specified.
Don't believe me? You may believe the Linux man page for the sudo command: "Because of this, care must be taken when giving users access to commands via sudo to verify that the command does not inadvertently give the user an effective root shell."
Okay, than tell us how to effectively exploit this "vulnerability"
See above sudo man page security note.
or read this caveat from the same sudo man page:
"There is no easy way to prevent a user from gaining a root shell if that user has access to commands allowing shell escapes.
If users have sudo ALL
there is nothing to prevent them from creating their own program that gives them a root shell regardless of any '!' elements in the user specification.
Running shell scripts via sudo can expose the same kernel bugs that make setuid shell scripts unsafe on some operating systems (if your OS supports the /dev/fd/ directory, setuid shell scripts are generally safe)."
There has been many, many vulnerabilities in setuid programs. In general, a vulnerability in a setuid root process means assured system compromise because the attacher will be running as root. Ping is a setuid root utility. Here is an example of a vulnerability: http://www.halfdog.net/Security/2011/Ping6BufferOverflow/
A user who has execute access to ping with this vuln has root access and can compromise a system.
If on your system you have two regular users and know passwords for each one you can jump from one user to the other via "su anotheruser". Notice, you never become a root here.
It may look that way, but technically you are incorrect. su works by running as root and *then* dropping euid to the other user. Only root can do that because changing euid is a privileged operation. In this case the time spent as root is very short, so I can see how you may be confused.
Another setuid/SUID vulnerability: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3485
However, this is beside the point. Sudo exists because you need it. There is no delegation of privileges in standard *nix or in POSIX. You cannot delegate the right to change system time. Only root can do that. So to change system time you run "sudo date -s ...". Sudo is a setuid root and start as root. By default it runs the tool you specify as root as well, so the "date -s ..." succeeds and sets the time. Had you specified "sudo -u date -s ..." (drop to user) you would not had succeeded in setting the time. Why? Because only root can change system time.
Windows does not need an equivalent to sudo (and no it is not "runas"), because 1) it is a liability and 2) privileges in Windows can be delegated.
It has EVERYTHING to do with setuid root of sudo!
No, it has to do with authentication only. My example about setuid daemon command at will never let you be a daemon. Look at the example where a user is not in the sudo group and is never allowed to be root. I am sure that "delegating privileges" on Windows requires some very important system action that is hidden from you like in the POSIX suid bit.
BTW, if you think that anyone can set the time on the system and it is very safe, you're very wrong. Why not letting your user set his own time instead via gui or in the .bashrc file by setting TZ variable with
export TZ="/usr/share/zoneinfo/region/place"
Yes, you could put in the sudoers something like this:
someuser ALL=(ALL) /sbin/hwclock
Only one command hwclock to set machine time maybe run as root (not date BTW), no other one. This might be scary if hwclock has a vulnerability or some other feature you didn't consider, yet letting a non-root user set time is already scary enough. Better example is managing printers. It's done without sudo by making all physical users join a group lpadmin to be able to set up printer for their account (you can also mandate authentication through sudo setting). You do a similar thing with mounted media.
Then you're trying to tell me that vulnerabilities stem from this. Name them please. How many viruses, strains of malware have exploited it? What about the super secure MS approach?
The entity that just very recently removed Autorun/Autoplay functionality from they default action, started offering headless systems (after 15 years of bashing idea of a minimal system), that still needs AV scanning and AV "cleaning" . This very entity can certainly lecture on security...no, it better not.
I bow down to its power. But its a hopeless method for individual admin, and the answer go look up how to do this on google is a dire appalling place to end up. I think MS got this wrong. They clearly built it and its a powerful API and there is no doubt on that. But its power is in the create stage, not administration. MS and partners should rightly be building their tools and UIs on it. And many are.
I've found despite its power, its real world power is limited, and confined. And in most cases the unskilled or semi skilled are simply able to do more, better, and faster using older methods and older toolsets.
Real power comes from how applicable and usable something actually is.
And one final note. Hyper V has been junk level for an age. In 2008 R2, the real world method to actually make it usable was to go get tools from codeplex that IMHO should have been supplied, and the Hyper V team should have been hammered into the ground until they did so.
Trevor's article leads me to think they have learned nothing.
It is not that bad using hyperv 2012 on a workgroup. It is deliberately made much more complicated than it needs to by Microsoft so they can make money.
It would be better to have my testing stuff all on a domain but only when I can have server 2012 essentials (In a hyperv VM) and something else using samba 4 on a tiny box working properly together.
The article contains only the boring bits not the bits that are hard to work out from the docs.
" It is deliberately made much more complicated than it needs to by Microsoft so they can make money."
No - that's a ridiculous claim. Virtually all organisations will have Active Directory, so there is no money to be made by making it awkward not to. It is complex because it is not the recommended model, and because Microsoft require that security is still enforced, so you have a lot of tasks to do to create the security relationships that would normally be provided by Active Directory....
A quite enjoyable style it is! Thanks, Trevor..
There is a few things that a non-MS person might notice here.
Why not having one or a few editable config files to accomplish all described tasks plus a million of other things? No, I am not talking about the abominable Windows registry or XML gibberish. It's a common practice for the *nix systems to have a human readable/editable file, or a directory residing in /etc/ or else. For this purpose, MS would need to come up with not only alternatives to a *nix shells, but also with a decent editor, like vi(m) or GNU Emacs. Yes, it also remains to teach, convince your users that it is a good thing to use, a mere trifle ... not!
Otherwise, the main idea of pretty much every article dedicated to PS is See, you can do it with PS as well, without any GUI really, Yaaaay!!!"
There is a few things that a non-MS person might notice here.
Indeed
Why not having one or a few editable config files to accomplish all described tasks plus a million of other things? No, I am not talking about the abominable Windows registry or XML gibberish. It's a common practice for the *nix systems to have a human readable/editable file, or a directory residing in /etc/ or else.
Um. Why not use text files for everything? Because text files do not scale. Take a look at what Trevor was doing:
1: Joined a domain. A domain join is actually a complicated transaction where trusts are established. Domain accounts become trusted users of the computer. Would you establish such trusts by editing text files on every single computer? What about the relationship part of the equation. How would you query an organization for the computers (which may be offline)? Editing another text file to contain all the computers? Who will keep that in synch? Trust relationships cannot be established by editing a single text file, but they *can* be established through a single command. Which is what Trevor did. Would you prefer that an organization keep a text file with all computers authorized. Is this amateur hour? Text files do not scale as configuration store.
2: Trevor used commands to grant privileges. Would you prefer an enterprise use old-style passwd files to maintain their directory of users, accounts and privileges? Really? Or do you recognize that, well, text files are not really suitable for storing credentials and privileges?
3: Trevor used cmdlets to discover network adapters and their configuration. On linux you'd use ifconfig or ip. Or would you rather edit a text file?
4: Trevor then installed and activated failover clustering. I could see how that conceivably *could* be done by editing some text file. The "installation". However you *will* need to somehow activate it. A command perhaps?
5: New VMs can be created and started using cmdlets. Would you configure a new VM by editing a text file? How about space allocation?
For this purpose, MS would need to come up with not only alternatives to a *nix shells, but also with a decent editor, like vi(m) or GNU Emacs. Yes, it also remains to teach, convince your users that it is a good thing to use, a mere trifle ... not!
Abstracting configuration so it is accessed through an interface has numerous advantages. For instance, the configuration store can change and evolve while the commands maintain backwards compatibility. By NOT blindly copying the *nix text-file obsession it has become easier to create robust scripting for Windows.
Another advantage (also illustrated by Trevor here) is that the command approach allows computers to be configured through scripting from a remote controller. Yes, you *could* create scripts and send them across SSH. But with remote commands you can just issue the command from remote and not worry about which version of the text configuration file format the script has to work with on that particular system.
Otherwise, the main idea of pretty much every article dedicated to PS is See, you can do it with PS as well, without any GUI really, Yaaaay!!!"
Well, yes. Exactly. And because you can do it with PS you can do it with a GUI as well. You see, the GUI can host the PS engine. Look at how the Server Manager in Server 2012 can be used to administer multiple remote systems, issuing commands to execute simultaneously and robustly across multiple nodes.
Trevor is weirded out by all the third person references to himself. Also: I'm ambivalent about PowerShell, myself. I prefer flat config files wherever possible. I like to be able to get in with some basic string manipulation stuff that I know knock together in any scripting language (from BASH to PHP) and pick apart whatever the file is. PowerShell is very...Microsoft.
If it has to be "not a flat text file" I'd prefer that all configs be something I can pull and then re-enter as XML - which admittedly is sort of possible in PowerShell - by using the language of my choice. I don't have *time* to learn a new scripting language. Certainly not one as badly documented as PowerShell. (Though again, Microsoft is getting better here.)
I *like* doing my configs in PHP for two reasons: I know the language by heart, and PHP.NET has the best damned documentation on the planet. Replete with examples and a community contribution section where commenting, common use cases and expansion on the functions in the language are integrated into the documentation.
In Linux I can easily knock together a BASH script that takes down a service, runs a PHP script to make whatever changes I need, then lights back up the service. I can manipulate all sorts of stuff in the file system in PHP and basically work in an environment I'm comfortable in without having to learn a whole pile of new stuff.
PowerShell is amazing. It's a great technological achievement and a good way of doing things. But it still doesn't have a command-line text editor. I can't simply *live* in PowerShell the way I can in bash. I have hundreds of servers I have only ever interacted with using SSH and BASH...PowerShell always requires me to pull up a PowerShell IDE or Notepad (at least!) and probably a dozen browser tabs to figure out what the hell I am supposed to do.
There's an element of "Get off my goddamned lawn" to my PowerShell ambivalence. But there is also a sense that the people designing PowerShell are DevOps-style "we're developers that think we're sysadmins" types who design for great big farms of identical machines. They aren't sysadmins who have only a handful of servers and who have to make changes to live systems without 8 days of testing in the lab.
PowerShell is for people who live in cleanrooms. BASH is for people who take cars apart and have grease on their hands. At least, that is how it has seemed to me so far.
But it still doesn't have a command-line text editor.
Have you thought of using the old ones? Vim and GNU Emacs, for instance? Here's one more link and I am sure that vim has a capability for it too. I'd recommend Emacs for it's immense power and the polyglot essence (bash, php, grep, Perl -- you name it).
BASH script that takes down a service, runs a PHP script to make whatever changes I need
I use a shell-on-steroids Perl if bash/awk/sed and friends code gets too complex to handle.
No, I can't use the old ones because they aren't ubiquitous. The Text editor *NEEDS* to be part of the CLI and installed on BLOODY EVERYTHING with PowerShell on it. This is why I won't move back to Windows for my unattended servers; the tools I need just aren't there as part of the CLI shell. If I have to start installing a bunch of tools onto my Hyper-V boxes then they cease being simple, interchangeable deployments and start being special flowers that each need attention. EDIT was part of the DOS-style command line for ages. BRING IT BACK.
Perl is good for those raised on Perl. I cut my teeth on VB and PHP. I'm not a developer by trade, and while I can read Perl, I don't think in Perl. I have coded so much PHP in my life that I think in PHP. I don't know of any other way to explain it; every other language I use is one for which I have to build a translation matrix in my head and map that functions of that language back to PHP functions that are part of my mental "muscle memory."
I can go months without using PHP and then pick it up again in minutes. If I go even a few days between Perl, Python, PowerShell or other coding stints, I'm pretty much back to square one. I don't know if that makes sense, but that's how it is. I don't have an eidetic memory; if I am going to learn a language it is going to have to be something I use every single day for so many months that it is burned into my synapses. For me, the ONLY things that ever achieved that level are DOS BATCH, HTML, and PHP.
If you want the barrier to uptake, it's that, RIGHT THERE. PowerShell is the bee's knees if you can work with it for 8 hours a day for months on end and you have time to learn, play, explore and so forth. If you manage a heterogenous environment and spend the majority of your time hip-deep in Linux, VMware and DSM (with Windows largely taking care of itself) then PowerShell is a hindrance, not an enabler.
PowerShell is a bitch of a thing to get in to if you only do Windows part-time...and the majority of that isn't "experimenting", it's "putting out fires."
No, I can't use the old ones because they aren't ubiquitous. The Text editor *NEEDS* to be part of the CLI and installed on BLOODY EVERYTHING with PowerShell on it.
I am curious. If a server is running headless, why would you need even a text editor? Why do you not use powershells remoting capabilities, e.g. from PowerShell ISE?
Invoke-Command (alias icm) can execute script files remotely, even when the script file resides locally on the controlling host. It can execute single script blocks or script files as part of the same session. The script executing remotely can even refer to local variables (something that bash cannot do and could be a reason you choose to "jump" (SSH) to the remote machine.
Because you often have to set the damned thing up using IPMI or other such things to get them remotable *before* you can get remote access even working. Other times you want to work on a file that lives on the system without dragging the file off the system or finding some way to get access to the local file storage on that system from your remote station.
In a unix world the shell is all. I just need one port open and I can get through to do my administration. No additional services, no additional windows, no nothing. Just one black box per server. In the Windows world I have to strip the bloody server naked and let all the bits hang out so that I can even edit a text file! WHAT. THE. FUCK.
Microsoft still lives and breathes eggshell security. Harden your edge, but behind that edge you need to wander around with your WMI, SMB and $deity only knows what else hanging out just to do basic administration! This is in contrast to a Linux world; there I have a hardened edge and layers of security - from obscurity by changing SSH off default ports to things like Fail2Ban to lock out attacks to layers of logwatching - that lock down a server INSIDE my network just as though it were facing the internet itself with no deprecation in usability or administerability.
Look, I don't buy eggshell security. Securing the edge is not enough. A) the edge is coming to you. IPv6 will eat your family. B) Something behind your edge is always compromised. Wee willy wonka the lobotomised salesdrone really likes barney BDSM porn and he's perpetual infected. Meanwhile, you forgot to firmware update your IPv6 lightbulbs and half of them are supporting malware that's probing your infrastructure from the inside.
So no, I don't want to use the PowserShell ISE. This doesn't solve my problem of opening a test file on the remote server without opening more holes. Not only that, the damned thing is Windows only; I stopped using Windows as my primary desktop environment ages ago. Have you seen Windows 8? Microsoft lost the plot and their corporate ego won't let them regain it.
Powershell is a necessary evil. It is unquestionably the future of administering Windows Servers because Microsoft says it is the future of administering Windows servers. What it isn't is good enough. It's all sorts of bitchin' and powerful but it is still designed solely for cleanroom sysadmins with their procedure manuals and testlabs and 3 month concept-to-implementation timeframes.
It is not something that lets me log in to a system and fix the fucking thing. It is a configuration tool that I see akin to "the Cisco IOS for Windows Server and associated applications." You don't log on to a CIsco router and just fix it. You never make live changed to a production unit without simulating and testing and layers of covering your own ass.
PowerShell is the same thing. You build your PowerShell config carefully in your cleanroom and then you push it out to the system and set that system's state. PowerShell really, really wants to be Puppet when it grows up. Given the awesomeness of Puppet, DevOps as a model for enterprise and commercial midmarket IT and so forth...that's great! Go Microsoft!
Systems administrators for smaller shops where budgets, staff and every other conceivable resource are as minimal as possible are firefighters. When you fight fires all day long, you want this. This is what Bash and the associated bog-standard utilities are.
When I'm in the middle of trying to put out 50 fires at the same time and you tell me to use PowerShell you are telling me to put out a burning building with this.
PowerShell is not a way to administer a system. It is a way to configure it. They are still completely different things. You can get yup on your horse and sneer disdainfully at the rest of the world and say asinine things like "well, if those sysadmins were any good, they'd never have fires to put out because they'd have adopted DevOps and be doing everything with huge pre-planning and simulation and testing." I'm sure you've thought it more than once reading this comment.
The reality of the matter, however, is that the majority of systems administrators simply don't get that option. They aren't in control of the budget. They don't set corporate IT policy. They don't have much control over any aspect of their jobs, really, and they simply do as they are told or they get replaced. They are told what to do not by some senior IT person who is themselves responsible for setting policy, but by the accountant, the sales clerk, the marketing wonk, the CEO and the janitor.
In most companies, sysadmins are the lowest ranking member of the corporate structure. They are there to serve. To make things happen whenever they are told and they are not expected - or allowed - to talk back. If they say no, they get fired; pure and simple.
In this situation, these people are fighting fires all day. They are fighting fires because they have to make quick changes to live hardware without simulations or a testlab. They need to back all this up (before and after) and they need to manage hundreds (if not thousands) of different types of devices and applications.
They move from device to device, server to server, application to application solving other people's problems in real time. This is why they can't use eggshell security. IT could be months or even years before they get back to a given system and then only because it did something it wasn't supposed to.
Every system they use has to have a complete set of tools on it. They can't wander around remotely accessing the system from their carefully maintained desktop; there may be layers of firewalls, VPNs, and gods only know what else between them and the target system. They may be RDPing in to server then RDPIng into another system then launching PuTTY to manage something because of a series of political and economic decisions taken by the business over the course of decades that isolated that system in that office in this particular way.
PowerShell as it stands today is virtually useless in that environment. Again: it is for configuration not administration. Maybe next version...
You clearly do not know as much as you think you know about Unix/Linux land.
I think that you Windows guys need to relax, yes you have discovered the power of scripting, that is all good and fine, but most of us have known this for like... lots of years?, even on windows, (remember vbscript? or any other Admin RAD?)
In my opinion (yes mine you can disagree with it) I have work extensively in both environments: Powershell is not specially powerful, the syntax combines some of the worst aspects of Bash and Perl with the slowness of a .NET environment. It is not completely without hope, but it is just an OK environment compared to what windows offered before, and most of the power comes from what functionality the application vendor exposes to the shell.
But yes, it is so good to think that MS is the beginning and the end of the Computer industry.
"""2: Trevor used commands to grant privileges. Would you prefer an enterprise use old-style passwd files to maintain their directory of users, accounts and privileges? Really? Or do you recognize that, well, text files are not really suitable for storing credentials and privileges?"""
Really, why not? go on, elaborate, for example Cisco must be doing a really shoddy job not recommending all customers to store the router credentials on a MS Microsoft AD domain, and spewing horrible text files on a console that contains usernames and encrypted password hashes.
I'm sure that a binary file being all that binarly and all improves system security a lot.
Also I'm sure that every single computing scenario out there requires the complexity of AD, and I'm also sure that no one else on the planet has managed to centralize authentication on a network other than Microsoft's AD.
You can just use a flat text file for things like a list of hostnames in Powershell, which is what I usually do for something that's just a list.
If your data is a bit more complicated (eg, a list of RSS feeds with title and update schedule), then XML makes a bit more sense (to me) over a flat list (or csv or something). I tend to use Notepad++, so XML is human readble/editable.
Yes, it would have been nice if Microsoft had implemented a proper scripting language 15 years ago (and we'll ignore how many cries of "they're just copying *nix" there would have been), but as it stands, they've got a proper scripting language now, isn't that a good thing?
Well done Microsoft for realising that certain things are far far far more efficient doing them on the CLI..
Shame your 'hyper-v' will still be years behind Libvirt/KVM in terms of flexibility, performance (if you use LVM+virtio for disk) and cost (£0)
Anyone who thinks KVM's performance is behind Hyper-V hasn't done it right - Windows VM's are very fast if you choose virtio and use the NONE cache setting in advanced IO.
Please define how KVM is 'more flexible'?
Hyper-v Server also costs £0 - and has a much lower TCO than other Hypervisor solutions.
And actually if you want a supported version of KVM like Red Hat - it costs a hell of a lot to license it. Especially if you enable functions like clustering, storage resilience, etc. that are free with Hyper-V, but are optional expensive add-ons with RH.
Hyper-v Server has outperformed KVM ever since the release of Hyper-V Server 2008 R2, and the gap is larger with Hyper-V Server 2012. Fro instance show me a KVM host running a single VM with 1 million IOPS like Microsoft demonstrated last year? No? I didn't think so....
Also worth noting that KVM is limited by having to run on top of a Linux OS, whereas Hyper-V Server is a dedicated Hypervisor OS (like VMware ESXi)...
Flexibility in the sense that an image can be converted to other hypervisors 'easily', the ability to resize partitions inside an vm image regardless in they are the first partition on the disk (i.e /dev/sda) - see virt-resize. Flexibilty due to the fact you can script in a Linux environment which is years ahead of 'power'shell.
There is a reason most of the big hardware players are fully supporting and getting behind KVM - i.e IBM, HP, Intel i.e
http://openvirtualizationalliance.org/blog/why-does-hp-believe-in-open-source
"KVM is a great fit for HP customers. Using HP cloud-optimized servers; web hosting service providers can roll their own infrastructure, enterprise customers can deploy integrated hardware and software solutions, and everyone can deploy application workloads in the HP Cloud."
> Hyper-v Server has outperformed KVM ever since the release of Hyper-V Server 2008 R2
Utter rubbish = seriously do benchmarks, KVM out performs Hyper V in IO by a serious margin when setup correctlyu - i.e LVM + virtio + correct cache settings.
> Fro instance show me a KVM host running a single VM with 1 million IOPS like Microsoft demonstrated last year?
KVM has achieved World Record IOPS: 1,402,720 IOPS
http://linux.uits.uconn.edu/mas02041/2012/06/28/kvm-technology-review-and-roadmap-update/
> Also worth noting that KVM is limited by having to run on top of a Linux OS, whereas Hyper-V Server is a dedicated Hypervisor OS (like VMware ESXi)...
You do know that ESXI is still forked from the Linux kernel also - see ovirt (ovirt.org) - its a Linux ESXI equivalent.
It should like at least half your beliefs are just assumptions not fact.
This post has been deleted by its author
So - you can also convert Hyper-V images to / from ESXi . You can easily resize Hyper-V disks. Saying that shell scripting in a Linux environment is ahead of Powershell instantly tells me that you don't have a clue what you are talking about. Powershell is far more powerful than any current Linux shell.
More hardware players support Hyper-V virtualisation than any other platform except ESXi
Look at the benchmarks - Hyper-V consistently outperforms KVM - and performs very close to ESXi- better than ESXi in some ways (e.g. IO performance) but worse in others (e.g. memory efficiency).
That KVM IOPS total was not on a SINGLE VM like Hyper-V. The KVM number is the maximum throughput of multiple VMs and is meaningless in comparison.
And another FAIL - the ESXi Hypervisor is NOT forked from the Linux kernel. You are confusing the Console, which is Not the Hypervisor.
(Notable that ESXi is now managed via Powershell due to the additional capabilities and security, and the majority of the legacy UNIX style tools / scripting have been ditched....)
Worth noting that the KVM claims to the top spots in the SpecVIRT bnechmarks are largely because they used larger boxes than the competition to measure their results - for instance the top result is from an HP DL980 with 80 cores! If you look at the underlying performance versus hardware, ESXi is faster....
"Yes, the Windows kernel is nowhere in sight on Hyper-V."
The Windows kernel is a hybrid microkernel, so you can ditch most of the 'OS' to just provide the required hypervisor capabilities. With the Linux monolithic kernel model, the full OS (and all the associated vulnerabilities and attack surface) remains.
And further worth noting that with Hyper-V, the Hypervisor sits directly between all hardware and the root partition, and that a copy of the Windows microkernel will run in the root partition - but is not the Hypervisor.
Whereas with KVM, the hypervisor runs as part of the kernel, which is a less efficient and secure model as you have a much fatter hypervisor layer...
Interestingly, the VMware vSphere PowerCLI implementation is mature and pretty awesome.
A great advert for PowerShell cmdlets and, I believe, even recognised by MS as an excellent implementation.
As with all languages it's possible to be inefficient with your code, but balance that with its accessibility (compared to the normal SDK) it's a great tool for those that still prefer scripts.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
