Advanced Access Control with the Trustees Project
6 - 12 min read
Jul 19, 2000
Recently I had an opportunity to speak with Slava Zavadsky and ask him a few questions about his work on the Linux Trustees Project, an effort to create improved access control and advanced file permission management similar to other operating systems.
LinuxSecurity.com: Can you offer a brief description of your background? How long have you been working on security? Have you always been involved in programming? Where are you from?
Slava Zavadsky: I came from Belarus, a small ex-USSR state. My background is a combination of different fields, and I've always shared ideas between fields. Until recently, I was actively involved in mathematical research. My primary interest was applications of wavelets to image processing and compression, and I believe that I spent about 30% of my time for mathematics.
Another my field of interest is IT (I mean deployment and maintenance of networks, software, and hardware in organizations). When I left Belarus, I was employed for MZOR - a large production (about 1000 workers) and engineering (about 300 engineers) corporation. My occupation was like CIO, but involves also a lot of technical, not administrative tasks. Another 30% of my time was spent developing the Trustees project, which came as a feature that we need to deploy a couple of working Linux servers at MZOR.
And, surely, software architecture and development, which give us a lot of fun and experience that is very mandatory in IT.
I was involved in programming since high school, and make my first payed project in the college (it was a cross assembling enviroment for developing embedded systems on PC).
I can not say how much time I was involved in security. Security does not exists itself. It is a part of network and software engineering, and one should always evaluate the project from the security viewpoint since the very early stages, and make sure that security assumptions still have the project usefull for users. It is simple a bunch of experience. I can not imagine a security specialist that can not deploy a network or write a CGI application.
LinuxSecurity.com: Can you describe the Linux Trustees Project? What is the goal/objective of the project?
Slava Zavadsky: Linux Trustees project borrows "trustee" idea from Novel's Netware OS. A trustee is object that give a given group or user access to a complete directory tree, not just a single file. In my own experience, the typical task that a file system administrator has is "to have a directory that some users R/W access, some R/O, others -nothing".
It can be done via a single click of mouse using Netware Administrator, but it is still complex in all other OSs.
In my understanding and experience, the standard Unix and Linux file permission model simple does not allow to have 2 different groups have different (say, R/O & R/W) access for a single file. In UNIX you just have owner, owner's group, and "others" permission, that give you no flexibility to manage access on per group basis. This problem is in certain degree resolved by different implementations of POSIX ACLs. ACL is basically a list of "access control records" each of them allows access to given file to a given user or group. The problem is that ACLs are affective on per file basis (in NT there are default ACLs that copied to new files that created in directory), that makes administration quite a complex. Moreover, millions of ACL required to implement a single security policy is a potential security risk, because it is not easy to verify them even if the tools are provided.
So, the goal of trustee's project is to have in Linux a convenient file permission management system that borrow the best from commercial (or even military) grade OS.
LinuxSecurity.com: Can you give a few examples of Access Control Lists here? What would it consist of? Can you describe the concept of ACLs?
Slava Zavadsky: ACL is a list of objects. Each of them grant permission for file to given user or group. There are default ACLs, that exist in directory and used as templete for new files. One can manage ACL either using a GUI in Windows NT, or using a command like:
setfacl -m u:lisa:+w fileThis adds write access to the permissions of a user ACL that is not a part of standard Linux kernel. The patch for them can be found at .
LinuxSecurity.com: How was it started?
Slava Zavadsky: I was employed in large company as a lead IT engineer, and my main duty was to have working about dozen of different servers. I finally found that it is simple impossible to have the same level of convenience that I used on Netware with Samba. I borrowed some ideas from ACLs, Novell, and Java Security workflow, and decided to implement model on a kernel level keeping all the stuff as much transparent as I can for applications.
It took about 2 weeks of my spare time to have first production Samba server working.
LinuxSecurity.com: What typical uses are there for this software?
Slava Zavadsky: Systems administrators that use Linux as file keeping facility (e.g., using Samba)
LinuxSecurity.com: It would be great to know more here. How does having more control over ownership of files map to improvements the windows client user would see?
Slava Zavadsky: The main (and probably only improvement) is access to directory despite of owner and permission mask of files. So, if administrator decided that somebody should (or should not) have access to file, he will see it despite of permission mask or ownership that set by unskiled user. Samba itself allows some control of access and permission mask of new files, but it is very limited and only on per share basis (it means for users that they should map a different disk for each directory with different permission.
LinuxSecurity.com: What are the most difficult challenges you faced while developing it?
Slava Zavadsky: First of all, kernel's internals. They are complex, moreover, they are constantly changed, so, it is require some time to keep the project up to date.
Another problem is misunderstandings with adepts of pure Unix. Most administrators that use trustees are very happy with the software, and I receive at least one "thank you" e-mail per day, but my attempts to have it integrated to kernel or just reserve syscall numbers was answered "That is not standard. We would rather have you implement POSIX ACLs".
LinuxSecurity.com: Why not just implem ent POSIX ACLs, then? How does it differ? How is your method better?
Slava Zavadsky: There are some technical differences, e.g. trustees allow you to deny a privilege, and no access is granted if such a denial is exists (borrowed from Java Security Framework). But the main difference is that trustee is a single object that implements a security policy for a very large set of files (a complete subdirectory tree), so just a couple of trustees is required where thousands of ACL is needed. Just to make everything clear - this permission can be cleared, modified or denied by another trustee object that lives deeper in directory tree.
Another difference is that ACLs (the implementation done by my friend Andreas Grunbacher) are depends on ext2 filesystem, while trustees is just a single file that loaded into kernel memory. The first approach is more nice and natuaral, but it requires different tar, different gzip etc. My approach is more transparent for everything, and actual size of conf file is less than 1k even for large systems.
LinuxSecurity.com: What new features are you working on?
Slava Zavadsky: I just finished a 2.x version of trustees that limit power of trustee to a filesystem (the tustee has no effect across mountpoint). There are some disadvantages here, but it will allow a more consistent and secure view, and it is in accordance with changes of VFS made in 2.4.x kernels.
I am thinking of:
- GUI for administration
- Storage of trustees in ext2/ext3
- Integration with capabilities
features are you working on?
Slava Zavadsky: I just finished a 2.x version of trustees that limit power of trustee to a filesystem (the tustee has no effect across mountpoint). There are some disadvantages here, but it will allow a more consistent and secure view, and it is in accordance with changes of VFS made in 2.4.x kernels.
I am thinking of:
- GUI for administration
- Storage of trustees in ext2/ext3
- Integration with capabilities
LinuxSecurity.com: That's for sure! Can you describe capabilities? How do they work together? I thought capabilities were already a form of ACLs?
Slava Zavadsky: In my understanding, capabilities is a method to grant/deny given "superuser" feauture for given process. E.g. ping is a set UID program, but it is actually required just an access to raw sockets. I believe that integration of filesystem ACL with capabilities can pay off.
LinuxSecurity.com: What do you think are the biggest secuirity concerns with using Linux today?
Slava Zavadsky: The qualifications of the average administrator. As with all powerful systems, Linux has a lot of potential and real holes. I suggest that the Linux community should finally establish several standard (may be automatically upgradeble) server distributions.
Current distributions are too hard and too complex to manage, and require about 2 days of a very skilled work to install working and secure Internet server.
It is better than NT, anyway.
LinuxSecurity.com: Security is always about tradeoffs. What tradeoffs do you face while developing the trustees project?
Slava Zavadsky: Nothing. Really.
LinuxSecurity.com: The administration and tuning overhead, no? Process of maintaining permissions with chmod and the trustees files?
Slava Zavadsky: The main overhead was creation for software, especially R&D phase. After I have it worked, it just save me from chmods.
LinuxSecurity.com: What would you like to let the Linux security community know about your project?
Slava Zavadsky: If you have some multiuser access on your server, try trustees. They may save you a lot of working hours. Let me give an example of configuration file:
# Grant to the group R/W access for directory [/dev/hda2]/httpd/htdocs:+web_editors:RWEBX # Grant the httpd daemon right to read files [/dev/hda2]/httpd/htdocs:httpd:REBXLinuxSecurity.com: How would you add to this to give the administrator the ability to read/modify those files as well? Would you have to include the process the administrator is running? How do you protect this file itself from an intruder modifying directly?
Slava Zavadsky: If administrator is root, the access is granted automatically. If he prefers to work under ordinary UID, just add him to web_editors.
The trustee affects all the processes that runs on the system. httpd in the example above means UID, not process name. The only headache is with "too wise" daemons, like run under root UID and calculates permission theirself (.e.g mars-nwe). IIn the example above, we can deny write access to everybody except web_editors (and root) by:
[/dev/hda2]/httpd/htdocs:+web_editors:DWLinuxSecurity.com: Can I ask you to give perhaps a short 'howto' on how to get started, or a definition of the terms that are used? And the options in the configuration file to show it's real abilities?
Slava Zavadsky: About once per week I recieve e-mail message like that "Thank you very much for your wonderful project. It allows me to transparently migrate my network from [name of commercial NOS] to Linux. I'd suggest the following feature [...............]. Another problem is lack of HOWTO. Can I write it." My answer is always "sure". No HOWTO. May somebody, sometimes will write it. May be even myself. Right now I just give another example of conf file. It is my first production one, I used it to avoid su to watch the system and to control a single samba share:
[/dev/hda1]/var/log:zavadsky:REB [/dev/hda1]/usr/local/apache/var:zavadsky:REB [/dev/hda1]/usr/exim:zavadsky:EB [/dev/hda1]/usr/exim/spool/log:zavadsky:REB [/dev/hda1]/usr/local/squid:zavadsky:REB [/dev/hda1]/usr/src:zavadsky:RWEBX #R/W for tg and R/O for [/dev/hda1]/var/stuff:zavadsky:RWEBX [/dev/hda1]/var/stuff/calor:calor:RWEBX [/dev/hda1]/usr/local/apache/share:httpd:REBXIn the example above I grant myself right to read all the files in /var/log. It means that if I wish to check the status of the system (say, tail /var/log/messages), I can do it under my user ID, without suid. Each line of the configuation file contains access controls for a single directory (rarely a file). After device name and name of directory, it contains a semicolon separated list like user_or_group:access spec.
Access specs basically use:
- R - read files
- E - rEad directories
- X -execute files
- B- cd to directories
- W - write
LinuxSecurity.com: I'd like to thank Slava for conducting this interview with us today. The Trustees project is certainly very interesting, and looks to have great potential! We wish you success with your project!
The home for the Linux Trustees Project is at
/trustees.html and Slava can be reached at
