[Security_sig] Security Gaps
emilyr at us.ibm.com
Fri Oct 14 14:16:11 PDT 2005
Chris Wright <chrisw at osdl.org> wrote on 10/13/2005 03:09:35 PM:
> * Emily Ratliff (emilyr at us.ibm.com) wrote:
> > Secure virtualized containment (not SELinux) ala Solaris
> > or HPUX Secure Resource Partitions
> > this often gets punted to Xen, but there is an advantage for
> > both types of virtualized containment available
> > Linux project: vserver not integrated
> This one is tough. Do people really want it? vserver, zones, hpux
> partitions don't give good isolation, so there's a lot of domain
> that can interfere with isolation attempts, IOW, Xen is better there.
> Or do people want better resource control (ala CKRM). I've worked with
> the vserver folks in the past, and mainline integration is not that high
> on their priority list.
I think that people want both. As an example where it would be nice to have
partitions within partitions, think about special purpose partitions being
built for Xen, or all of the functionality being put into DOM0. It would
be nice for all of the special purpose partition functionality to run in
either a single DOMU or in DOM0, if the functionality could be reasonably
> > Easy to use RBAC tools (not talking about RBACPP)
> This could be easy to use any security tools (effectively it's about
> creating and administering sane policy)
I'll go along with that. :-)
> > Whole disk encryption
> dm target not sufficient?
Here's an example article along this line:
> > Patch risk assessment
> What can be done here?
What I'm imagining here is an addition to the interfaces that apply the
patch, YOU, yum, etc. to make it clear whether an exploit has been spotted,
how invasive the patch is, and other bits of information that an
administrator can use to determine the trade-offs for applying the patch.
To some degree this is in the High/Medium/Low categorization. I think that
there is a lot of room for improvement and fresh ideas in this area.
> > MLOSPP compliance may become an issue in the near future
> Aside from FIPS, what are the showstoppers here?
Disclaimer: I haven't talked to an evaluator about MLOSPP and I'm not sure
that I would consider all of these show stoppers versus areas where work
is required. The crypto requirements in general are of concern. Requirement
for integrity labels in addition to sensitivity labels. Covert channel
requirements (limited illicit information flows). Modular decomposition
requirement (current draft).
> > Other requests that we have received - default umask 037, no world
> > writeable directories (/tmp) on filesystems/partitions with
> > binaries and log files.
> What's the concern with the latter bit?
They want to be able to mount filesystems with world writeable directories
as nosuid and they are worried about rogue users exhausting disk space for
IBM Linux Technology Center, Security
emilyr at us.ibm.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the security_sig