Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting... Please check out the Community Guidelines in the
Announcements and Administration Category, below.

Check is admin

Gova_GimerGova_Gimer Posts: 24
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;

Comments

  • Peter_ViscarolaPeter_Viscarola Posts: 6,651
    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Posts: 12,567
    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.

    Tim Roberts, [email protected]
    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
  • Tim_RobertsTim_Roberts Posts: 12,567
    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Peter_ViscarolaPeter_Viscarola Posts: 6,651
    (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

    Peter Viscarola
    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
  • Mark_RoddyMark_Roddy Posts: 4,263
    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
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!