linux enhanced security and trusted linux

John Wojtowicz (wojtowij@tcs-sec.com)
Thu, 20 May 1999 11:27:08 -0400


At 12:51 AM 5/20/99 -0400, you wrote:
>>> Putting everying in the inode would work, but it breaks compatibility.
>>
>> Well ext3 could store it in the inode, with the new kernels ignoring
>> privileges if you disable full-blown capabilities. That way distributions
>> could be built as "vanilla" linux or as "trusted" linux.
>
>This choice depends on what your goal is. Do you want to create insanely
>secure systems that only an NSA sysadmin could handle? Do you want to
>help protect newbie admins who only weakly understand permissions?
>

Being someone who works with Trusted OSes every day, I'd say
I'd like to see both. That way it might be possible in the future
to create a B1+ secure system based on linux, but linux can still
operate as a "vanilla unix" OS.

So I see now three security models.

1.) vanilla unix
2.) Linux improved security
3.) typical Trusted OS security.

I strongly agree with the usefullness of number 2.
But I see more usefullness in number 3 than you do.

>You must have some goal in mind. Here is mine:
>
>Create security enhancements that Red Hat can enable by default.
>This means NFS support is important. Newbie admins should not need to
>worry about anything, but expert admins should have some flexibility.
>It should be possible to admin the system without a root account.
>Even better, root daemons and normal setuid-root executables should not
>be needed. Normal software (Oracle, BRU, Stronghold) should run.
>
>It would also be very nice to meet C2 or B1, shutting up M$ and *BSD.

Well maybe it would be good to have the an underlying privilege mechanism
in place that would support all three models. Which is what I think
I'm advocating, by describing the privilege sets to such an extent as
I have.

>Linux drops the setuid bit when an executable is modified.
>
>> (NOTE: causing a program to run with too few privileges could
>> cause a denial of service.)
>
>This is why I keep suggesting an extra set of capability bits that
>specifies what the minimum requirement is. Execution should just fail.
>(maybe log the attempt too)

I'm all for two privilege sets on the file, no matter where it goes,
this would also make it easier to implement option number 3 above.
Call them forced and allowed, use forced like your current set
in the ELF header, then use "allowed" as the ones you're allowed to
drop. This way we can still implement option number 3 (as a B1+ option)
easier already having support forced, and allowed file capability sets in the
kernel (even if they are used slightly differently).

John

--
John Wojtowicz, Secure Systems Engr.  ph:    (703) 318-7134
Trusted Computer Solutions, Inc.      fax:   (703) 318-5041
13873 Park Center Rd. Suite 225       email: jwojtowicz@tcs-sec.com
Herndon, VA  20171                    http://www.tcs-sec.com/

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/