RSS Comments for Linux trustees

19 Apr 2002 12:53 ggoudsmit Thumbs up

Trustees rocks! Huge maturity leap for Linux IMHO
We use our huge fileserver to serve Apples, Windows and Linux machines, and needed a centralized security system, that allows different groups to have different rights on the same shares.

I used to work with AIX and it's Extended attributes that contained Posix ACL's. Two kernel patch projects exist that support ACL's using extended attributes for Linux, but the data is stored within special blocks on the the system, i.e. modifying the contents of the actual filesystem.

Special tools are thus required to save all permissions to a special file, to be restored by another special tool.

Trustees defines all permissions in a special file which is read into the kernel at boot time, or whenever root feels like it. This file is just a normal file, so no special action is required to save your permissions.

The only drawback is that this type of ACL's can only be maintained by the system administrator; an individual user cannot maintain the ACL's of his own files. You'll need the POSIX compliant ACL tools for this... These work exactly like AIX's ACL's, and similar to NT's.

But for my purposes, Trustees was EXACTLY wat I needed... Great job by Vyacheslav...

Now if we could just get it into the main kernel development tree and make this baby mainstream!

22 Jun 2000 09:03 zavadsky

The first anniversary of Linux Trustees, or trustees vs ACLs
Working on the next release of Linux trustees, I found that the project
is more that a year old.

This engaged me to write several comments.

The project in brief
The idea of trustees came to me when I installed Samba server and found
that in order to use it in serious enterprise environment I really need
to invent a mechanism for controlling permissions to directories and directories
tree. As most systems administrators, I have a good experience with Novell
Netware and I still believe that the approach used in Netware to control
access is the best invented. By a single click you can grant a group access
to directory and all it's subdirectories. The linux does not allow such
a convenience, in fact I still do not know how to give one group R/O access
and another group R/W access for a single directory.

I played a lot with different security management tools, as well as
with samba configuration file and I found that the only way is to write
my own kernel level software.

In short, trustee is a single object that bound to directory (or file)
and affects all the files and subdirectories in it.

 

Usage of trustees
During last year, I received  a lot of excellent testimonials from
people who use trustees and several critics from people who do not. The
critics is as follows:

Trustees are completely not standard. I'd rather should implement POSIX
ACLs. - Well. They are not standard. But are very convenient. Implementing
of POSIX ACLs requires serious changes in virtually all filesystem related
software (like tar), it also requires a reasonable amount of "default ACLs'.
The only successfully working implementation of POSIX ACLs that I know
is NT. But it is huge, slow and still inconvenient.

Because of trustees objects reside in kernel memory, trustees can be
used only on very small systems for very limited purposes. This is
not true. The difference between ACL and trustee is that ACL affects a
single file, but trustee all subdirectories and their context. This means
that a couple of trustees objects implements given security policy, and
I can not imagine system that will have more than a thousand security polices.
Example: The following line in trustee.conf file (trustees 2.0 syntax)
[/dev/sda3]/data/marketing:+marketing:RWEBX:+sales:REBX:+staff:!DRWEBX
use
about 60 bytes of kernel memory and implements a policy for complete directory
/data/marketing  (and all subdirectories) that may be as huge
as several gigabytes and the policy we are talking about is pretty complex
but still pretty common. First of all, all kind of access is denied for
people outside staff  group. Read/only access is granted to
members of sales and Read/Write to members of marketing.
Implementation of such a policy in terms of ACLs will require a couple
of ACLs assigned to each file affected as well as default ACLs set to affect
new files (implemented in NT, but I have no knowledge of such an implementation
in Unixes). This finally will lead to thousands of ACL objects in file
system and a great memory consumption for caching purposes, as well as
potential security risk because nobody can chek this thousands of ACLs,

Trustees are not consistent. You can remount directory in new mountpoint
and have all trustees permissions in no effect. You = root. But I partially
agree with this comment. It is true for trustees 1.0 -1.6, where syntax
of line in the example above was something like /mnt/disk3/data/marketing:+marketing:RWEBX:+sales:REBX:+staff:!DRWEBX.
The
situation is to be changed with trustees 2.0 that are tested now and should
be released in couple of days.

Trustees 2.0
The trustees are not changed much since trustees 1.0. But with the release
of linux 2.4.0 I found that the architecture of VFS changed significantly
and I have to change trustees. Few words how the trustees works inside
the kernel. There is kernel function permission that basically check
permissions for given file. I replaced all the calls of this function inside
kernel to call of my own function that substitutes  (or combines)
unix permissions by trustees ones. But the problem is that in order to
calculate trustees permission I  have to sort out all the parents
of file. In previous Linuxes it was relatively simple, but Linux 2.4.0
introduces opportunity to mount a given device in several mountpoints.
Thus, any dentry can have several absolute path names. So, I should either
to block this new function in trustee path (and changed a lot kernel structures)
or to limit trustee to a given device. It means that trustee object can
not influence across file systems border. Disadvantage: you can not put
something like /mnt:*:REBX, you should put

[/dev/cdrom]/:*:REBX

[/dev/fd0]/:*:REBX

etc. instead.

Advantages: you can control a directory itself, despite of the point
you have mounted new filesystems.

New syntax:
You can control access either to block devices or to network filesystems

Block device:

[block_device_file_name]path_inside_block_device:user_or+group:trustee_mask.....

Please note that in this case trustee actually use only major and minor
number of block device, so you can create an alias or symlink to device
if you wish.

Network file system

{network path}path_inside_block_device:user_or+group:trustee_mask.....

Network path is generally the same as you use in corresponding mount
command, say //server_name/share_name  for samba mounts. Look
at /proc/mounts for exact network names, I am looking at the same
structures in kernel when finding network device name as proc filesystem.

Fisrt slash is mandatory in both cases.

Screenshot

Project Spotlight

icc2to4

A utility that converts an ICC profile from v2 to v4.

Screenshot

Project Spotlight

PHP-Calendar

A Web-based calendar written in PHP/SQL.