Downgrading labels

fergus fergus at cobbled.net
Mon Apr 4 07:11:53 GMT 2005


On 29.03-06:49, Ilmar S. Habibulin wrote:
[ ... ]
> Not, i'm not confused between biba and mls models. I'm confused with
> label
> downgrading capability, that might be used in the following scenario:
> 
> 1. user has right to downgrade label
> 2. user has right to develop custom software
> 
> So user can develop software, which might surve as information downgrade
> buffer. It raises label, reads info, lowers label, writes info.
> 
> One can say -- do not allow users change labels. This is one of the
> possible solutions. I see another one - why not to limit the way user can
> change its label. Only up -- for mls policy and vs for biba. That's for
> ordinary users, of cause.

i'm afraid i can't comment on MLS and BIBA with much authority but
my experience is that a process can be downgraded and write up.  in
your scenario a user could write software that would downgrade
itself but it will never be able to recieve information from a
higher level so cannot write it to a lower level.  as for the
information being buffered in memory i can't think of a reasonable
solution except tagging memory blocks with security labels.

an alternative hack may be to mark the "top level" process (i.e: one
spawned outside the users control -- e.g: shell) and only allow that
process to switch level (i.e: the privilage would not be inherited
by child processes).  although it wouldn't eliminate the issue of
buffering/downgrade/write scenario it would mitigate it.  the
admin/security officer could then mark certain binaries as "top
level" (i'm sure there's a better name for this privilage).

this would most likley insert the need for a further privilage that
would allow a process to assign "top level" to it's child processes
because any process that wished to reduce it's security level would
have to do this prior to forking or end up with it's child processes
isolated at a higher security level.

-- 
: fergus cameron                :   [ .]        cobbled    :
: ^^^^^^@cobbled.net            : [ ~][ ]             .net :
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/trustedbsd-discuss/attachments/20050404/d43b7afe/attachment.bin


More information about the trustedbsd-discuss mailing list