Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

OSR Seminars


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 8  
09 Jul 18 15:02
Gova Gimer
xxxxxx@sivaller.no-ip.org
Join Date: 26 Mar 2018
Posts To This List: 2
Check is admin

Hello , this code ioctl don't work, it return always status denied. I want determine if user is admin. case IOCTL_CMD_FILE_TEST: { /*PVOID p = ExAllocatePool(NonPagedPool, 64 * 1024 * 1024); if (p != NULL) { KdPrintfcriti(("Oui")); } else KdPrintfcriti(("Non")); status = STATUS_SUCCESS;*/ if (irps->Parameters.DeviceIoControl.InputBufferLength >= sizeof(LUID)) { LUID FatSecurityPrivilege = { SE_SECURITY_PRIVILEGE, 0 }; RtlCopyMemory(&FatSecurityPrivilege, irp->AssociatedIrp.SystemBuffer, sizeof(LUID)); if (!SeSinglePrivilegeCheck(FatSecurityPrivilege, UserMode)) { status = STATUS_ACCESS_DENIED; } else status = STATUS_SUCCESS; KdPrintfSure2(("Security test %d return status:%x\n", FatSecurityPrivilege.LowPart,status)); } else status = STATUS_BUFFER_TOO_SMALL; } break;
  Message 2 of 8  
09 Jul 18 15:57
Peter Viscarola
xxxxxx@osr.com
Join Date:
Posts To This List: 6243
List Moderator
Check is admin

Is there a QUESTION in that post, or are you simply sharing your observation with the world at large? Assuming you're asking WHY SeSinglePrivilegeCheck always seems to return FALSE, you'll have to tell us: 1) What LUID are you using? FatSecurityPrivilege isn't a "real" LUID that I know about. 2) In what context is this code running... do you know for sure... and how do you know that? Peter OSR @OSRDrivers
  Message 3 of 8  
09 Jul 18 18:07
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 12008
Check is admin

xxxxx@sivaller.no-ip.org wrote: > this code ioctl don't work, it return always status denied. > I want determine if user is admin. The whole concept here is silly.  Why would you invoke a driver to ask about your current privileges?  You can call GetTokenInformation for TokenPrivileges and learn this information in user mode directly. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 4 of 8  
16 Jul 18 08:23
Martin Burnicki
xxxxxx@meinberg.de
Join Date: 11 Oct 2017
Posts To This List: 13
Check is admin

xxxxx@probo.com wrote: > xxxxx@sivaller.no-ip.org wrote: >> this code ioctl don't work, it return always status denied. >> I want determine if user is admin. > > The whole concept here is silly.  Why would you invoke a driver to ask > about your current privileges?  You can call GetTokenInformation for > TokenPrivileges and learn this information in user mode directly. Hm, a case that immediately comes to my mind: If you have a driver that provides an API e.g. via IOCTL for a specific PCI card then the calling application isn't necessarily your own one, which properly checks the permissions before it calls the IOCTL. It can also be a 3rd party application run by any user, so I think it's a good idea that the driver checks if the calling process has sufficient rights to do the requested action on the PCI card, e.g. to write some card-specific configuration to the card. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: xxxxx@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
  Message 5 of 8  
16 Jul 18 11:37
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 12008
Check is admin

xxxxx@meinberg.de wrote: > > If you have a driver that provides an API e.g. via IOCTL for a specific > PCI card then the calling application isn't necessarily your own one, > which properly checks the permissions before it calls the IOCTL. > > It can also be a 3rd party application run by any user, so I think it's > a good idea that the driver checks if the calling process has sufficient > rights to do the requested action on the PCI card, e.g. to write some > card-specific configuration to the card. Hmm.  I would expect to handle this by setting an SDDL string on your driver, so that unprivileged users couldn't open a file handle to begin with. I think you're trying to argue that perhaps some ioctls could be privileged and some unprivileged.  I'm just not convinced that's a driver's responsibility.  The  whole concepts of users and permissions are user-mode concepts. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 6 of 8  
16 Jul 18 13:36
Peter Viscarola
xxxxxx@osr.com
Join Date:
Posts To This List: 6243
List Moderator
Check is admin

(What Mr. Roberts said. As a matter of architecture, it is best to try to keep explicit policy out of your driver, and out of kernel-mode, whenever possible) Peter OSR @OSRDrivers
  Message 7 of 8  
17 Jul 18 03:30
Martin Burnicki
xxxxxx@meinberg.de
Join Date: 11 Oct 2017
Posts To This List: 13
Check is admin

xxxxx@probo.com wrote: > xxxxx@meinberg.de wrote: >> >> If you have a driver that provides an API e.g. via IOCTL for a specific >> PCI card then the calling application isn't necessarily your own one, >> which properly checks the permissions before it calls the IOCTL. >> >> It can also be a 3rd party application run by any user, so I think it's >> a good idea that the driver checks if the calling process has sufficient >> rights to do the requested action on the PCI card, e.g. to write some >> card-specific configuration to the card. <...excess quoted lines suppressed...> Indeed. E.g., my driver is for PCI/PCIe cards that are used for time synchronization, and there are lots of IOCTL codes that are used to read the current status or configuration from the card, which is permitted for every user, or to write some configuration settings to the card, which is denied for non-admin users. > I'm just not convinced that's a > driver's responsibility.  The  whole concepts of users and permissions > are user-mode concepts. Basically I agree this could be handled with read/write access permissions to the driver. However, in case of IOCTLs I'm not aware of a way to handle this except by checking the permissions inside the driver. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: xxxxx@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
  Message 8 of 8  
17 Jul 18 06:33
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 4100
Check is admin

You could create two device objects, one privileged, one not so privileged. Mark Roddy On Tue, Jul 17, 2018 at 3:29 AM xxxxx@meinberg.de < xxxxx@lists.osr.com> wrote: > xxxxx@probo.com wrote: > > xxxxx@meinberg.de wrote: > >> > >> If you have a driver that provides an API e.g. via IOCTL for a specific > >> PCI card then the calling application isn't necessarily your own one, > >> which properly checks the permissions before it calls the IOCTL. > >> > >> It can also be a 3rd party application run by any user, so I think it's > >> a good idea that the driver checks if the calling process has sufficient > >> rights to do the requested action on the PCI card, e.g. to write some <...excess quoted lines suppressed...> --
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 19:27.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license