This privilege can be used to create and run processes under another user (including
SYSTEM) given proper access tokens for that user.
Windows Services are programs that run in the background to perform necessary operations for the operating system to function. When you say, "when an account other than Local System is used to run service, the SCM automatically grants the account certain security privileges", it should be noted that services can only be started by the following three Service User Accounts:
- Network Service
- Local Service
This means that to run a Windows Service you must already have the privileges of one of those three "users".
System is essentially an Administrator, and the other two are fairly high level user groups.
From the MSDN:
C++ constant: SE_TCB_NAME string: SeTcbPrivilege
Scripting short name: Tcb
Required to act as part of the operating system. The holder is part of the trusted computer base.
Services are extensions of the operating system, so it is not really surprising that the SCM gives this privilege by default to services. The Trusted Computer Base Privilege allows access to hardware device drivers and/or software components that are considered to be the "base" of the computer's (i.e. operating system) security.
Another exerpt from Microsoft:
Allows a process to authenticate like a user and thus gain access to
the same resources as a user. Only low-level authentication services
should require this privilege.
In other words this allows a process to impersonate a user. This does mean that you can run things as
SYSTEM. I know impersonate sounds terrible, but there is a mechanism built-in to Windows to "impersonate users". This is how
Run as Administrator performs its duties. However, to grant this privilege you must provide Administrator credentials in some way. If malware is already to the point of being able to assign itself this permission/privilege, then you're already in a lot of trouble.
Access Tokens are Windows way of allowing threads/processes/users to access certain portions of the operating system. Security Tokens are passed to almost every lower level function used in Windows. Because services are generally running at higher privileges, they are granted privileges for creating access tokens. When interacting with the desktop, they're probably interacting with user level objects. They will need to access, modify, and create tokens for this.
All of this behavior isn't out of the ordinary. Services are low level programs with high system privileges. The privileges that you mention are all standard privileges for services to have. A lot of malware will try to impersonate, or use services to gain access to the system because of this. See my answer here for a bit more information on that topic.