[Security_sig] 10/14 Conf. call minutes
sds at epoch.ncsc.mil
Tue Oct 19 13:03:35 PDT 2004
On Tue, 2004-10-19 at 14:24, Chris Wright wrote:
> I agree, it should be. However, esp. w/ the configuration complexity,
> and lack of vendor integration, we actually got pushback on this (yeah,
> surprised me too). If you look at some of the assumptions posted
> a while back, you'll see some really scary stuff, like protected by
> physical security and implicitly trusted authenticated admins, and
> network partitioning...trying to force the hand of the "DAC is enough."
> One issue is that a conversation about Linux and MAC inevitably points
> to SELinux as a solution when we're not interested in pushing any
> particular solution. Further it quickly hits, "too complex," "too
> expensinve," "not in my enterprise," which derails the conversation
> about using MAC in general.
I think the proper response to such complaints is "Better integration
and tools are coming", and "We (OSDL/Security SIG/whomever) are
helping to make it happen because we believe that MAC is necessary to
truly secure the computing environment." Something to note here is
that MAC as we use the term has three principal properties:
1) Administratively-defined policy,
2) Enforced over all subjects and objects in the system,
3) Security decisions based on all security-relevant information.
A number of other security projects that claim to provide MAC do not
and can not meet these three criteria. With SELinux, you can relax
the posture as desired in your policy configuration so that you end
up devolving to one of the simpler "MAC" models, but the base mechanism
gives you the full flexibility to decide. With the simpler "MAC"
models, you are locked into their more limited approach.
> Heh, sure you can. In fact, last I checked that's what SELinux does ;-)
> Unless packages come with files already labelled, you are dependent
> upon pathnames for object labelling. And even if the packaged files
> are labelled, you may need to relabel based on local policy (which is
> path based). Depending on your level of paranoia even this is not
> acceptable, but in practice it works. Whether the type information
> is made explicit in the configuration or is implicit hits the issue of
> model flexibility vs. ease of administration. The jury is still out on
> whether simple tasks are better done with simple models.
It is true that the SELinux file_contexts configuration uses pathnames
to initialize the file labels at install time. Initializing the file labels at
install time is reasonable given security measures in development and
distribution, which are addressed elsewhere in the evaluation criteria.
But continuing to use pathnames at runtime as a basis for security
decisions is fundamentally flawed; the pathname conveys nothing about
the real security properties of the object.
> And all the labels in the world may not stop me from opening /etc/shadow
> with my privileged role, and opening an editor in my unprivileged role,
> and using my eyes and the keyboard to copy the contents. Different threat
> models, different protection schemes...
But the principal benefit of MAC is protection against malicious and
flawed programs, not malicious users. It can partition users better
into differing categories so that a user with lesser authorization is
less of a risk, but no one ever claimed MAC helps against a malicious
user authorized for the data.
Stephen Smalley <sds at epoch.ncsc.mil>
National Security Agency
More information about the security_sig