rainit2006 / My_Windows

0 stars 0 forks source link

系统用户,Administrator、Service #11

Open rainit2006 opened 7 years ago

rainit2006 commented 7 years ago

Administrator VS SYSTEM user The main difference between the Administrator and SYSTEM is that Administrator is an actual account (for example, it has a password) whereas SYSTEM is not. (Properly speaking, SYSTEM is a "security principal".)

One practical difference is that, if the computer is joined to a domain, processes running as SYSTEM can access domain servers in the context of the computer's domain account. Processes running as Administrator have no access to domain computers unless the password happens to match or alternative credentials are explicitly provided.

It is possible for a file, directory, registry key, or other securable object to only grant access to SYSTEM and not to Administrator. However, I'm not aware of any examples on a default installation of Windows. Edit: I forgot about the SAM key, containing the local account information. This has full control granted only to SYSTEM, with the Administrators group having neither read nor write access. Kreemoweet has also pointed out that Vista has a number of other examples.

rainit2006 commented 7 years ago

ーーー

rainit2006 commented 7 years ago

ーーーー

rainit2006 commented 7 years ago

Windowsサービス ー サービスと通常プログラムの違い ① 通常のプログラムは、ユーザーが起動します。 ② 基本的には起動したユーザーの権限で実行されています。通常のプログラムを「管理者権限」で実行させることも可能ですが、その場合は明示的に「管理者として実行する」必要があります。 ③ ログインしてからの起動になりますし、ログオフするときには停止します。

Windowsサービスは、 ① ユーザーがログインしていなくても、Windowsの起動と同時に実行させることが可能です。 ② 権限も、あらかじめ設定しておくことが可能です。 セキュリティソフトなど、ログインしていない状態でも立ち上がっていてほしいプログラムは、Windowsサービスとすることで、Windowsの起動と同時に実行させることが可能となります。

また、サーバーでは基本的に、電源が入っていればすべてのサービスが実行されています。これらのサービスもWindowsサービスとして実行されています。

rainit2006 commented 7 years ago

