Venkat Yekkirala wrote:
Keeping in mind (R1a), I wonder if it makes more sense for (OTBND1a)
to take the label of the process/domain which sends the data to the
socket? After all, the process/domain is the "origin" of the data.
Right. This is what "ends up" happening in the non-privileged case
Keeping in mind (R1a), I wonder if it makes more sense for (OTBND1a) to take
the label of the process/domain which sends the data to the socket? After
all, the process/domain is the "origin" of the data.
Right. This is what "ends up" happening in the non-privileged case. In the
privileged multi
On Monday 26 June 2006 7:05 pm, Venkat Yekkirala wrote:
> USER REQUIREMENTS:
>
> The broad user requirements for labeled networking would be that of
> information labeling and flow control. Specifically,
>
> 1. Data labeling:
> a. data must be labeled where it originates.
> b. data must
On Mon, 26 Jun 2006, Venkat Yekkirala wrote:
> > What we need is a design rationale, some kind of detailed discussion of what
> > the user requirements are and what the plan is for implementing features to
> > meet these requirements.
>
> The following is not extensive in a formal/theoretical sen
What we need is a design rationale, some kind of detailed
discussion of
what the user requirements are and what the plan is for implementing
features to meet these requirements.
The following is not extensive in a formal/theoretical sense, but hopefully
addresses the need here.
Needless to sa
> There's also the question of ongoing maintenance in the
> mainline kernel. Unfortunately, there's been an increasing
> trend recently for companies to drop code over the wall. For
> example, once they get it to some basic level of completeness,
> and the initial patches are merged, their dev
On Wed, 21 Jun 2006, Venkat Yekkirala wrote:
> > Can you clarify whether, with this patch, Linux will then have a
> > complete labeled network implementation in terms of both LSPP
> > compliance and common user requirements?
>
> I can't comment on the LSPP compliance issue since the specific/pr
> Can you clarify whether, with this patch, Linux will then
> have a complete
> labeled network implementation in terms of both LSPP
> compliance and common
> user requirements?
I can't comment on the LSPP compliance issue since the specific/proprietary
security target being used might really
On Tue, 20 Jun 2006, Venkat Yekkirala wrote:
> The current approach to labeling Security Associations for SELinux
> purposes uses a one-to-one mapping between xfrm policy rules and
> security associations. This doesn?t address the needs of real world MLS
> (Multi-level System, traditional Bell-
