Access Control in Solaris CIFS Server (Basics)


Access control, generally speaking, is a set of mechanisms for limiting access to certain items by a principal. The following entities are essential to the access control model/process:


Secured object: the object/item that needs protection
Security principal: the entity that is trying to get access to a secured object. To enforce the access control, this principal needs to be identifiable i.e. has an identity. In some cases, principal's identity needs to be verified and a security context needs to be established.
Security information: a set of data that defines what kind of access is allowed/denied to a secured object.
Security agent: the entity that enforces the access control. Enforcing is essentially an algorithm which determines whether or not a security principal is allowed the requested access to a secured object based on corresponding security information.
Access control, in the context of this blog, is about mechanisms for limiting access of users and/or hosts to exported file systems over CIFS in Solaris, where three levels of control is offered:

1. Share Host-based Access Control
2. Share Access Control List (ACL)
3. File System Security


The access control is applied in the order presented above where security information for that level is set. These three levels act as successive access filters, which means a user has to pass all three in order to obtain access to a file or directory. Level 1 and 2 filters are wide open by default, which means a user only has to pass the file system filter.


1. Share Host-based Access Control

Host-based access control is controlling access of a host or group of hosts to a file system export/share over SMB/CIFS. Since this is a share level access control it means it is only applicable to network and not local accesses.

Access control information is set as share properties using sharemgr(1M) or sharesmb property of ZFS datasets using ZFS(1M). Three hosts lists can be specified as rw, ro, and none. Depends on the list, a host will get read-write, read-only or no access, respectively. By default, none of these properties are defined so all hosts get full access to a share. CIFS server enforces host-based access control each time a client requests to make a connection to a share.

Secured object: share
Security principal: host
Security information: lists of hosts with read-write, read-only, and no access
Security agent: CIFS server

2. Share Access Control List (ACL)

Share ACL provides the same level of access control as Windows does for its shares. Basically, each share can have an access control list with entries that specify accesses allowed/denied to users and/or groups. Similar to host-based access control, this is only applicable to network accesses and only over SMB/CIFS.

This feature is only supported for ZFS shares. Shares' ACL can be managed using ls(1) and chmod(1) on Solaris or using Windows share management GUI from a Windows client. The recommendation is to use Windows GUI.

Although ZFS is used to store shares' ACL, the access control is enforced by CIFS server each time a client requests to make a connection to a share. Currently, the default setting allows full access to everyone. Since autohome shares are created at run time based on autohome rules, no ACL can be set for them at the moment.

Secured object: share
Security principal: user
Security information: Access Control List
Security agent: CIFS server

3. File System Security

Although CIFS clients get access to exported file systems through CIFS server but CIFS server plays no role in enforcing file level access control. This level of access control is enforced by each exported file system according to its native security mechanisms. For example, UFS uses POSIX ACL, while ZFS uses its own version of ACL which is based on NFSv4 ACL and provides similar semantics to Windows ACL.

Since this level of access control is enforced by file systems, network and local accesses will be treated the same.

On Solaris, file system access control information can be seen using ls(1) and can be modified using chmod(1) regardless of the type of file system. Windows ACL editor GUI can be used to view and edit file system security information although it is only recommended to be used with ZFS since Windows representation might not be quite adequate for other security types.

Secured object: file system objects. Mainly files/directories.
Security principal: user
Security information: depends on the type of access control offered by the exported file system. Examples are ZFS ACL, POSIX ACL, and Unix permission bits.
Security agent: exported file system

Comments:

Although CIFS clients get access to exported file systems through CIFS server but CIFS server plays no role in enforcing file level access control

Posted by Ordis on January 08, 2011 at 02:32 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Afshin Salek

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Feeds