[Security_sig] 8/05 Conf. call minutes
chrisw at osdl.org
Thu Aug 5 11:26:26 PDT 2004
Ge Weijers (Sun)
Emily Ratliff (IBM)
Ed Reed (Novell)
Chris Wright (OSDL)
John Cherry (OSDL)
Matt Anderson (HP)
Makan Pourzandi (Ericsson)
- CGL Security requirements doc
- DCL assumptions (didn't get to this one)
- continue discussion of MAC/RBAC/Privsep needs in CGL on list
with goal of getting a concise question (or set of ?s) for Ge
to ask CGL WG.
Ge: X.805? Not really telecom security experts, so we do the best from
the docs. Three planes. End User plane (telephone data, fax, web
traffic, whatever), control plane (i.e. SS7), management plane (setup
systems, billing info upload). Security layers... Some areas overlap.
Web interface to update account info. What kind of assumptions, etc.
Chris: Application becomes ripe for attack vector. Separation of
application facing network and application facing control plane. I
don't think we can specify applicatin security. But we can make sure we
provide a rich set of security primitives that the application can use.
Makan: Different applications running, difficult to general purpose
security for all of them. Perhaps we should limit just the platform.
Ge: Agree, but some application info influence the platform security.
Have to be able to make spplication assumptions to make platform
assumptions for what security provides.
Makan: Agree, just want to make sure we don't make application security
Ge: Telephony application that isn't interpretting data is unlkely to
have buffer overflow. But web application that I can set provisioning
data (where my phone rings first) does data interpretation and
communicates back and forth between planes. Agree we can't dictate
Makan: We agree. Just should have a small section that highlights this.
Chris: I thoguht that was already in the document.
Ge: We can't dictate for the application, but we do need to provide
Makan: I think the confinement is very useful, for example.
Chris: I think we are in agreement that we can't specify application
security, but we can ensure the platform has the security mechanisms
available to the application (or integrator) to due proper confinement,
Ge: Different hosts for different planes is probably unrealistic, for
customer premise equipment.
Chris: Completely agree.
Ge: For separation, what do we require?
Chris: In other words what confinement/seperation options do we specify.
Ed: Traditional trusted admin. env. contradicts separation of admin
roles. Well, we probably recognize that there will be root. But we
don't want to have to use it.
Ed: Do we need that specificity here? Allow for roles, etc... without
Ge: What are the roles from a telecom application that would map to
operating system privileges? E.g. down a T-1 vs. add a new number.
Ed: Agree, but if you can add disks, etc, perhaps there are
Ge: May not need RBAC do we need? RBAC, Solaris for example, is useful
for multiple users sharing roles. Multiple nurses (users), doctors
(users) etc, with different needs that can be shared by common roles (a
nurse role with read access to records and a doctor role with write
Ed: What level do we specify? The solution space is still being
innovated, so there isn't really an answer yet.
Makan: RBAC in Solaris was user based. Telecom app is one at most two
users. Separate privs might be sufficient. Or ability to drop privs.
Ge: Dropping privs at admin task exectution time may be sufficient for
managing least privs.
Ed: Yes, separating privs for each admin application so that admin who
can change the IP can't add a tap.
Makan: Convinced user is not right level. Privilege separation and
RBAC might be enough. Just show list of existing projects. Project
exist and opensource has been a requirement.
John: Yes, that's the requirement.
Chris: I'm not convinced that we need to worry about malicious admin.
This is one of the assumptions that we've vetted though WG.
DCL/CGL discussion which includes discussion on RBAC and admin role
separation. Conclusion: CGL may not generate a need for labeled
security like RBAC, where we expect DCL will. So limiting converstaion
to CGL for now.
More dicussion on usage model with single user or few users. And
questions of whether traditional confinements of uid separation and
things like chroot are sufficient.
Chris: Early on I was convinced that folks has bought into MAC. Now
from conversations here, I'm less convinced that it's an easy sell,
mainly due to cost of deployment.. And, at this point I'm not convinced
that it's even needed with separate uids, etc.
Makan: Well, we all know that separate uids is the right thing.
Even the application developers know this, but market realities may
generate less secure environment. So applications ship as single user.
So having the ability to do fine-grained definitions (like SELinux)
for what each application can do to separate apps is useful.
Chris: This is confusing. On one side we have a single trusted admin
and an untrusted user app. So separation might be done with uid/chroot.
But single user with multiple apps that need fine-grained SELinux-style
confinement is at odds with this. Which do we need?
More dicussion on this MAC vs. DAC requirements...
Conclusions: We've agreed that we don't care about application specific
security needs. And we can't specifiy separate processors for separate
security planes. The sticking point is about whether the environmental
assumptions are restrictive enough that the rest of the security needs
of the system can be handled without MAC. We'll take this up on the
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
More information about the security_sig