Updated (at bottom)
I have a UMDF video driver based upon the IddCx sample. I have a command-line test (running 'As Administrator') that calls CreateFile on a video adapter device instance to get a handle to it for IOCTL purposes. The test fails on the CreateFile call with Access Denied
I discovered that if I simply disable and re-enable the adapter in Device Manager, and then re-run the same test, it succeeds. The test will continue to succeed until I restart Windows, or uninstall/reinstall the device.
The test's CreateFile call itself doesn't trigger any calls to my driver (more on that below), so I can't easily debug it from the bottom up.
Toggling the adapter device's enabled state changes SOMETHING such that the exact same CreateFile call succeeds. I decided to trace the CreateFile call until it fails... here's what I've found:
--- User Mode ---
mytest!CreateFile
ntdll!NtCreateFile
--- Kernel Mode ---
nt!IopCreateFile
nt!ObOpenObjectByNameEx
nt!ObpLookupObjectName
nt!IopParseDevice
nt!SeAccessCheck [returns Access Denied]
nt!IopParseDevice calls nt!SeAccessCheck, and when that returns FALSE, nt!IopParseDevice sets last error to Access Denied and returns failure.
Now, here's the interesting part (that I need help with):
The parameters passed into nt!SeAccessCheck are slightly different, depending upon whether I run my test before or after I disable+enable my device. Notably, the provided SecurityDescriptor parameter's SECURITY_DESCRIPTOR_CONTROL member changes:
(after Windows restart or adding new adapter device)
0x9814 (SE_SELF_RELATIVE | SE_SACL_PRESENT | SE_DACL_PRESENT | SE_DACL_PROTECTED | SE_SACL_AUTO_INHERITED)
(after disable/enable adapter)
0x8014 (SE_SELF_RELATIVE | SE_SACL_PRESENT | SE_DACL_PRESENT)
I don't know enough about Windows security to understand what these two flags signify in the larger context. Can anyone shed light on what might be going on?
Update #1:
I've found that this behavior happens with the Windows-driver-samples video\IndirectDisplay example project. The only change was to add a call to WdfDeviceCreateDeviceInterface between WdfDeviceCreate and IddCxDeviceInitialize, and to add a do-nothing EvtIddCxDeviceIoControl callback (just calls WdfRequestComplete with STATUS_INVALID_DEVICE_REQUEST). So, it doesn't seem to have anything to do with my particular driver (unless it's something I'm failing to do...)
Update #2:
This gets curiouser and curiouser...
It turns out that every time I cycle through disbling and then re-enabling the driver, the security descriptor that gets used is toggled (between the above two options).
Related
I'd like to get event in kernel on each new process that starts (fork+execve or posix_spawn), and be able to prevent this operations.
The first option would be using Mac framework named mpo_vnode_check_exec by Hooking to this method with function that return 0 when access is granted or check deferred to next hook.. non zero returned value means access is refused right away.
Unfortunately, this framework is unsupported by apple, and I wish to use a stable alternative like kauth fileop scope with KAUTH_FILEOP_EXEC flag.
However, this framework is for detection only and lacks prevention capabilities..
Perhaps there's a way to prevent the process from running when I get relevant kauth callback on process creation, or halt the process from running until I decide whether it should run or not (and enforce the verdict in another thread).
thanks
However, this framework is for detection only and lacks prevention capabilities..
Correct, if you're only focussing on the File scope.
Register with the Vnode scope and your callback returns whether or not access is allowed.
kauth_listen_scope(KAUTH_SCOPE_VNODE, &myCallback, NULL);
Finally, note that this scope is very noisy, as every type of access to every resource is reported.
I have a Windows 10 machine where some UI process runs happily for days until it silently exits without any visible exception.
I have enabled ETW tracing but pretty much all call stacks come up with ???? marks. I suppose there was no proper ETW provider rundown happening in this process. After enabling Process Destruction call stacks I have found that one
[Root]
ntoskrnl.exe!KiPageFault
ntoskrnl.exe!KiInitiateUserApc
ntoskrnl.exe!KiDeliverApc
ntoskrnl.exe!KiSchedulerApcTerminate
ntoskrnl.exe!PsExitCurrentUserThread
ntoskrnl.exe!PspExitThread
ntoskrnl.exe!PspExitProcess
Does this indicate a page in error so I should suspect a hardware failure of the hard disc or memory?
I have found a failed file io request at that time:
The specified request is not a valid operation for the target device.
(0xc0000010) = Event SubType, FSCTL = Event Type, C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.ServiceModel\v4.0_4.0.0.0__b77a5c561934e089\System.ServiceModel.dll
which makes me think that the hard disk has an issue.
I have a Windows application that interacts with some hardware. A handle to the hardware is opened with CreateFile, and we control the hardware using DeviceIoControl.
I'm attempting to update an application which uses this hardware to open the hardware in an exclusive mode, so that other programs can't access the hardware at the same time (the hardware has mutable state that I can't have changed out from under me). I do this by passing 0 as the dwShareMode parameter to CreateFile. After making this change, I am still able to run two separate instances of my application. Both calls to CreateFile in both processes are successful. Neither returns INVALID_HANDLE_VALUE.
I believe one of several things is happening, and I'm asking for help narrowing the problem down.
I badly misunderstand the dwShareMode parameter
dwShareMode doesn't have any effect on DeviceIoControl - only ReadFile or WriteFile
The driver itself is somehow responsible for respecting the dwShareMode parameter and our driver is written badly. This, sadly, isn't totally unheard of.
Edit Option 2 is nonsense. dwShareMode should prevent the 2nd CreateFile from happening, DeviceIoControl has nothing to do with it. It must be option #1 or option #3
The Question:
Is the device driver responsible for looking at the dwShareMode parameter, and rejecting requests if someone has already opened a handle without sharing, or is the OS responsible?
If the device driver is responsible, then I'm going to assume #3 is happening. If the OS is responsible, then it must be #1.
Some additional Clues:
IRP_MJ_CREATE documentation suggests that the sharing mode does indeed get passed down to the device driver
I believe that sharing rules are only enforced on some devices. In many (most?) cases enforcing sharing rules on the device object itself (as opposed to on objects within the device namespace) would make no sense.
Therefore, it must be the responsibility of the device driver to enforce these rules in those rare cases where they are required. (Either that or the device driver sets a flag to instruct the operating system to do so, but there doesn't seem to be a flag of this sort.)
In the case of a volume device, for example, you can open the device with a sharing mode of 0 even though the volume is mounted. [The documentation for CreateFile says you must use FILE_SHARE_WRITE but this does not appear to be true.]
In order to gain exclusive access to the volume, you use the FSCTL_LOCK_VOLUME control code.
[That's a file system driver, so it might not be a typical case. But I don't think it makes a difference in this context.]
Serial port and LPT drivers would be an example of a device that should probably enforce sharing rules. I think there may be some applicable sample code, perhaps this would shed light on things?
Edited to add:
I've had a look through the Windows Research Kernel source (this is essentially the same as the Windows Server 2003 kernel) and:
1) The code that opens a device object (by sending IRP_MJ_CREATE to the driver) does not appear to make any attempt to enforce the sharing mode parameter, though it does check access permissions and enforces the Exclusive flag for the driver;
2) I've also searched the code for references to the structure member that holds the requested dwShareMode. As far as I can see it is written into the relevant structure by the internal function that implements CreateFile, and later passed to the device driver, but otherwise ignored.
So, my conclusion remains the same: enforcing the sharing mode rules, or providing an alternative mechanism if appropriate, is the responsibility of the device driver.
(The kernel does, however, provide functions such as IoCheckShareAccess to assist file system drivers in enforcing sharing rules.)
In cases where we open a COM port with :
CreateFile(devname,GENERIC_READ | GENERIC_WRITE,
0,
0,
OPEN_EXISTING,
0,
0);
It doesnt allow another application to open the same COM port until the previous handle is closed. I would suggest walking through serenum.sys to check if it has a role here.
I'm developing a driver that hooks some functions in windows (hardening driver that will block some actions). The problem is, that I want to log which was the user who attempted to run those actions.
For example, I've put an hook on ZwSetValueKey in order to filter registry writing.
The hook works perfectly, But I don't know how to get the caller SID. I've found out that I can determine whether the mode of the caller(i.e. user mode or kernel mode) using ExGetPreviousMode. But I'm not really sure how to determine the SID if the caller was in user mode.
Thanks.
If this were user mode, you'd start with GetCurrentProcess or GetCurrentThread, and then call GetProcessToken or GetThreadToken. This would get you an access token, from which the SID can be extracted directly. In kernel model, there's PsGetCurrentProcess and ZwOpenProcessTokenEx, and the like for threads.
Here's the equivalent question for user space: How to get Calling-Process Windows User Access Token.
I haven't tested this, but I hope it gets you started.
VOID SeCaptureSubjectContext(Out PSECURITY_SUBJECT_CONTEXT) is probably the kernel-mode API you're looking for, at least if you have ntifs.h available.
I have implemented a class that gets local printers and, depending on the application option, uses one of the local printer available.
Firstly, the class enumerates the printers (EnumPrinters - PRINTER_ENUM_LOCAL) and saves the corresponding PRINTER_INFO_2. Then, it gets printer capabilities (DeviceCapabilites) and DEVMODE. Each class instance will access one printer.
When application selects the printing option, it selects which printer will be used and its corresponding instance of the class. Then, this instance creates the device context:
m_hdc = CreateDC (m_pi2->pDriverName, m_pi2->pPrinterName, NULL, m_pdm));
where
HDC m_hdc;
PRINTER_INFO_2 * m_pi2;
DEVMODE * m_pdm;
and process all printing data accordingly.
The problem is that sometimes, the CreateDC return NULL and GetLastError() return ERROR_FILE_NOT_FOUND(2).
I mean 'sometimes' because in other machines, with same printer, same processor, same Windows XP SP3 image and same test data, the CreateDC processes correctly. In addition, the reinstalling the system and application the problem disappears sometimes no.
I am looking forward to hearing any suggestion that helps me to find out the issue.
Thank you in advance.
It sounds like a problem loading a file required by the printer driver. You could use Process Monitor (a free SysInternals tool downloadable from microsoft.com) to get a bunch of information about what's going on at the time of the error. I'd do a capture and look at failed file and registry accesses. The fact that it fails intermittently on one particular machine seems consistent with a messed up driver configuration.
Another thing you could try is to create an information context rather than a device context. You can't print with an IC, but you can query information about the device, which may be a way to get additional information.