Friday Mar 25, 2011

Blog Migration

Sun blogs will be migrated to by the end of April

Tuesday Oct 20, 2009

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

Thursday Aug 06, 2009

How to enable guest access to a Solaris CIFS share

A new share property, guestok, has been added (snv_118) to control whether or not guest access is allowed on a share.
If guestok is set to true, guest access will be allowed on the specified share. If the guestok share property is not defined or
is set to false, guest access will not be permitted on that share. By default, the guestok property is not defined, i.e. guest
access is disabled by default.

Examples to set guestok using sharemgr(1M) and zfs(1M):

# sharemgr set -P smb -p guestok=true -r myshare mygroup
# zfs set sharesmb=name=myshare,guestok=true mydataset

When a user attempts to connect to an SMB server, the request is interpreted as a guest connection if an account name is
not specified or the specified user account does not exist. Guest connections are not authenticated except when the guest
account has a password (more details below). Windows systems typically use a predefined local account called Guest to
represent guest connections, although this account can be renamed. On Solaris, the system administrator can define an
idmap name-based rule to map Guest to any local Solaris username, such as guest or nobody. For example:

# idmap add winname:Guest unixuser:guest

If the local account has a SMB password in /var/smb/smbpasswd the guest connection will be authenticated against
that password. Any connection over SMB made using an account that maps to the local guest account will be designated as
a guest connection. In the absence of an idmap rule for Guest, an ephemeral ID will be generated for this Windows account
by idmap service.

Saturday Jun 28, 2008

Solaris CIFS Server and ZFS

There is a common misconception that Solaris CIFS server has been designed specifically to work with ZFS but it is actually file system agnostic. The CIFS server is a consumer of the Virtual File System (VFS), which provides a common interface to all file systems. The VFS provides a common abstraction layer that allows consumers to treat all file systems as generic resources, so the CIFS server provides interoperability with any file system that can be shared.

On the other hand, in order for a UNIX hosted CIFS server to provide seamless interoperability with Windows systems or CIFS clients in general, it needs support for features that are not typically provided by file systems on UNIX. Some important examples of such features are: Windows style Access Control Lists (ACLs), the ability to store Security Identifiers (SIDs) rather than UIDs and GIDs, case-insensitive name operations and support for DOS attributes.

From the outset of the CIFS server project, we had an advantage in that ZFS offered some attractive features, such as support for Windows style ACLs (ZFS supported NFSv4 ACLs, which are very similar to Windows ACLs) and the potential to add support for new features required for seamless CIFS integration. After enhancing ZFS and the VFS to realize the goal of having CIFS as a first class file sharing protocol, along with NFS, on the Solaris OS, ZFS is now the only file system that supports the full set of Windows interoperability enhancements when it's shared over CIFS. This rich feature set has led to the misconception that the CIFS service only works with ZFS.

Although ZFS is the ideal file system to be exported via CIFS, it is important to remember that all of the features that are necessary for CIFS are provided via the VFS, which means whenever any of these features are provided by another file system they can be consumed by the CIFS server. For example, NTFS streams are implemented on Solaris extended attributes. Since both UFS and ZFS support extended attributes, both UFS and ZFS provide support for NTFS streams over CIFS.

I'll talk about ZFS features and enhancement from CIFS point of view in future blog posts.

Monday Nov 12, 2007

CIFS for Solaris: A new protocol, a new world

CIFS/SMB is not a new protocol, it's not new in Solaris either but ...

If you want to visit another world and trade with its inhabitants, having good products to trade most likely wouldn't be enough because they wouldn't understand what you are trying to achieve. Both the inability to communicate and huge cultural differences would be an enormous barrier. In order to initiate the relationship you need to know how to communicate and speak their language, which may be accomplished through a translator or by learning the language yourself. Learning the language yourself is a lot harder but, ultimately, it's a lot more efficient.

Solaris has a lot of great features to offer but it couldn't interoperate directly with the Windows world because it didn't know how to speak CIFS, one of the official communication languages of the Windows world. There have been a few translators over the years, including Samba, which is a really good CIFS communicator, but it was time for Solaris to learn how to speak CIFS. Learning a foreign language can be hard but learning to communicate with another world can be very, very hard, and for Solaris, some intrusive brain surgery was required to attach a CIFS speech center.

When trying to communicate with other people one of the first things you need to know is how to identify and call those people. User identity in the Solaris world is quite different from those of the Windows world. In the UNIX world people from different cities can have similar identities and, even though they are different individuals, they can be mistaken for one another. In the Windows world no two people can have the same identity, no matter where they live. This identity problem was solved by PSARC 2007/064, which allows various parts of the operating system to deal with Windows style identities.  For example, ZFS now understands Windows style identities (SIDs), in addition to other enhancements including Windows style ACLs, DOS attributes, and mixed and case-insensitive operations.

One of the design goals was to limit the ripple effects of such changes and it was important that applications and services that don't need to know about Windows identities remained unaffected. This is supported by the identity mapping service, which was discussed recently here. Some of the more intrusive changes were to the VFS to add feature registration, new parameters and new features, such as PSARC 2007/218 and PSARC 2007/227.  This was intrusive because, although it didn't materially affect the operating system architecture, the ripple effects touched every file system.

So now Solaris can speak CIFS almost fluently, without the help of a translator. Perhaps not completely without an accent, and people from the Windows world might recognize that we are a foreigner, but that's a work in progress and we're getting better by the day.


Afshin Salek


  • Sun
« July 2016