Re: Login

From: Matthew X. Economou (xenophon+usenet_at_irtnog.org)
Date: 07/05/05

  • Next message: russell kym horsell: "Re: anyone successfully compiled Open Office ?" 
    Date: 04 Jul 2005 23:25:36 -0400

    >>>>> "fato" == fato <usina@osmail.mine.nu> writes:

        fato> Hi, I'm not pretty sure, but I think root is a really good
        fato> equivalent of administartor in the windows
        fato> environment. System user looks like more a daemon user
        fato> account than admin.

    Comparing the antiquated Unix permissions model to the more modern
    (and vastly more complicated) Windows NT access control mechanisms is
    like comparing apples to oranges, but I find myself agreeing with
    Fixx's comment. In the Windows NT family, the SYSTEM account is the
    security ID under which the operating system itself acts. This
    corresponds to the root account on UNIX system. There is not direct
    analog to the Administrator account, as it is limited (however
    slightly) in what it can do. For instance, certain registry keys
    (such as the SAM keys under HKEY_LOCAL_MACHINE\Security) are
    inaccessible to the Administrator account; root has no such
    limitations.

    To answer Anders Lund's question about accessing the SYSTEM account:
    it IS possible. The trick with which I am most familiar is using the
    Windows scheduler service via the BSD-ish "at" command. There used to
    be a privilege escalation bug where non-admins could submit jobs to be
    run under the SYSTEM account via the command line, as described at
    http://www.arson-network.com/index.php?class=tutorial&subargs=155. I
    used to use this in hacking demos all the time. Another way is to get
    the Windows Service Control Manager, roughly equivalent to BSD's
    /etc/rc, to run your command within the operating system's security
    context (see http://www.virweb.com/wintools.htm or
    http://www.nobodix.org/seb/win2003_adminpass.html for examples).

    Abusing the Windows NT access control mechanism is so much fun.
    Theoretically, DACLs are way more powerful than the "superuser" model
    UNIX has used for the last 35 years, but DACLs are difficult to design
    and implement correctly. Theoretically, one could use DACLs to exert
    fine-grained control over a Windows NT system, locking it down in ways
    not possible even in SELinux or TrustedBSD, not even Microsoft does
    it, and certainly just about every application vendor out there (big
    ones like GE or Siemenns or whoever) has no clue how to use DACLs, to
    the point where what should be normal, every day applications require
    admin access on workstations in order to run properly. To the point
    where Microsoft is designing this really kludgy indirection system
    in order to transparently fool applications into thinking they are
    accessing privileged files or registry keys, when in reality they are
    only accessing files/keys in that user's home directory. Ugh, a very
    nasty hack.

    Anyway, now that we are way the heck off topic, should I set followups
    to somewhere in microsoft.public.*? :)

    Best wishes,
    Matthew

    P.S. Yes, I know about POSIX ACLs, SELinux, and TrustedBSD. Yet every
    UNIX system I have administered in the last 10 years still uses the
    old superuser security model, with administrative access from
    non-admin accounts brokered by hacks like sudo or RBAC. MAC/DAC
    simply isn't in wide use in the UNIX world, commercial or otherwise. 

    -- 
"In the social equation, the value of a single life is nil; in the
cosmic equation, it is infinite."
    - Arthur Koestler, _The Invisible Writing_
  • Next message: russell kym horsell: "Re: anyone successfully compiled Open Office ?"

    Relevant Pages