No subject

Ilmar S. Habibulin ilmar at ints.ru
Sat Sep 8 07:08:34 GMT 2001


On Fri, 7 Sep 2001, Robert Watson wrote:

> On Thu, 6 Sep 2001, Ilmar S. Habibulin wrote:
>
> There are a number of programs in the system with the problem you describe
> -- for example, I know that both the SSH client and server make tests
> based on uid to determine how they should behave, rather than trying the
> operation and testing for failure.  My expectation is that:
Heh, i think that integrating capabilities problems are nothing compairing
to MAC integration. I'm trying to make packet labeling prototype work,
hope to finish it in a week or two. 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.

> The degree to which this happens will depend on how successful we are in
> the userland integration--in particular, how well we can modify
> applications to behave correctly both as setuid and with capabilities.
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.

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.


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



More information about the trustedbsd-discuss mailing list