I'm trying to find a list of Win32 API functions that require the process that uses them to have heightened administrative privileges in order to use them. Does anyone know where I could find a list of these functions? Thanks!
Such a list simply does not and can not exist. Because an API alone does not determine what privileges are required (it can, but in most cases it doesn't).
For example take one of the oldest and most used APIs there is: CreateFile.
Reading a file in the windows directory is allowed for normal users, writing/creating one however isn't.
Using the API to create a local pipe
is allowed for normal users, creating
a global pipe or networked pipe
usually isn't (depends on further
security settings/group policies).
And many more examples.
Related
I would like to test some software and would like to make it well-behaved regarding cloud files. For reference functions like RtlIsPartialPlaceholder and RtlIsCloudFilesPlaceholder have been introduced in order to look at the information returned when traversing the folder hierarchy. The above links point to kernel mode documentation, but these functions also exist in user mode (ntdll.dll) and they are really implemented very trivially.
However, in order to test said software I would have to be able to somehow create the states a placeholder for a file on OneDrive can be in.
What functions (registered COM classes would also be fine) can I use to automate creation of a reproducible test set up which I can use to:
create placeholders
only partially hydrate a placeholder
achieve the same for both directories and files
PS: this question was the only one remotely connected to the topic, which I was able to find here on SO.
Standard file/directory operations (create/read/write, etc.) can be achieved transparently using the Win32 API. That's the whole point of this technology.
So, you can create a placeholder using the standard Win32 APIs.
If you create a file or directory in a "sync root" (like in the OneDrive folder hierarchy in the OneDrive case), the associated sync engine process (like OneDrive.exe) will ensure the file or directory is a placeholder. And you can't create a placeholder outside of a sync root hierarchy, AFAIK.
For a file (you can't hydrate or dehydrate a directory), reading/writing correspond to hydration. Note that some sync engines (and/or depending on their configuration) can decide to always fully hydrate a file even if only some bytes were asked by the end-user API (applications).
There are some specific Win32 APIs though for special operations.
You can dehydrate a file using CfDehydratePlaceholder. You can hydrate a file CfHydratePlaceholder. For all the Cloud Filter API, when creating directory handles, don't forget to use the FILE_FLAG_BACKUP_SEMANTICS flags.
I looking for an API method that retrieve the info that "net view /domain" does.
namely, I'm looking for a way to enumerate the visible domains within a forest, using win32api (in C environment)
thanks.
Update:
it seems that DsEnumerateDomainTrusts can do what I need, however, it doesn't looks like net.exe importing it, so I'd still like to know of other options.
Update2:
as it's name imply, the function only enumerate trusted domain, even when DS_DOMAIN_IN_FOREST is specified,
so I'm in square 1.
I think that in your case the best way is to interrogate Active directory.
You will find in this answer the way to get all the domains in your directory, first requesting "rootDSE" to find the configuration naming context, second requesting for crossRef with nETBIOSName to retreive domain entries
As you are interested in how to interrogate active directory from native code, you may have a look to LDAP C-Binding API as discribed in RFC 1823 specifies, Microsoft support it, see MS Strategy for Lightweight Directory Access Protocol (LDAP). You'll find the using and reference manuals of the Microsoft API in Lightweight Directory Access Protocol.
follow up to: Windows Filesystem Minifilter Drivers: can I monitor and prevent FS operations using them?
I'm looking for a method to filter access to certain file system resources.
This includes removable media and non-ntfs file systems - so standard ACL won't work.
from what I read, a files system driver filter might be helpful - but I didn't find a way to get the user id of the initiating user.
Is this possible?
other recommendations \ references to existing tools are also welcome.
I am not sure what does "user id" mean. But this might be useful:
When handling IRP_MJ_CREATE look at IrpSp->Parameters.Create.SecurityContext->AccessState.
ACCESS_STATE contains SecurityDescriptor and SubjectSecurityContext.
From SubjectSecurityContext you can retrieve PACCESS_TOKEN if you need it (call SeLockSubjectContext and SeQuerySubjectContextToken).
Have a nice day!
In most cases obtaining security information (token) of the user that initiated the call is possible, at least for operations such as file open and directory enumeration (and these are main points of filtering when you plan to prevent access of the user to the resource). And then you can cancel or modify request as you need. The only limitation I can think of is when the network redirector accesses the disk on behalf of the remote user impersonated as local system account. But these are border cases that you would need to investigate yourself in your particular task.
Using WTSGetActiveConsoleSessionId and WTSQueryUserToken, I know it is possible for a service running as SYSTEM to launch an application onto the current desktop without using a password. Is to launch CreateProcessAsUser without needing a password for LogonUser provided the program launching the process has sufficient privileges?
EDIT 1: The situation is vaguely similar to this instance, but I need to be able to launch a process as a user regardless of whether or not they are logged on to the system at the time.
There is the possibility of using the undocumented NtCreateToken function; I think this example project uses it. Short of that, it is not possible.
Depending on the token you are trying to forge, you will require certain privileges, in particular the TCB one springs to mind. Services have that. The "Windows NT/2000 Native API Reference" by Nebett has an example.
However, services creating a process as SYSTEM on the current desktop is not as easy anymore since Vista. The improved session separation is the issue here. However, you could impersonate the user at the other end of a pipe and the current thread should be able to act as that user (e.g. SYSTEM).
Theoretically, at least, you could implement your own authentication package and then use it to generate a suitable token.
Another possible option, depending on your exact requirements, is to use the SidsToRestrict and PrivilegesToDelete option of the CreateRestrictedToken function along with SetTokenInformation to create a suitably modified derivative of your own token.
However, I would not trust this approach if you're going to be running untrusted code: I'm not entirely certain that it wouldn't be possible for a sufficiently ingenious attacker to use such a token to attack the parent process or other privileged processes. (In particular I'm not sure whether you'd be able to create a new logon session and assign it to the restricted token; this might not be the only issue.)
We're building an application designed to run on Windows-based servers. One of the considerations we're looking into at the moment is how to control access to the application's GUI, which allows configuration and controls the "back end" services.
In order to secure the application properly, there are several objects which will need ACLs to be applied - files, directories, Registry keys, named pipes, services etc. We need to provide administrators with some way to configure those ACLs in order to limit access to authorized users only.
One approach we have considered is to create a tool which can modify the ACLs on all those objects simultaneously, but that would be a fair chunk of work and could be fragile.
The other possible approach we're looking at is to create a custom group (e.g. "My App Users") so we can give that group the appropriate rights to each object. This means that administrators will be able to add/remove authorized users by using familiar Windows group membership tools.
So: is creating groups at install time an acceptable thing to do, or is it likely to upset administrators? I'm more familiar with the UNIX world, to be honest, where server-based apps are more or less expected to create groups, but I'm uncertain of the etiquette in the Windows ecosystem.
Also: is there a better solution to this that I've missed?
Thanks in advance!
The question is twofold - one technical, and one political. Technically a local group is fine, you can add AD or domain users into a local group and everyone's happy. In terms of whether an app should be messing with a server's security 'stance', the only reasonable answer is to pop up some kind of request telling the user what you are going to do and asking permission (make sure you also document the decision in some kind of log or entry). This also addresses everybody's legal a$$ eg if they click "no, leave my app unsecured" and get hacked).
Taking a UNIX approach, you could tell the user what you need, suggest a local group (and give the user the chance to pick another local or domain/AD group). Take a look at how (eg) Oracle installs on UNIX do it.
Since this is a server app and you might have to support silent/unattended install, make sure that the behavior can be specified in the install script and very, very sure that the behavior of the script is documented so that no one installs the program without realizing the change in security policy that the installer implements.
I think it's perfectly fine to create a local group for this purpose.
Furthermore I have not been able to come up with a better solution after giving it some thought.
Depending on the size of the implementation, groups could be the way to go.
But please keep in mind that the relevant ACLs on directories and the registry ought to be set. I do agree that setting them once to the group and then let access control be maintained by group memberships.
In regards to klausbyskov's answer, I think a local group could be fine, but consider using LDAP instead. From a security perspective you would detach the authentification process and let the Directory handle it; using kerberos.