The Linux Trustees Project is an effort to create improved access control and advanced file permission management similar to other operating systems.
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 file
This 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
http://acl.bestbits.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
And time to implement all of these.
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
And time to implement all of these.
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:REBX
LinuxSecurity.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:DW
LinuxSecurity.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:REBX
In 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
Just to clarify, ACLs and Trustees are 2 different paths. The main difference
that ACL, according to POSIX, affects a single file, but trustees affect a whole
directory tree.
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 http://www.braysystems.com/linux
/trustees.html and Slava can be reached at
zavadsky@braysystems.com
Only registered users can write comments.
Please login or register. Powered by AkoComment! |