浅谈Windows访问控制在.NET(C#)中的实现(ACE, SD, DACL, SACL) https://www.mgenware.com/blog/?p=70

//基本ACE abstract class AuthorizationRule //属性(属性名称:类型名称) IdentityReference: IdentityReference;
//所针对的安全主体的标识 //System.Security.Principal.IdentityReference类 InheritanceFlags: InheritanceFlags; //控制继承选项 IsInherited: bool; //本对象是继承过来的(还是显示设置的)? AccessMask: int; //该ACE代表的权限直。不管是访问规则还是审查规则的权限都会被转换成int保存在这个属性里。


IdentityReference属性存储ACE中的安全主体标识,
在Windows安全控制体系中,以用户标识SID存储,在.NET中你可以使用**SecurityIdentifier来代表SID**,
或者用**NTAccount类来以用户账户名称**来代表安全主体标识。
![201110091949515293](https://user-images.githubusercontent.com/12871721/30012612-3e5134e0-917c-11e7-8cdc-30bca1e26ea9.png)

- AccessRule:
DACL中的ACE(常提到的ACE多指这个)存储安全对象中的访问控制信息。既然是访问控制,缺不了3大主体:
1, 针对的安全主体(用户账户)
2, 所涉及到的权限
3, 规则类型(允许还是拒绝)
.NET中的AccessRule类型代表着DACL中的此类ACE,他继承于ACE基类(上面讲的AuthorizationRule)。

- AuditRule
.NET中的审查规则类.
SACL(系统ACL)也在安全描述项中保存,它的ACE不是进行访问控制的,而是针对安全主体与系统的的审查信息。如果审查规则被启用,指定安全对象被访问或拒绝后相关信息会被系统录入安全事件薄中。
AuditRule也继承于一AuthorizationRule类。

实际情况中,我们只会使用AccessRule和AuditRule的派生类。比如:FileSystemAccessRule和FileSystemAuditRule。

- SD(Security Descriptor:安全描述项)
存储ACE的地方。
ObjectSecurity类是SD的基类, 用来操作DACL和SACL。
//SD基类,用来操作DACL和SACL

abstract class ObjectSecurity //方法 bool ModifyAccessRule(AccessControlModification, AccessRule, out bool isModified); //修改DACL

bool **ModifyAudit**(AccessControlModification,
    AuditRule,
    out bool isModified);
//修改SACL

//返回值和isModified参数一样,都指是否被修改成功

//属性(属性名称:类型名称) AccessRuleType: Type; //访问控制规则类型,比如FileSystemAccessRule AuditRuleType: Type; //审查规则类型,比如FileSystemAuditRule AccessRightType: Type; //访问权限类型,比如FileSystemRights枚举



- CommonObjectSecurity和NativeObjectSecurity
CommonObjectSecurity继承ObjectSecurity,它没有添加任何实质内容。
NativeObjectSecurity继承CommonObjectSecurity,在CommonObjectSecurity的基础上,进一步加入了Windows本地SD的模型。比如ResourceType枚举,可以标识SD所付对象的类型。(比如常见的文件对象,注册表键值,Windows服务,打印机等等)

- 本地实体SD
同ACE一样,本地SD的ACL类型也是继承自抽象SD基类。并且几乎适合本地ACE实体一一对应的。有一个特例,ACE中文件系统的对象只有FileSystemAccessRule或AuditRule。但是SD的ACL类型虽然也有FileSystemSecurity,但是属抽象类,其派生类:DirectorySecurity和FileSecurity才是最终可以使用的对象。究其原因,除了名称分别指文件名和文件夹名外。ObjectSecurity的IsContainer属性在DirectorySecurity中是True的,而在FileSecurity中是False的。

- "安全标识符"(Security Identifier,SID)
_系统是通过SID对用户进行识别的,而不是很多用户认为的"用户名称"。SID可以应用于系统内的所有用户、组、服务或计算机,因为SID是一个具有惟一性、绝对不会重复产生的数值,所以,在删除了一个账户(如名为"A"的账户)后,再次创建这个"A"账户时,前一个A与后一个A账户的SID是不相同的。这种设计使得账户的权限得到了最基础的保护,盗用权限的情况也就彻底杜绝了。
查看用户、组、服务或计算机的SID值,可以使用 "Whoami"工具来执行,该工具包含在Windows XP安装光盘的"Support\Tools"目录中_

- 访问控制列表(ACL)
顾名思义,这是一个权限列表,用于定义特定用户对某个资源的访问权限。
在访问控制列表中,每一个用户或用户组都对应一组访问控制项(Access Control Entry,ACE),这一点只需在"组或用户名称"列表中选择不同的用户或组时,通过下方的权限列表设置项是不同的这一点就可以看出来。显然,所有用户或用户组的权限访问设置都将会在这里被存储下来,并允许随时被有权限进行修改的用户进行调整,如取消某个用户对某个资源的"写入"权限。

- 安全主体(Security Principal)
在Windows 中,可以将用户、用户组、计算机或服务都看成是一个安全主体,每个安全主体都拥有相对应的账户名称和SID。根据系统架构的不同,账户的管理方式也有所不同──本地账户被本地的SAM管理;域的账户则会被活动目录进行管理......
一般来说,权限的指派过程实际上就是为某个资源指定安全主体(即用户、用户组等)可以拥有怎样的操作过程。因为用户组包括多个用户,所以大多数情况下,为资源指派权限时建议使用用户组来完成,这样可以非常方便地完成统一管理。

针对权限的管理有四项基本原则,即:拒绝优于允许原则、权限最小化原则、累加原则和权限继承性原则。
rainit2006 commented 7 years ago

获得用户名称

var everyone = new SecurityIdentifier(WellKnownSidType.WorldSid, null);
            var acct = everyone.Translate(typeof(NTAccount)) as NTAccount;
            string user = acct.ToString();