Questions about TrustedBSD

[Robert Watson]

On Thu, 23 Jun 2005, Kövesdán Gábor wrote:

> I'm very interested in the TrustedBSD project, but I haven't known so 
> much about this project so far. I've read the homepage, but I still have 
> a few questions. I would be glad if somebody in this list would answer 
> my questions.
>
> 1, I see ACLs, MAC and extended attributes have been merged to FreeBSD 
> 5.x. Are these projects complete or there will be further features?

Extended attributes are now part of the native FreeBSD UFS2 file system, 
which is used by default since about 5.1-RELEASE.  ACL support is compiled 
into the kernel, but must be enabled on file systems using tunefs(8) or 
when creating the file system, and relies on the extended attribute 
support.  Enabling ACL support in the kernel has been the default also 
since 5.0 or 5.1, I believe.  Both are considered production quality 
features, although there are some edge case situations where applications 
may not properly preserve ACLs when files are copied, for example.

MAC support is considered experimental, although the MAC Framework on 
which our MAC policy modules are based is considered increasingly mature. 
In the upcoming 6.0 release, it will be much closer to feature complete, 
providing MAC policy support for protecting additional IPC types, such as 
System V IPC.  Some of the policy modules are quite mature; others require 
more documentation or more experimentation in production before we can 
call them production quality.  Some are imply demonstration modules.

> 2, I've read about the Capabilities extension. Is it something similar 
> to RBAC? It sounds similar for me. Can we fine-tune the privileges of 
> one user or what it actually means?

In the context of TrustedBSD, "Capabilities" typically refers to the 
POSIX.1e decomposition of root privilege, and in particular, a model by 
which root privileges are decomposed into a mask of rights that can be 
assigned to processes, and picked up due to executing specific binaries 
similar to setuid.  There are some similarities to concepts in role-based 
access control, but I think there may be more differences.  Specifically, 
POSIX.1e privileges are really oriented on decomposition of the user in 
order to allow privileges to be assigned to users or roles, whereas more 
general Role-Based Access Control is targetted at implementing general 
procedural or data protection for users and applications beyond basic 
system rights.

The POSIX.1e capability work is considered somewhat sidelined right now, 
as I'm not comfortable that it actually provides an immediate security 
benefit, due to the risk level in changing the privilege model.  Some of 
the changes to support this, such as breaking out root privileges into a 
mask of more specific privileges for the purposes of an access control 
decision, are in our SEBSD development branch, so that assignment of these 
privileges can be constrained using Type Enforcement.  I don't currently 
have a specific timeline for merging these privilege check changes.

> 3, As for SEBSD, it is just a hardened kernel, or does it require 
> modifications on the userspace? Has it been already merged to 
> FreeBSD-CURRENT, or will have been it merged by the time 6.0-RELEASE 
> comes out? I don't know so much about the SELinux or SEBSD, but I would 
> like to learn. Do You know any comprehensive documentation about this 
> topic on the Net?

SEBSD requires both kernel and user space changes, as it introduces 
mandatory labeling and protection at all levels in the system. 
Specifically, programs associated with the login process, and other user 
management and switching related activities (cron, sendmail, etc) need to 
be label-aware.  SEBSD really consists of five things right now:

- Modifications to the TrustedBSD MAC Framework required to add support
   for additional access control checks and labels required by SEBSD, but
   not required by previously developed security modules.  For example,
   SEBSD labels file descriptors as well as files, and the above-mentioned
   privilege changes.

- An SEBSD module, which encapsulates a port of NSA's FLASK architecture,
   security server, and Type Enforcement policy, and is loaded as a kernel
   module.

- The ported SELinux support libraries and tools, such as libsepol,
   libselinux, etc, as well as the policy compiler.

- A set of modifications to a number of base FreeBSD tools and libraries,
   such as login-related parts, cron, sshd, password tools, and so on, to
   be aware of Type Enforcement.

- A sample TE policy for constraining applications and components, based
   on the sample policy NSA provides for SELinux.

Of the above, some parts but not all have been merged to the base FreeBSD 
tree for 6.0.  In particular, we haven't yet merged the file descriptor 
labeling support, some changes to the file system mount code, and some 
changes relating to tty labeling for pseudo-terminals.  Several of these 
changes are scheduled for merge to the base FreeBSD tree in time for 6.0, 
but likely not quite all.

We currently distributed SEBSD as an extended FreeBSD release, which can 
be downloaded via CVSUP, or a sample ISO.  Our current ISO snapshot is 
quite old, and a new one will be going online in the next couple of days 
for download, and updates to quite a recent 6.0 snapshot.

You can find information on NSA's FLASK/TE work on the NSA web page; 
interestingly, FLASK/TE were originally devloped on a BSD/Mach-derived 
micro-kernel system, so this is in some ways "the return to BSD" via 
Linux.  :-)

> 4, How is SEDarwin in connection with the TrustedBSD project? Or it just 
> some kind of extra project from TrustedBSD developers who also like 
> Darwin?

SEDarwin is an experimental port of the TrustedBSD MAC Framework and SEBSD 
policy module from FreeBSD to Darwin, which is made easier (although not 
easy) byt the similarities between FreeBSD and Darwin.  It's being done by 
several of the same people who work on the MAC Framework on FreeBSD, as 
well as SEBSD.

> 5, The documentation is pretty rough on the homepage. How can I learn 
> more about the TrustedBSD project?

This is an accurate observation.  Some of the papers there are still quite 
relevant, and there is a fair amount of documentation floating around. 
However, there's relatively little user-oriented documentation.  I have 
high hopes that, among other things, we'll shortly have a Google 
summer-of-code intern who will be interested in helping out with this.

Help from you and others in working to improve the documentation would be 
much appreciated.

Thanks!

Robert N M Watson

>
> Thanks in advance for the answers,
> Cheers,
>
> Gábor Kövesdán
> To Unsubscribe: send mail to majordomo at trustedbsd.org
> with "unsubscribe trustedbsd-discuss" in the body of the message
>