Projects / Linux trustees

Linux trustees

The main goal of the Linux Trustees project is to create an advanced permission management system for Linux. The solution proposed is mainly inspired by the approach taken by Novell Netware and the Java security API. Special objects (called trustees) can be bound to every file or directory. The trustee object can be used to ensure that access to a file, directory, or directory with subdirectories is granted (or denied) to a certain user or group (or all except user or group). Trustees are like POSIX ACLs, but trustee objects can affect entire subdirectory trees, while ACLs a single file. Trustees works with the 2.6 Linux kernel.

Tags
Licenses

Recent releases

  •  23 Jul 2005 06:44

    Release Notes: A buffer size calculation error that could cause memory corruption was fixed. Several makefile enhancements were made to allow compilation on kernels newer than 2.6.12.

    •  15 Apr 2005 10:37

      Release Notes: This version fixes a problem where permissions were sometimes not being applied correctly to the root partition (especially with respect to files that did not exist already).

      •  09 Apr 2005 07:55

        Release Notes: A overflow condition that caused memory corruption leading to an OOPS or hard-lock has been fixed. There were other miscellaneous bugfixes and documentation updates.

        •  17 Feb 2005 21:52

          Release Notes: This release compiles as an external module for the 2.6 kernel. It uses the Linux Security Module (API) to allow even an unpatched kernel to use trustees. There have been several security and general bugfixes.

          •  16 Dec 2002 18:19

            Release Notes: Support for kernel 2.4.20 and 2.5.50.

            Recent comments

            19 Apr 2002 12:53 ggoudsmit

            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

            OpenStack4j

            A Fluent OpenStack client API for Java.

            Screenshot

            Project Spotlight

            TurnKey TWiki Appliance

            A TWiki appliance that is easy to use and lightweight.