your mail

[Robert Watson]

On Sat, 8 Sep 2001, Ilmar S. Habibulin wrote:

> On Fri, 7 Sep 2001, Robert Watson wrote:
> 
> Heh, i think that integrating capabilities problems are nothing
> compairing to MAC integration.

Yes, I agree entirely--as you point out, there are a lot of "magic" UNIX
primitives that don't lend themselves to mandatory access control.

> I'm trying to make packet labeling prototype work, hope to finish it in
> a week or two.

Sounds great -- I have not had the opportunity to make much progress in
this space, other than to keep merging the MAC code forwards to new
versions of -CURRENT.  I need to test it again in a post-KSE world and
make sure it still works properly.

> So, there are pty pardigm, used by many remote shell programms, such as
> telnet/telnetd, xterm, etc. FreeBSD has library functions openpty() and
> forkpty(). They find next free pty device and set apropriate rights on
> them, using chmod() and chown(). If MAC would be enabled(included) we
> have to call mac_set_file() function from *pty(). But the problem is,
> that not only xterm from Xfree336, but even telnetd (both in 2.2.5,8 and
> -current!) do not use this call. So i have to find chmod/chown calls and
> make mac changes in each program. 

It is probably worth fixing at least telnetd to use openpty() -- I didn't
realize that they don't use it.  One of the real benefits to that
abstraction is that it hides system-dependant security details from the
application, which is precisely what we need.

> Successful userland integration depends on wide testing of
> capability-enabled programs. When i've patched system, recompiled,
> installed it, i began to setup capabilities on files. And foggot to set
> CAP_SYS_BOOT on /sbin/reboot&shutdown. Ctrl+Alt+Del helped, but
> situation was funny. suser uid 0 test was turned off. 

The system shutdown procedures rely on a number of assumptions about
signals and the correct operation of the process initiating the
shutdown--I've run into some similar nasty problems, including panics if
init isn't able to kill all other processes, due to the assumption that
init never dies.

> And another one bad thing is that extended attributes are not enabled by
> default. So to use any on advanced security features user have to enable
> extattrs, desired feature and setup it. Are there any plans of better
> extattr support and integration? Just wondering, cause current
> implementation satisfys me.

Yes.  The DARPA funding to NAI Labs covers an enhanced extattr
implementation built into FFS, instead of layered into UFS.  We're
currently waiting on DARPA for some paperwork to get our sub-contractors
running, but their task will be to work on a highly integrated
high-performance version, with proper support also for soft updates.  The
result of this work will be that extended attributes are always "on", and
much faster than before, as well as having improved consistency properties
in the event of a failure.  Once DARPA gets the sub-contractors online,
we'll have a sense of the precise timeline for implementation.  This
should make ACLs, Capabilities, and MAC all run much better, and be easier
to install and manage.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert at fledge.watson.org      NAI Labs, Safeport Network Services


To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message