|
From: Mimi Z. <zo...@li...> - 2010-02-19 21:28:45
|
On Fri, 2010-02-19 at 15:42 +0100, Roberto Sassu wrote:
> > Hello all
> >
> > i'm wondering what assumptions must be made in order to assure that the domain
> > "domX" is the only subject allowed to access a file with type "typeY" in a
> > system where off-line attacks are possible and an integrity check on files and
> > labels in the overall filesystem is not applicable due to the high performance
> > penalty.
> >
> > These are the hypothesis i think are required:
> > 1) kernel with SELinux, with policy loading and enforcing mode setting
> > disabled at runtime;
> > 2) there is an integrity system stacked with SELinux which is able to
> > grant/deny access depending on the hash and the label of files (checks will be
> > performed only a subset of files, as described in the following points);
> > 3)"local_login_t" is the only domain allowed to change the process label;
> > 4) every file used by the type "local_login_t" is integrity protected (i need
> > to build a list files used by this process and to specify a valid hash)
> > 5) the regular user which plays with "domX" is mapped with the selinux user
> > "user_t" (probably i need extra assumptions to protect the mapping);
> > 6) "domX_exec_t" is the only entrypoint for "domX";
> > 7) the label "domX_exec_t" is bound to the executable and its hash (the
> > association is verified at execution time);
> > 8) the transition "user_t -> domX" has been defined when executing a file
> > labeled with "domX_exec_t";
> > 9) for now i assume that the user root is not involved in this use case;
> > 10) file labelled with "typeY" are protected and the label is bound to the
> > hash (the association will be verified at access time);
> > 11) none subject is authorized to relabelfrom "typeY";
> >
> > Then when defining the rule:
> > allow domX typeY: file { getattr open read };
> >
> > can i say that files labelled with typeY can be read only by the process
> > started from the executable labelled with "domX_exec_t"?
> >
> > Thanks in advance for replies
Assuming the protection mechanism itself (kernel and associated
policies) is protected as well as the selected file data and metadata,
then this should work. There are some subtleties, such as all
directories in path to the labeled files must be protected, to block
renaming/relocation attacks (exchanging a valid rm for a valid ls).
We're looking at doing something similar. As you mentioned, protecting
the overall system has too high a penalty, so we're looking at
protecting just the files owned by root as the default policy.
I'm adding an integrity appraisal extension to IMA, which will maintain
the hash in security.ima. To protect the extended attribute from
off-line attack, EVM will maintain an hmac across the set of security
extended attributes. (Both sets of patches coming shortly.)
The initial patches will authenticate the selected extended attributes,
and cryptographically bind them to the inode; however, additional work
will still be needed to bind other directory and inode metadata for more
complete protection.
Mimi
|