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;

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

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.

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

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.

(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

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.

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.

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

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
>> 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.

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


NTDEV is sponsored by OSR

Visit the list online at: <
http://www.osronline.com/showlists.cfm?list=ntdev\>

MONTHLY seminars on crash dump analysis, WDF, Windows internals and
software drivers!
Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>