[redhat-lspp] getattr and mls

[Clarkson, Mike R (US SSA)]

I agree that for some threat models hiding existence of levels is
important, but not for all models. Also even when hiding the existence
is import, it often doesn't need to be protected at the same level as
the data itself. Thus, it would be nice to be able to separate the read
and getattr mls protections. This leads to a question I've had for a
while. Has there been any consideration to providing greater granularity
of mls control?

The existing approach works like this:

mlsconstrain { dir file lnk_file chr_file blk_file sock_file fifo_file }
{ read getattr execute }
	(( l1 dom l2 ) or
	 (( t1 == mlsfilereadtoclr ) and ( h1 dom l2 )) or
	 ( t1 == mlsfileread ) or
	 ( t2 == mlstrustedobject ));

With an mls.if interface like this:

interface(`mls_file_read_up',`
	gen_require(`
		attribute mlsfileread;
	')

	typeattribute $1 mlsfileread;
')

An approach like the following would provide the same level of
convenience, but add additional flexibility:

Use three mlscontrain statements instead of one, separating the read,
getattr, and execute privileges

mlsconstrain { dir file lnk_file chr_file blk_file sock_file fifo_file }
{ read}
	(( l1 dom l2 ) or
	 (( t1 == mlsfilereadtoclr ) and ( h1 dom l2 )) or
	 ( t1 == mlsfileread ) or
	 ( t2 == mlstrustedobject ));

mlsconstrain { dir file lnk_file chr_file blk_file sock_file fifo_file }
{ getattr}
	(( l1 dom l2 ) or
	 (( t1 == mlsfilegetattrtoclr ) and ( h1 dom l2 )) or
	 ( t1 == mlsfilegetattr ) or
	 ( t2 == mlstrustedobject ));

mlsconstrain { dir file lnk_file chr_file blk_file sock_file fifo_file }
{ execute}
	(( l1 dom l2 ) or
	 (( t1 == mlsfileexecutetoclr ) and ( h1 dom l2 )) or
	 ( t1 == mlsfileexecute ) or
	 ( t2 == mlstrustedobject ));

Then provide the following four interfaces, instead of the single one
shown above:

## This provides exactly the same privilege as mls_file_read_up does in 
## the original approach.
interface(`mls_file_read_up',`
	gen_require(`
		attribute mlsfileread;
		attribute mlsfilegetattr;
		attribute mlsfileexecute;
	')

	typeattribute $1 mlsfileread;
	typeattribute $1 mlsfilegetattr;
	typeattribute $1 mlsfileexecute;
')

interface(`mls_file_read_up_only',`
	gen_require(`
		attribute mlsfileread;
	')

	typeattribute $1 mlsfileread;
')

interface(`mls_file_getattr_up_only',`
	gen_require(`
		attribute mlsfilegetattr;
	')

	typeattribute $1 mlsfilegetattr;
')

interface(`mls_file_execute_up_only',`
	gen_require(`
		attribute mlsfileexecute;
	')

	typeattribute $1 mlsfileexecute;
')

This could be further refined by using M4 macros to eliminate the
redundancy of the 3 mlsconstrain statements above:

define(`mls_rx_filetype_constraint',
mlsconstrain { dir file lnk_file chr_file blk_file sock_file fifo_file }
{ $1}
	(( l1 dom l2 ) or
	 (( t1 == $2 ) and ( h1 dom l2 )) or
	 ( t1 == $3 ) or
	 ( t2 == mlstrustedobject ));
')

mls_rx_filetype_constraint(read, mlsfilereadtoclr, mlsfileread)
mls_rx_filetype_constraint(getattr, mlsfilegetattrtoclr, mlsfilegetattr)
mls_rx_filetype_constraint(execute, mlsfileexecutetoclr, mlsfileexecute)

Any thoughts?

> -----Original Message-----
> From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu]
> Sent: Thursday, November 15, 2007 12:11 PM
> To: Clarkson, Mike R (US SSA)
> Cc: redhat-lspp at redhat.com
> Subject: Re: [redhat-lspp] getattr and mls
> 
> On Thu, 15 Nov 2007 11:30:16 PST, "Clarkson, Mike R (US SSA)" said:
> > Is there a compelling reason to protect the getattr permission with
mls
> > constraints?
> >
> > The RHEL5 policy treats the gettattr the same way read is treated
with
> > respect to mls constraints. What information that may be classified
is
> > being protected?
> 
> For some threat models, the ability to detect "MLS level xyzzy exists
on
> this system" is in itself Bad Juju.   Being able to determine that
file
> ABC is unreadable because it's in level xyzzy is, itself, potentially
> unacceptable information leakage....