locked
How are tokens w/o mandatory integrity SID treated? RRS feed

  • Question

  • I have a question related to Mandatory Integrity Control (MIC).

    Usually all user tokens contain an additional SID in the groups list,
    which is one of the MIC SIDs (S-1-64-x) denoting the integrity level.

    Tests under RC2 (Build 5744) with tokens missing the MIC SID don't show
    any special behaviour. A process running with an administrator's token w/o
    MIC SID seems to have all permissions which an administrator usually has.
    In terms of MIC the result looks like the token is treated  as having "high"
    integrity (S-1-64-12288).

    The question is this: What happens in the kernel, if the token does not
    contain one of these MIC SIDs? How is that token treated? Does it
    automatically belong to one of the MIC levels and which one is that?


    Thanks,
    Corinna

    Thursday, November 9, 2006 4:45 PM

Answers

  • There's no contradiction but I could have been clearer.
    The documentation on this is a little behind.

    When TokenMandatoryPolicy is not set (TOKEN_MANDATORY_POLICY_OFF is default), the MIC sid is worthless.
    Hence your results.
    The LSA will set the mandatory policy of most (if not all) tokens to TOKEN_MANDATORY_POLICY_NO_WRITE_UP | TOKEN_MANDATORY_POLICY_NEW_PROCESS_MIN. The MIC sid comes into play at this point...

    Monday, November 13, 2006 8:18 PM
  • Thanks for the explanation!

    Do you also, by any chance, know the exact meaning of the
    TOKEN_MANDATORY_POLICY_NO_WRITE_UP and
    TOKEN_MANDATORY_POLICY_NEW_PROCESS_MIN flags?


    Thanks,
    Corinna



    P.S: The original question has been answered by Jeffrey Tan in the newsgroup
    microsoft.public.win32.programmers.kernel, see
    http://groups.google.com/group/microsoft.public.win32.programmer.kernel/msg/6008bdad60d5c476
    Monday, November 13, 2006 8:47 PM

All replies

  • Do you mind sharing how you obtained such a token?
    As far as I know all tokens created by the LSA should have an integrity SID.

    Thursday, November 9, 2006 6:31 PM
  • The tokens have been explicitely created using Nt CreateToken.  Since it's
    apparently possible to create tokens without MIC SID
    this way, it would be
    interesting to learn how these tokens are
    treated by the kernel.

    Corinna
    Friday, November 10, 2006 9:08 AM
  • From which component? A driver? No service should have the privilege required to call this API.
    You're in unsupported territory at this point.

    Apparently, tokens without an explicit integrity SID are considered untrusted (the lowest level).
    On the other hand, assuming you haven't set the TokenMandatoryPolicy either, the token in question is immune from integrity checks... which is not very desirable.

    Friday, November 10, 2006 9:37 PM
  • > You're in unsupported territory at this point.

    That was not, in fact, part of the consideration.  It's a simple question:
    It is possible to create tokens w/o MIC SID, so what does the kernel make of them?

    > Apparently, tokens without an explicit integrity SID are considered untrusted (the lowest level).
    > On the other hand, assuming you haven't set the TokenMandatoryPolicy either, the token in
    > question is immune from integrity checks... which is not very desirable.

    Sorry, but... doesn't the first statement contradict the second one?  From my tests
    I don't see these tokens being treated as lowest level so I assume immunity from checks
    is more probable.  However, I read of TokenMandatoryPolicy the first time in your reply.
    The SDK documentation seems to stop at TokenSessionId.  Any pointer?


    Thanks,
    Corinna

    Saturday, November 11, 2006 9:29 AM
  • There's no contradiction but I could have been clearer.
    The documentation on this is a little behind.

    When TokenMandatoryPolicy is not set (TOKEN_MANDATORY_POLICY_OFF is default), the MIC sid is worthless.
    Hence your results.
    The LSA will set the mandatory policy of most (if not all) tokens to TOKEN_MANDATORY_POLICY_NO_WRITE_UP | TOKEN_MANDATORY_POLICY_NEW_PROCESS_MIN. The MIC sid comes into play at this point...

    Monday, November 13, 2006 8:18 PM
  • Thanks for the explanation!

    Do you also, by any chance, know the exact meaning of the
    TOKEN_MANDATORY_POLICY_NO_WRITE_UP and
    TOKEN_MANDATORY_POLICY_NEW_PROCESS_MIN flags?


    Thanks,
    Corinna



    P.S: The original question has been answered by Jeffrey Tan in the newsgroup
    microsoft.public.win32.programmers.kernel, see
    http://groups.google.com/group/microsoft.public.win32.programmer.kernel/msg/6008bdad60d5c476
    Monday, November 13, 2006 8:47 PM
  • It will be clearer when the documentation is available but the short version is:
    NO_WRITE_UP pretty much enables the MIC SID (making sure the level of the subject writing is greater or equal to the level of the object).
    NEW_PROCESS_MIN makes sure that the level of a subprocess is MIN(subject creator level, file object level).

    I believe the other answer referred to the default level of objects (when they don't have a label)...

    Monday, November 13, 2006 10:25 PM
  • Uh, thanks, that's helpful!

    Corinna
    Tuesday, November 14, 2006 3:42 PM