Feature Request: Make sudo more powerful #301
Comments
|
Wow thank you so much for this! This is a incredibly helpfull. I've desired to learn how to create tokens from scratch for so much time, but since I don't monetize gsudo I must focus on other work streams. I've thought of doing something like this in the TokenProvider class class. If we could craft the token there, it is gracefully used in the "token switch". There is a but... gsudo is intended to be a convenience security tool. We have to consider the overall impact on system security, as we don't want gsudo to be flagged as a malware toolkit by Microsoft or AV vendors. Therefore, we need to be cautious about which features to include in its scope. I'll give it some thought and circle back to this issue when I have more time. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Okay this ended up being a really long-winded one, but bare me with as I really need to lay down the groundwork first to fully demonstrate my point.
Description
As you are probably well aware, Windows doesn't really have a concept of a "root" user nor have access control directly tied to users per-se, but instead is centered around security descriptors which describe privileges, access control lists and security groups. Processes are then tied with access tokens, which are containers of said descriptors. Access control is then managed by comparing the caller process' access token against different combinations of required privileges and group member-/ownerships depending on the situation.
Case example
For example, there is really no such thing as a "TrustedInstaller" user, but it is instead a "SYSTEM"1 user who is a member (and owner) of the "TrustedInstaller"2 group.
Let's say you need to modify securable objects3 which can be modified only by "TrustedInstaller", which many times is the case when you need to customize the operating system be it for your own local installation or when configuring Windows images for deployment using the Windows ADK.
Let's look at the two following privileges:
SeBackupPrivilege
SeRestorePrivilege
At a first glance, it seems that having those privileges enabled would do the thing. However, those bypass the ACL only for file operations, but not other ones like modifying registry keys or scheduled tasks, and you will run into a "access denied" error. To be able to have full access to the keys, you need to be a member of the "TrustedInstaller" group and there is no privilege to get around that requirement in every case.
Summary
In summary, to be able to have full access to everything means you need to pass whatever access checks the OS throws at you. Like mentioned before, these are combinations of checks against which privileges and groups the token has. In addition to "grant" access checks, there are also "deny" checks to verify that the token is not a member of a specified group, such as "Guests."4.
Also the different API calls, some of which date back to 1993 (Windows NT 3.1), are not always 100% consistent in their access requirements — as using different versions of essentially the same function residing in different modules, or getting to the same end result with a different set of calls — can have differences in their checks and therefore the access needed5.
There really ought to be a "absolutely bypass every single access check" privilege, but alas, that is not the case.
Even something that sounds like it, SeTcbPrivilege6, doesn't achieve that.
In the spirit of "show, don't tell", let's move on to tests for further demonstration.
Tests
All tests were carried out with gsudo v2.4.0 portable inside an official Windows 11 VM (August 2023) from MSDN of following build:
First, let's view the privileges and groups we acquire using the SYSTEM option,
gsudo -s.#> gsudo -s whoami /all
Right, the default integrity level (High) doesn't match the one needed (System). Let's try again.
#> gsudo -s -i System whoami /all
Okay, now we're in business. Let's do the same for the TrustedInstaller option,
gsudo --ti#> gsudo --ti whoami /all
And then the regular Administrator elevation,
gsudowith no parameters.#> gsudo /whoami all
And finally in the unelevated command prompt, without gsudo.
#> whoami /all
See those outputs and the differences between them. To further understand the issue here, let's move on to the next part.
The Problem
So we've now talked about how access is controlled by privileges and groups, both of which are contained inside the access token.
The process executing the commands, in this case
cmd.exe, has the access token which the sub-process ofwhoami.exethen inherits and prints the information about the token. The key insight here is that no matter what you are doing, access token is the key.Comparing the outputs of tests above, we can see how each of them have differing amounts of access. While the integrity level is straight-forward, being either higher or lower; not so much for the groups and privileges.
You can see that while the regular admin elevation is a straight-up upgrade, the SYSTEM and TrustedInstaller options are not. Losing some groups and privileges while gaining others makes using
gsudo -sandgsudo --tioptions win some, lose some situations.Furthermore, you can see that not only are many of the privileges disabled, some of them don't even exist in some but do in others.
What's up with that? Well, that brings us to another problem we need to tackle.
Basically, the bouncer at the door checks whether you have a full glass of water, and you can empty or fill up a glass, but you can't fill up a glass which you don't already have.
When access tokens are created, they are assigned privileges which can either be enabled or disabled.
But you cannot add new privileges to an existing token. So when we need additional privileges, enabling existing privileges isn't enough.
The Goal
If you are still reading, kudos to you.
As all of this seems rather complicated and so far we've only added layers of problems on top of another, let's define our goal.
To summarize, these are the components we're working with
a) the integrity level (single, ranging from "low" to "system")
b) sets of different privileges (multiple; can be either enabled/disabled)
c) group memberships (multiple; with attributes enabled, deny-only, owner)
What do we want?
Obviously in a true sudo fashion, all of them.
a) highest integrity level, "system"
b) all privileges, each of them enabled
c) all "good" groups like Administrators, but not the bad ones like Guests
That might seem like a tall order because of the many roadblocks like not being able to enable existing privileges or add new groups when we don't have the privileges to do that, not to mention that adding new privileges can't be done.
There is also some further complexity when it comes to traversing the boundaries between integrity levels, and there also are different types of access tokens like impersonation tokens and then impersonation levels in regards to those, but we'll skip that for now.
For all of these problems, fortunately a rather simple and almost perfect solution exists. Let's finally explore that.
The Solution
So now you understand the problem, and here is the solution.
Presenting the backstage pass, all-you-can-eat combo deal, diplomatic passport equivalent of access tokens – the all-access token.
As we determined that the hardest problem is not being able to add privileges to an existing token, the solution is rather simple – we simply create a new one.
Again in both the spirit of "show, don't tell", and because the technical explanation would take forever in a post that is already too long, I have prepared a working code example in lieu of more words.
And now let's see the output of
sudo /whoami all#> sudo /whoami all
As you can see, we have successfully added and enabled every privilege in existence, along with the most important well-known groups and thrown in some additional ones for good measure.
Adding the TrustedInstaller group to the token instead of loaning it from the trustedinstaller.exe process also saves the step of needing to start the trustedinstaller service as we don't need the process anymore is also a plus.
As to why this solution isn't perfect, points back to the fact we started with regarding to access control defined by groups. We can enable all access related to privileges, but it's possible to configure the OS with any combinations of groups and accesses related to them and as such it's infeasible to cover every possible configuration without coloring outside the lines and resorting to dirty hacks. But this should cover most of the typical setups, and those people who have made their unique configurations would already know how to deal with the specifics of them.
For the general user, this should cover pretty much everything, no matter the version or edition from Vista to 11 and the Server counterparts of them. Granted I've only tested this on Windows 7 Ultimate, Windows Server 2012 R2, Windows 10 Home and Windows 11 Enterprise but it should work for all the other ones too, along with 99% of whatever use-cases without running into a "access denied" error.
This is probably the closest you can get to a true "root" user in Windows in a clean manner using existing APIs without hacking, modifying, bypassing or exploiting anything. In essence it's simply a matter of piecing together the correct configuration for the highest level of access, which to be frank is unnecessarily complex, but in the end it all comes together after figuring it out.
Proposed technical details
Use the techniques as shown in the winsudo example.
Glossing over the specifics, here is the rundown:
a) Copy the attributes of the existing token as a base
b) Add all privileges to it as enabled (tkp_all in the example)
c) Add "good" groups which are guaranteed to exist, with attributes mandatory/enabled/owner where applicable (tkg_good in the example)
d) Add "extra" groups which might or might not exist depending on version and edition of Windows by checking their existence first (tkg_xtra in the example)
e) Modify existing groups, remove deny-only attribute and add enabled attribute wherever applicable
The code example does work stand-alone and can be used as-is, but it really is a condensed small application of just the sudo functionality needed without any fancy features of this project like a proper pseudo-terminal, terminal detection, configuration options, etc. So absorbing the core functionality from that to this project would result in a best-in-slot sudo solution.
I see the project uses both .NET and PowerShell, which are kinda the same thing after all in many ways.
As you can call native functions from .NET like you already do, all of the C example code can be transferred to .NET / PS.
If you want it to be faster, another idea could be to keep all the native code in C and compile it as a DLL exporting a function call to "Elevate()" or whatever, then including the DLL in the .NET project as a resource and then using the FindResource / LoadResource / LockResource APIs to load the DLL from a resource to memory and then call the exported function from .NET.
Well, I don't think this fulfills the "concise" rule of creating issues, but I'm not sure I could've explained it properly in any other way. Sorry about that 😅
Footnotes
SYSTEM User SID S-1-5-18 ↩
TrustedInstaller Group SID S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464 ↩
Securable objects can be files, registry keys, services, processes, jobs, etc. ↩
Guests Group SID S-1-5-32-546 ↩
For example — a) saving a registry key to a file using RegSaveKey or b) querying a registry key with RegQueryValueEx and then saving the result to a file — achieve the same end result, but are different operations requiring different levels of access. ↩
SeTcbPrivilege: "Act as part of the operating system" ↩
The text was updated successfully, but these errors were encountered: