From jmorris at namei.org  Tue Apr  1 16:41:01 2008
From: jmorris at namei.org (James Morris)
Date: Wed, 2 Apr 2008 10:41:01 +1100 (EST)
Subject: [fmac-discuss] ANN: SELinux Developer Summit 2008, Ottawa
Message-ID: <Xine.LNX.4.64.0804021025040.25321@us.intercode.com.au>

----------------------------------------------------------------------------
SELinux Developer Summit 2008, Ottawa
----------------------------------------------------------------------------

This is to announce the 2008 SELinux Developer Summit, which is to be held
in Ottawa on the 22nd of July, as an OLS mini-summit.

The SELinux Developer Summit will be a one day summit intended to provide 
a forum for focused technical discussion regarding current and future 
development plans for SELinux and related Flask/TE projects.

The intended audience will consist of current SELinux developers,
system/security administrators, distribution organizers/packagers, and power
users.  The format will be a mix of presentations and moderated discussion,
including a panel where attendees will be invited to submit questions and
feedback.

** This will be an open event, although, to attend, you will be required to be
registered for the 2008 Linux Symposium. **

A Call for Participation (CFP) will be issued on 7th April, 2008.  If you wish
to submit a presentation or panel topic, please do so then.

To contact the organizing team, send email to:

    selinux-summit-team AT namei.org

Also refer to the resources below for more information.

[1] SELinux Developer Summit:
    http://selinuxproject.org/page/Developer_Summit_2008

[2] OLS mini-summits:
    http://www.linuxsymposium.org/2008/minisummits.php

----------------------------------------------------------------------------

-- 
James Morris
<jmorris at namei.org>


From jmorris at namei.org  Fri Apr  4 03:16:06 2008
From: jmorris at namei.org (James Morris)
Date: Fri, 4 Apr 2008 21:16:06 +1100 (EST)
Subject: [fmac-discuss] ANN: 2008 SELinux Developer Summit CFP
Message-ID: <Xine.LNX.4.64.0804042114060.29760@us.intercode.com.au>

---------------------------------------------------------------------------
2008 SELinux Developer Summit Call For Participation (CFP)
---------------------------------------------------------------------------

The call for participation for the 2008 SELinux Developer Summit is now
open.  The summit will be held July 22nd in Ottawa.  See the original
announcement[1] for the summit and the summit wiki page[2] for background
about the summit and summaries of prior summits.  Note that all attendees of
the mini-summit must be registered as attendees of the Linux Symposium [3].

The focus of this year's summit will be usability and infrastructure.
Usability topics of interest include (but are not limited to) policy
development, administration, and desktop integration.  Infrastructure topics
of interest include (but are not limited to) embedded systems, label
translation, userspace object managers, network filesystems, and labeled
networking.

Other topics relating to SELinux technology, flexible mandatory access
control, and its application to real-world problems are also of interest for
this symposium. Such topics might include:

    * Updates on the various Linux distributions using SELinux
    * Flexible MAC in other operating systems
    * Case studies and application experience with flexible MAC
    * User and customer concerns and needs

Forms of participation include:

    * Technical presentations (20-30 minutes each, papers are optional)
    * Discussions (submitter acts as facilitator)
    * Panels (submitter acts as moderator)
    * Lightning talks (work-in-progress reports)

No marketing pitches will be accepted.

Proposals may be sent to the organizing team at:

    selinux-summit-team AT namei.org

In your proposal, please identify the form of participation, the amount of
time you expect to need, and a title and abstract describing the topic you
wish to cover.

If you wish to attend the summit without presenting, please also send a
notification of your intent to attend to the organizing team at the above
alias.

** Whether presenting or just attending, you must register for the Linux
Symposium[3] in order to attend the SELinux Developer Summit. **

This CFP will end on April 18.  Participants will be notified by April 25,
and the schedule will be published on April 02.

[1] SELinux Summit announcement, http://marc.info/?l=selinux&m=120716549912011&w=2
[2] SELinux Summit wiki page, http://selinuxproject.org/page/Developer_Summit_2008
[3] Linux Symposium, http://www.linuxsymposium.org/2008/

----------------------------------------------------------------------------

-- 
James Morris
<jmorris at namei.org>


From alan.duboff at sun.com  Fri Apr  4 04:09:27 2008
From: alan.duboff at sun.com (Alan DuBoff)
Date: Fri, 4 Apr 2008 04:09:27 -0700 (PDT)
Subject: [fmac-discuss] ANN: 2008 SELinux Developer Summit CFP
In-Reply-To: <Xine.LNX.4.64.0804042114060.29760@us.intercode.com.au>
References: <Xine.LNX.4.64.0804042114060.29760@us.intercode.com.au>
Message-ID: <Pine.GSO.4.64.0804040348180.23996@eagle>

On Fri, 4 Apr 2008, James Morris wrote:

> ---------------------------------------------------------------------------
> 2008 SELinux Developer Summit Call For Participation (CFP)
> ---------------------------------------------------------------------------

James,

Thanks for including the FMAC community of OpenSolaris in your Call For 
Participation. I hope to see OpenSolaris be a strong player in this space, 
and certain there will be participation at the Summit.

Others in the SELinux community should feel welcome to join the FMAC 
community on OpenSolaris for discussion of Flask/Type_Enforcement related 
issues, as pertained to all systems.

I know that I will be trying to understand SELinux community more, much 
the same.

John Weeks presented an introduction to FMAC at the OpenSolaris user group 
I run in Silicon Valley, and if anyone is interested you can view it on 
ustream at our user group page, here:

http://www.ustream.tv/channel/svosug

The first video is late week's meeting.

You can get the slides to go along with the presentation at this link:

http://blogs.sun.com/aland/resource/FMAC_intro.pdf

I have to take blame for the video, John is very small and hard to see, 
but some have said he looks better like that, so quality is subjective.;-)

--

Alan DuBoff - Solaris x86 IHV/OEM Group


From john.weeks at sun.com  Sat Apr 12 14:57:18 2008
From: john.weeks at sun.com (John Weeks)
Date: Sat, 12 Apr 2008 14:57:18 -0700
Subject: [fmac-discuss] Progress update
Message-ID: <4801303E.9010203@sun.com>

Hi,

I've been busy for the past several weeks integrating the contributed Flask/TE 
implementation into an OS/Net (ON) gate that's based on build 86. So, now that I 
have some of the code built I thought it would be a good time to show you what's 
working.

Output of uname:
----------------

tralfaz-65% uname -a
SunOS tralfaz 5.11 onnv-fmac-jweeks i86pc i386 i86pc

Checkpolicy in action:
----------------------

tralfaz-63% /usr/sbin/checkpolicy -d -b 
/etc/security/fmac/ss_policy/usr/sbin/checkpolicy:  loading policy configuration 
from /etc/security/fmac/ss_policy
security:  4 users, 4 roles, 271 types, 22 levels
security:  28 classes, 37862 rules
/usr/sbin/checkpolicy:  policy configuration loaded

Select an option:
0)  Call compute_access_vector
1)  Call sid_to_context
2)  Call context_to_sid
3)  Call transition_sid
4)  Call member_sid
5)  Call change_sid
6)  Call list_sids
7)  Call load_policy
8)  Call fs_sid
9)  Call port_sid
a)  Call netif_sid
b)  Call node_sid
c)  Call fs_use
d)  Call genfs_sid
e)  Call get_user_sids
m)  Show menu again
q)  Exit

Choose:  q

tralfaz-64% /usr/sbin/checkpolicy -V
15-mls

Policy loaded in kernel:
------------------------

Apr 12 09:00:56 tralfaz genunix: [ID 510077 kern.notice] NOTICE: fmac: Loading 
policy /etc/security/fmac/ss_policy
Apr 12 09:00:57 tralfaz genunix: [ID 328047 kern.notice] security:  4 users, 4 
roles, 271 types
Apr 12 09:00:57 tralfaz genunix: [ID 114590 kern.notice] , 22 levels
Apr 12 09:00:57 tralfaz genunix: [ID 100000 kern.notice]
Apr 12 09:00:57 tralfaz genunix: [ID 343361 kern.notice] security:  28 classes, 
37862 rules
Apr 12 09:00:57 tralfaz genunix: [ID 635134 kern.notice] NOTICE: fmac: Policy 
loaded from /etc/security/fmac/ss_policy

No system calls or avc hooks in the kernel yet, but it's good to have the base 
Flask/TE code working :-)

We will be starting design discussions on the list next week.

-John




From Glenn.Faden at Sun.COM  Sun Apr 13 16:05:23 2008
From: Glenn.Faden at Sun.COM (Glenn Faden)
Date: Sun, 13 Apr 2008 16:05:23 -0700
Subject: [fmac-discuss] Zones and Flask
Message-ID: <480291B3.7090602@sun.com>

I'd like to get a discussion going about how Solaris zones should be 
treated by Flask. Since all zones share a single kernel it is natural to 
assume that they will share the same security server. But the Solaris 
kernel has zone-awareness built in, and individual zones can act like 
virtual machines, so Flask should support some notion of zone-awareness, 
as well.

There is the related issue of flexibility. Zones provide strong but 
coarse separation, and providing flexibility of cross-zone policies is 
generally a bad thing. The major premise of the Solaris zone model is 
that no process in a non-global zone (even running with all the zone's 
privileges) can cause damage to any other zone including the global 
zone. In Trusted Extensions we've gone even further to prevent any 
communication between processes in different zones, including via the 
filesystem or the network.

One could argue that Flask could be used to provide a more flexible 
cross-zone access control, but I think this would be a mistake. In the 
SELinux implementation, the security server is called to restrict access 
that would otherwise be allowed, but it doesn't weaken the default 
(legacy) policy.

I think the value of Flask is its ability to provide fine-grained access 
within each zone, especially within the global zone. Since the global 
zone is special, it may need to have unique policy rules from non-global 
zones. But rather than special-case the global zone, we should consider 
per-zone attributes as part of the policy specification.

One more issue is the fact that user IDs in different zones may 
correspond to the same user (as they do with Trusted Extensions) or may 
be unrelated, as in the more general consolidation model. In the latter 
case, it is likely that users would be assigned different initial 
security contexts since they represent different individuals. But we may 
want to do that in either case since the MLS component of the security 
context, for example, would be different in each zone.

--Glenn


From sds at tycho.nsa.gov  Mon Apr 14 06:03:41 2008
From: sds at tycho.nsa.gov (Stephen Smalley)
Date: Mon, 14 Apr 2008 09:03:41 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <480291B3.7090602@sun.com>
References: <480291B3.7090602@sun.com>
Message-ID: <1208178221.18883.40.camel@moss-spartans.epoch.ncsc.mil>


On Sun, 2008-04-13 at 16:05 -0700, Glenn Faden wrote:
> I'd like to get a discussion going about how Solaris zones should be 
> treated by Flask. Since all zones share a single kernel it is natural to 
> assume that they will share the same security server. But the Solaris 
> kernel has zone-awareness built in, and individual zones can act like 
> virtual machines, so Flask should support some notion of zone-awareness, 
> as well.

Thanks for starting this discussion.  I've written down some initial
thoughts on how FMAC/Flask might interest with not only zones but also
the other Solaris security mechanisms that I'll send out shortly to the
fmac-discuss list, but I'll try to respond briefly here to your points.

I agree that Flask/FMAC should ultimately support some way to express
policy based on zone; we have a similar need in Linux for containers.
But I don't expect that to happen right away in the first round of
integration, as there is plenty of work to be done just to get the basic
integration done.

> There is the related issue of flexibility. Zones provide strong but 
> coarse separation, and providing flexibility of cross-zone policies is 
> generally a bad thing. The major premise of the Solaris zone model is 
> that no process in a non-global zone (even running with all the zone's 
> privileges) can cause damage to any other zone including the global 
> zone. In Trusted Extensions we've gone even further to prevent any 
> communication between processes in different zones, including via the 
> filesystem or the network.
> 
> One could argue that Flask could be used to provide a more flexible 
> cross-zone access control, but I think this would be a mistake. In the 
> SELinux implementation, the security server is called to restrict access 
> that would otherwise be allowed, but it doesn't weaken the default 
> (legacy) policy.

Where I could envision some degree of flexibility is in allowing the
policy to dictate allowed information flow among the zones, such the one
could directly express and enforce "assured pipelines" of zones in the
kernel policy via FMAC/Flask.  That is a natural generalization of the
existing support for expressing and enforcing assured pipelines of
processes.  The approach wouldn't be to weaken existing restrictions on
the non-global zones but rather to provide a reinforcement of what today
might only be expressed and enforced by entities in the global zone.

> I think the value of Flask is its ability to provide fine-grained access 
> within each zone, especially within the global zone. Since the global 
> zone is special, it may need to have unique policy rules from non-global 
> zones. But rather than special-case the global zone, we should consider 
> per-zone attributes as part of the policy specification.

We can actually treat the zones differently without necessarily
supporting per-zone attributes in policy, just by encoding the
differences in the Type Enforcement type space.  But I do agree that
ultimately we're interested in exploring more direct support for
handling the zones.

> One more issue is the fact that user IDs in different zones may 
> correspond to the same user (as they do with Trusted Extensions) or may 
> be unrelated, as in the more general consolidation model. In the latter 
> case, it is likely that users would be assigned different initial 
> security contexts since they represent different individuals. But we may 
> want to do that in either case since the MLS component of the security 
> context, for example, would be different in each zone.

Yes, this makes sense.  What may help here as well is that for
Flask/FMAC, we map Unix user ids to policy user ids first, then
authorize the policy user ids for specific attributes.  So a given Unix
user id in one zone may map to a different policy user id than that same
Unix user id in another zone.
 
-- 
Stephen Smalley
National Security Agency



From sds at tycho.nsa.gov  Mon Apr 14 06:08:02 2008
From: sds at tycho.nsa.gov (Stephen Smalley)
Date: Mon, 14 Apr 2008 09:08:02 -0400
Subject: [fmac-discuss] Integrating FMAC into OpenSolaris
Message-ID: <1208178482.18883.43.camel@moss-spartans.epoch.ncsc.mil>

Hi all,

I finally got some time to sit down and write up my current thoughts
on how I expect this project to approach integrating FMAC into
OpenSolaris, and how it might interact with Solaris' existing security
mechanisms.  These are just my thoughts - feel free to jump in and
discuss!

In general, I would expect to follow the same basic approach as
described for Linux in the published paper and technical report
available from: 
- http://www.nsa.gov/selinux/papers/freenix01-abs.cfm
- http://www.nsa.gov/selinux/papers/slinux-abs.cfm

John Weeks is starting by adding the NSA-contributed Flask
infrastructure (security server, AVC) to the kernel, introducing
support for labeling processes and files with security contexts, and
introducing basic permission checks over process context transitions
upon exec and over file accesses.  This should yield a useful
proof-of-concept code base that people can play with and learn from.

We will then gradually expand the set of process and file operations
covered by Flask permission checks.  We will later turn our attention
to sockets (local and network) and other kernel objects and
operations, seeking to gradually obtain complete coverage over all
kernel objects and operations.

Precisely how FMAC will ultimately interact with existing Solaris
security mechanisms is not firmly decided yet, but the following
description represents my current thinking.  Note that much of
this may change as we learn more about the system and how it works in
practice.  Community input and feedback is welcome.

In the following descriptions, I will sometimes distinguish between
how FMAC/Flask (i.e. the framework) might interact with existing
Solaris security mechanisms and how the particular security models
(RBAC, Type Enforcement (TE), and MLS) implemented by the example
security server (policy engine) might interact with those mechanisms.
We aren't necessarily bound to the example security server although we
do believe it is a good starting point and we particularly want to
preserve its support for TE, as noted in the FMAC project intro.  One
issue to consider with regard to deviating from the example security
server is that the more we deviate from it, the less compatible we
will become with Linux and the less we will be able to reuse existing
tools and infrastructure for policy.  One deviation that already
exists is that the MLS model in the example security server that has
been contributed to OpenSolaris is not the same as what is presently
in Linux, as the Linux implementation of MLS was overhauled by others
after our original contribution.

- Audit and System Logging: In the Linux implementation, we started
off using the system logging (sysklogd) facility for reporting
permission denial messages, and later migrated to using the audit
subsystem when it was created for Linux.  We will need to do
something similar in Solaris; we might start with system logging if
that is easier and then migrate to using audit or we could possibly
start using audit from the beginning if that is straightforward to do.
We will need to be able to easily feed these denials from the system
logs or audit logs into tools for policy development and debugging.
We will also eventually want to look at extending the audit facility
to include process and object security contexts in its existing audit
records and to support filters based on security contexts, as was 
also done in Linux.

- Discretionary Access Control (DAC): FMAC is orthogonal and
complementary to DAC.  Each operation must pass both its DAC check and
its FMAC check in order to proceed.

- Privileges: FMAC will apply a parallel permission check for each
privilege check.  This mirrors the interaction between Linux
capabilities and SELinux.  This is particularly leveraged by the TE
model in the example security server to limit root processes and
setuid programs to least privilege, to bind privileges to specific
programs, and to establish firm boundaries on privilege escalation.
There are two options for how the base privilege check should interact
with the FMAC permission check:
1) Similar to DAC, require privilege to always be granted by both
mechanisms.  This is safer as it means that FMAC cannot escalate
access beyond what the normal system would have granted, but more
limiting in functionality.  This is the current situation in Linux,
although modifications to lift that restriction have been proposed and
Linux recently has gained another mechanism for assigning privileges
to programs via file capabilities.
-or-
2) FMAC can optionally override an ordinary privilege denial.  This
allows FMAC to completely manage privileges if desired.

I would suggest starting with option (1) but revisiting this issue
later once we have more experience and have assessed the state of the
Solaris userland and its dependencies on uid 0 and setuid.  We have
gradually worked through and addressed a number of such dependencies
in Linux, but will have to re-assess them in Solaris.

Note that FMAC itself does not require any new privileges and will not
be overridden by any existing privilege, as its security model is
self-contained and can directly express exceptions as needed at fine
granularity based on the fields of the security context it manages.

- FGAP: Regardless of which option is chosen above, it is important
that FGAP not be able to grant a privilege denied by FMAC, as that
would defeat the "mandatory" nature of FMAC and prevent it from
strictly guaranteeing against privilege escalation.  Thus, FGAP can be
viewed as an extension of the base privilege check computation,
potentially mutating its result, without impacting the subsequent FMAC
permission check.  Under option (1), the subsequent FMAC permission
check will only be able to deny a privilege that would have been
granted.  Under option (2), FMAC may optionally grant or deny a
privilege independent of the earlier decisions.  I would suggest
starting with option (1) here as well, then revisiting the issue
later.

- RBAC: As I understand it, in Solaris, RBAC is an application-layer
construct that is not directly visible to or enforced by the kernel.
Privileged userland establishes the initial privilege set of a process
and the kernel then merely enforces this privilege set and adjusts it
appropriately as needed.  Thus, Solaris RBAC is not fundamentally
different than Solaris privileges wrt kernel mechanism and does not
interact any differently with FMAC/Flask as a framework.

In the example security server, RBAC is a security model layered on
top of TE and roles are directly visible to the kernel as a field of
the security contexts of processes.  The RBAC model is used to control
entry into particular Type Enforcement domains, which in turn are used
to assign permission sets and privileges to processes.  Thus, the RBAC
model plays an important role in configuring the system policy and
limiting entry to domains.

I would suggest initially retaining the RBAC model of the example
security server as an orthogonal and complementary mechanism to the
Solaris RBAC mechanism, and later investigating whether we can
directly map Solaris roles to kernel roles to enable direct expression
and enforcement of role restrictions in kernel policy with
corresponding reduced need for trust on userspace agents.  The Solaris
RBAC interfaces could then potentially be mapped to the new kernel
mechanism for roles.

- Zones: Initially I expect zones and FMAC to be orthogonal and
complementary to one another.  There seems to be no reason why one
wouldn't be able to apply both simultaneously, using zones for
coarse-grained isolation and namespace separation and using FMAC for
intra-zone fine-grained protection, including hardening of the global
zone.  Later we can investigate extensions such as optionally
supporting per-zone policy.  A natural extension of FMAC would be to
introduce support for labeling zones with FMAC security contexts and
applying permission checks based on these zone labels in a similar
manner to TX, but without being MLS-specific.

- Trusted Extensions (TX): As TX is implemented via labeled zones, I
expect TX and FMAC to initially be orthogonal and complementary to one
another as with zones.  Providing finer-grained isolation within a
zone, e.g. to support huge numbers of discrete categories without
needing a separate zone for each one, would be an interesting area to
investigate.  We will definitely want to enable FMAC to leverage and
use TX facilities such as labeled networking (to convey security
contexts rather than just MLS labels) even when TX is not enabled.

As before, the above just represents a dump of my current thinking on
the matter and I'm open to discussing any and all of the above ideas.
Looking forward to a constructive dialog with the OpenSolaris and
Flask/TE communities.

-- 
Stephen Smalley
National Security Agency



From paul.moore at hp.com  Mon Apr 14 11:20:20 2008
From: paul.moore at hp.com (Paul Moore)
Date: Mon, 14 Apr 2008 14:20:20 -0400
Subject: [fmac-discuss] Reminder: 2008 SELinux Developer Summit CFP
Message-ID: <200804141420.21020.paul.moore@hp.com>

---------------------------------------------------------------------------
2008 SELinux Developer Summit Call For Participation (CFP) Reminder
---------------------------------------------------------------------------

This is a reminder that the Call For Participation (CFP) deadline for 
the 2008 SELinux Developer Summit is April 18th.  The Summit will be 
held July 22nd in Ottawa.  See the original CFP[1], the Summit 
announcement[2], and Summit Wiki[3] for more information.  It is 
important to note that all attendees of the SELinux Developer Summit 
must be registered as attendees of the Ottawa Linux Symposium[4].

The focus of this year's summit will be usability and infrastructure.  
Usability topics of interest include (but are not limited to) policy 
development, administration, and desktop integration.  Infrastructure 
topics of interest include (but are not limited to) embedded systems, 
label translation, userspace object managers, network filesystems, and 
labeled networking.

Other topics relating to SELinux technology, flexible mandatory access 
control, and its application to real-world problems are also of 
interest for this symposium. Such topics might include:

    * Updates on the various Linux distributions using SELinux
    * Flexible MAC in other operating systems
    * Case studies and application experience with flexible MAC
    * User and customer concerns and needs

Forms of participation include:

    * Technical presentations (20-30 minutes each, papers are optional)
    * Discussions (submitter acts as facilitator)
    * Panels (submitter acts as moderator)
    * Lightning talks (work-in-progress reports)

No marketing pitches will be accepted.

Proposals may be sent to the organizing team at:

    selinux-summit-team AT namei.org

In your proposal, please identify the form of participation, the amount 
of time you expect to need, and a title and abstract describing the 
topic you wish to cover.

If you wish to attend the summit without presenting, please also send a 
notification of your intent to attend to the organizing team at the 
above alias.

** Whether presenting or just attending, you must register for the Linux 
Symposium[4] in order to attend the SELinux Developer Summit. **

This CFP will end on April 18.  Participants will be notified by April 
25, and the schedule will be published on April 02.

[1] CFP, http://marc.info/?l=selinux&m=120730523920388&w=2
[2] Announcement, http://marc.info/?l=selinux&m=120716549912011&w=2
[3] Summit Wiki, http://selinuxproject.org/page/Developer_Summit_2008
[4] OLS, http://www.linuxsymposium.org/2008

-- 
paul moore
linux @ hp


From William.Young at Sun.COM  Mon Apr 14 11:43:15 2008
From: William.Young at Sun.COM (Will Young)
Date: Mon, 14 Apr 2008 14:43:15 -0400
Subject: [fmac-discuss] Integrating FMAC into OpenSolaris
In-Reply-To: <1208178482.18883.43.camel@moss-spartans.epoch.ncsc.mil>
References: <1208178482.18883.43.camel@moss-spartans.epoch.ncsc.mil>
Message-ID: <4803A5C3.9050808@sun.com>

Stephen Smalley wrote:
>
> - Zones: Initially I expect zones and FMAC to be orthogonal and
> complementary to one another.  There seems to be no reason why one
> wouldn't be able to apply both simultaneously, using zones for
> coarse-grained isolation and namespace separation and using FMAC for
> intra-zone fine-grained protection, including hardening of the global
> zone.  Later we can investigate extensions such as optionally
> supporting per-zone policy.  A natural extension of FMAC would be to
> introduce support for labeling zones with FMAC security contexts and
> applying permission checks based on these zone labels in a similar
> manner to TX, but without being MLS-specific.
>
> - Trusted Extensions (TX): As TX is implemented via labeled zones, I
> expect TX and FMAC to initially be orthogonal and complementary to one
> another as with zones.  Providing finer-grained isolation within a
> zone, e.g. to support huge numbers of discrete categories without
> needing a separate zone for each one, would be an interesting area to
> investigate.  We will definitely want to enable FMAC to leverage and
> use TX facilities such as labeled networking (to convey security
> contexts rather than just MLS labels) even when TX is not enabled.
>   
    In networking, TX is really only relying on zones for the wide sweep 
initial configuration of objects and some non-essentials.  In a network 
centric point of view we have what amounts to a hierarchical cred 
'search' from mblk, conn, process that ends at the processes' zone.

    If you want to latch in without per zone labels you will want a 
default label for the system that all zones may inherit and assign 
alternate labels specifically to processes (isolating them from their 
zone with your policy.)  Having multiple zones with the same label you 
will not be able to support all-zone interfaces which are where the per 
zone label considerations would occur.  On private interfaces we will 
not notice that the label of the zone and the process are different (we 
will only care whether the process's label matches the peer or packet 
label.)
     -Will



From darrenm at opensolaris.org  Mon Apr 14 16:26:36 2008
From: darrenm at opensolaris.org (Darren J Moffat)
Date: Tue, 15 Apr 2008 00:26:36 +0100
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <480291B3.7090602@sun.com>
References: <480291B3.7090602@sun.com>
Message-ID: <4803E82C.6040305@opensolaris.org>

Glenn Faden wrote:
> There is the related issue of flexibility. Zones provide strong but 
> coarse separation, and providing flexibility of cross-zone policies is 
> generally a bad thing. The major premise of the Solaris zone model is 
> that no process in a non-global zone (even running with all the zone's 
> privileges) can cause damage to any other zone including the global 
> zone. In Trusted Extensions we've gone even further to prevent any 
> communication between processes in different zones, including via the 
> filesystem or the network.

On the other hand TX provides controlled channels (via the global zone/ 
trusted path) between zones and it would be nice in somecases to augment 
these.

> One could argue that Flask could be used to provide a more flexible 
> cross-zone access control, but I think this would be a mistake. In the 
> SELinux implementation, the security server is called to restrict access 
> that would otherwise be allowed, but it doesn't weaken the default 
> (legacy) policy.

I have a different view on this and I think having an ability to provide 
a highly controlled cross-zone access control mechanism using Flask 
would be a bit value.

For example I've been working with a vendor recently that has a need for 
  highly controlled channels between zones; some of this can be met 
using intra-zone ipfilter rules and a mix of shared and exclusive ip 
stack zones. Not all of the data can be sent over IP ,sometimes it is 
doors or unix domain sockets.  So controlling which processes in a given 
zone can be a door client can be a peer to a door server in another zone 
is needed for them.  I can see value in expressing that policy in a 
system like Flask rather than having to code the checks into the door 
servers/clients using door_ucred/getpeerucred.


-- 
Darren J Moffat


From Darren.Moffat at Sun.COM  Mon Apr 14 15:28:46 2008
From: Darren.Moffat at Sun.COM (Darren J Moffat)
Date: Mon, 14 Apr 2008 23:28:46 +0100
Subject: [fmac-discuss] Integrating FMAC into OpenSolaris
In-Reply-To: <1208178482.18883.43.camel@moss-spartans.epoch.ncsc.mil>
References: <1208178482.18883.43.camel@moss-spartans.epoch.ncsc.mil>
Message-ID: <4803DA9E.1090601@Sun.COM>

Stephen Smalley wrote:
> - Audit and System Logging: In the Linux implementation, we started
> off using the system logging (sysklogd) facility for reporting
> permission denial messages, and later migrated to using the audit
> subsystem when it was created for Linux.  We will need to do
> something similar in Solaris; we might start with system logging if
> that is easier and then migrate to using audit or we could possibly
> start using audit from the beginning if that is straightforward to do.
> We will need to be able to easily feed these denials from the system
> logs or audit logs into tools for policy development and debugging.
> We will also eventually want to look at extending the audit facility
> to include process and object security contexts in its existing audit
> records and to support filters based on security contexts, as was 
> also done in Linux.

Personally we should start by integrating with Solaris Audit from the 
start.  It already logs lots of credential information including 
zonename and privileges.  Adding new records and events it pretty easy, 
the harder part is actually knowing what to record but the experience 
with Linux will help a lot here.

For specific auditing help contact the OpenSolaris audit project (and 
audit-discuss at opensolaris.org alias) can help.

-- 
Darren J Moffat


From Darren.Moffat at Sun.COM  Mon Apr 14 16:32:25 2008
From: Darren.Moffat at Sun.COM (Darren J Moffat)
Date: Tue, 15 Apr 2008 00:32:25 +0100
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <1208178221.18883.40.camel@moss-spartans.epoch.ncsc.mil>
References: <480291B3.7090602@sun.com>
	<1208178221.18883.40.camel@moss-spartans.epoch.ncsc.mil>
Message-ID: <4803E989.9090605@Sun.COM>

Stephen Smalley wrote:
> processes.  The approach wouldn't be to weaken existing restrictions on
> the non-global zones but rather to provide a reinforcement of what today
> might only be expressed and enforced by entities in the global zone.

This is exactly the case I'm talking about in the case I referenced in 
my other email.  The vendor is currently planning on using global zone 
"proxies" to help with the intra zone data moving or "channel" setup.

-- 
Darren J Moffat


From gww at eng.sun.com  Mon Apr 14 17:46:48 2008
From: gww at eng.sun.com (Gary Winiger)
Date: Mon, 14 Apr 2008 17:46:48 -0700 (PDT)
Subject: [fmac-discuss] Integrating FMAC into OpenSolaris
Message-ID: <200804150046.m3F0kmKF010050@marduk.eng.sun.com>

> - Audit and System Logging: In the Linux implementation, we started
> off using the system logging (sysklogd) facility for reporting
> permission denial messages, and later migrated to using the audit
> subsystem when it was created for Linux.  We will need to do
> something similar in Solaris; we might start with system logging if
> that is easier and then migrate to using audit or we could possibly
> start using audit from the beginning if that is straightforward to do.
> We will need to be able to easily feed these denials from the system
> logs or audit logs into tools for policy development and debugging.
> We will also eventually want to look at extending the audit facility
> to include process and object security contexts in its existing audit
> records and to support filters based on security contexts, as was 
> also done in Linux.

	As the current architect for the Solaris Audit project, let
	me extend you a helping hand.  As the FMAC project identifies its
	interfaces, both in the kernel and in userland that are security
	relevant from a audit perspective, the two projects will need
	close cooperation.  All audit events and their associated records
	are a necessary part of any Solaris Common Criteria Evaluation
	and as is noted in
	http://opensolaris.org/os/community/arc/caselog/2003/397/
	are obliged to be worked with the Solaris Audit (and sometimes also
	with the Solaris Evaluations) project.

	That said, Solaris Audit is flexible, extensible, and should be
	able to accommodate the FMAC projects needs without much project
	specific code.  Please contact the OpenSolaris Audit project:
	audit-discuss at opensolaris.org for help early on in determining
	the details.

	I suspect the FMAC leaders don't need additional information about
	audit, but perhaps other's on the fmac-discuss list might be interested
	in the Audit Policy:
	http://opensolaris.org/os/community/arc/policies/audit-policy/

Gary..


From john.weeks at sun.com  Tue Apr 15 07:14:06 2008
From: john.weeks at sun.com (John Weeks)
Date: Tue, 15 Apr 2008 07:14:06 -0700
Subject: [fmac-discuss] List problems
Message-ID: <4804B82E.8010808@sun.com>

It looks like we are having problems with messages posted to the list that are 
not making it to all list members. We are looking into the problem and I'll let 
you know when it's resolved.

I'd also like to remind everyone on the list that you can only post from your 
registered e-mail address. If you send from more than one e-mail address to 
fmac-discuss, then make sure you have all of them registered on the list.

-John


From gww at eng.sun.com  Tue Apr 15 11:05:17 2008
From: gww at eng.sun.com (Gary Winiger)
Date: Tue, 15 Apr 2008 11:05:17 -0700 (PDT)
Subject: [fmac-discuss] Integrating FMAC into OpenSolaris
Message-ID: <200804151805.m3FI5HFh010953@marduk.eng.sun.com>

> - Privileges: FMAC will apply a parallel permission check for each
> privilege check.  This mirrors the interaction between Linux
> capabilities and SELinux.  This is particularly leveraged by the TE
> model in the example security server to limit root processes and
> setuid programs to least privilege, to bind privileges to specific
> programs, and to establish firm boundaries on privilege escalation.
> There are two options for how the base privilege check should interact
> with the FMAC permission check:
> 1) Similar to DAC, require privilege to always be granted by both
> mechanisms.  This is safer as it means that FMAC cannot escalate
> access beyond what the normal system would have granted, but more
> limiting in functionality.  This is the current situation in Linux,
> although modifications to lift that restriction have been proposed and
> Linux recently has gained another mechanism for assigning privileges
> to programs via file capabilities.
> -or-
> 2) FMAC can optionally override an ordinary privilege denial.  This
> allows FMAC to completely manage privileges if desired.
> 
> I would suggest starting with option (1) but revisiting this issue
> later once we have more experience and have assessed the state of the
> Solaris userland and its dependencies on uid 0 and setuid.  We have
> gradually worked through and addressed a number of such dependencies
> in Linux, but will have to re-assess them in Solaris.

	This seem to be a good initial starting point.  I would point out
	that except for privilege escalation (see privileges(5)) and suid
	0, any dependency on uid 0 is a bug and should be filed and
	corrected.

Gary..


From William.Young at Sun.COM  Wed Apr 16 09:30:34 2008
From: William.Young at Sun.COM (William Young)
Date: Wed, 16 Apr 2008 12:30:34 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <4803E82C.6040305@opensolaris.org>
References: <480291B3.7090602@sun.com> <4803E82C.6040305@opensolaris.org>
Message-ID: <480629AA.3030202@sun.com>

Darren J Moffat wrote:

> For example I've been working with a vendor recently that has a need for 
>   highly controlled channels between zones; some of this can be met 
> using intra-zone ipfilter rules and a mix of shared and exclusive ip 
> stack zones. Not all of the data can be sent over IP ,sometimes it is 
> doors or unix domain sockets.  So controlling which processes in a given 
> zone can be a door client can be a peer to a door server in another zone 
> is needed for them.  I can see value in expressing that policy in a 
> system like Flask rather than having to code the checks into the door 
> servers/clients using door_ucred/getpeerucred.

	I think I have a similar but slightly different view point.  I think 
cross zone doors and network loopback (for the shared stack) should be 
possible but explicit whether or not TX or Flask are in use.

	The ability to obtain a loopback socket reachable in another zone can 
be met with current RBAC privileges ip_config->SO_ALLZONES and allowing 
all-zones loopback interfaces independent of any MAC policy.

	The ability to obtain a global door should be similar.

	TX and Flask should be preventing actions that would have succeeded 
based on their policies not enabling functionality that is otherwise 
non-existent.

	Returning to the door server example, the average server should not 
have to change because it does not explicitly request a global door.  If 
a server does request a global door it needs the privilege to do so then 
it needs to take the a cred's zone in to account if it makes any 
credential specific actions.

	If you want to override the need for awareness then MAC is responsible 
for pre-translating the cred into the equivalent cred in the door 
server's zone.  The safe translation currently requires wiping out the 
uid, various privileges that are a right to act in a specific zone, ... 
  Probably we want the door server to make its own translation for 
anything non-MAC specific according to its own purpose for going global.
	-Will


From sds at tycho.nsa.gov  Wed Apr 16 11:05:40 2008
From: sds at tycho.nsa.gov (Stephen Smalley)
Date: Wed, 16 Apr 2008 14:05:40 -0400
Subject: [fmac-discuss] Integrating FMAC into OpenSolaris
In-Reply-To: <200804150046.m3F0kmKF010050@marduk.eng.sun.com>
References: <200804150046.m3F0kmKF010050@marduk.eng.sun.com>
Message-ID: <1208369140.18883.255.camel@moss-spartans.epoch.ncsc.mil>


On Mon, 2008-04-14 at 17:46 -0700, Gary Winiger wrote:
> > - Audit and System Logging: In the Linux implementation, we started
> > off using the system logging (sysklogd) facility for reporting
> > permission denial messages, and later migrated to using the audit
> > subsystem when it was created for Linux.  We will need to do
> > something similar in Solaris; we might start with system logging if
> > that is easier and then migrate to using audit or we could possibly
> > start using audit from the beginning if that is straightforward to do.
> > We will need to be able to easily feed these denials from the system
> > logs or audit logs into tools for policy development and debugging.
> > We will also eventually want to look at extending the audit facility
> > to include process and object security contexts in its existing audit
> > records and to support filters based on security contexts, as was 
> > also done in Linux.
> 
> 	As the current architect for the Solaris Audit project, let
> 	me extend you a helping hand.  As the FMAC project identifies its
> 	interfaces, both in the kernel and in userland that are security
> 	relevant from a audit perspective, the two projects will need
> 	close cooperation.  All audit events and their associated records
> 	are a necessary part of any Solaris Common Criteria Evaluation
> 	and as is noted in
> 	http://opensolaris.org/os/community/arc/caselog/2003/397/
> 	are obliged to be worked with the Solaris Audit (and sometimes also
> 	with the Solaris Evaluations) project.
> 
> 	That said, Solaris Audit is flexible, extensible, and should be
> 	able to accommodate the FMAC projects needs without much project
> 	specific code.  Please contact the OpenSolaris Audit project:
> 	audit-discuss at opensolaris.org for help early on in determining
> 	the details.
> 
> 	I suspect the FMAC leaders don't need additional information about
> 	audit, but perhaps other's on the fmac-discuss list might be interested
> 	in the Audit Policy:
> 	http://opensolaris.org/os/community/arc/policies/audit-policy/
> 

Thanks, based on your and Darren's comments, we'll try to integrate with
audit from the start.  I've joined the audit-discuss list, and we'll
take the discussion up there to work out the specifics.

-- 
Stephen Smalley
National Security Agency



From sds at tycho.nsa.gov  Wed Apr 16 11:16:22 2008
From: sds at tycho.nsa.gov (Stephen Smalley)
Date: Wed, 16 Apr 2008 14:16:22 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <4803E82C.6040305@opensolaris.org>
References: <480291B3.7090602@sun.com>  <4803E82C.6040305@opensolaris.org>
Message-ID: <1208369782.18883.268.camel@moss-spartans.epoch.ncsc.mil>


On Tue, 2008-04-15 at 00:26 +0100, Darren J Moffat wrote:
> Glenn Faden wrote:
> > There is the related issue of flexibility. Zones provide strong but 
> > coarse separation, and providing flexibility of cross-zone policies is 
> > generally a bad thing. The major premise of the Solaris zone model is 
> > that no process in a non-global zone (even running with all the zone's 
> > privileges) can cause damage to any other zone including the global 
> > zone. In Trusted Extensions we've gone even further to prevent any 
> > communication between processes in different zones, including via the 
> > filesystem or the network.
> 
> On the other hand TX provides controlled channels (via the global zone/ 
> trusted path) between zones and it would be nice in somecases to augment 
> these.
> 
> > One could argue that Flask could be used to provide a more flexible 
> > cross-zone access control, but I think this would be a mistake. In the 
> > SELinux implementation, the security server is called to restrict access 
> > that would otherwise be allowed, but it doesn't weaken the default 
> > (legacy) policy.
> 
> I have a different view on this and I think having an ability to provide 
> a highly controlled cross-zone access control mechanism using Flask 
> would be a bit value.
> 
> For example I've been working with a vendor recently that has a need for 
>   highly controlled channels between zones; some of this can be met 
> using intra-zone ipfilter rules and a mix of shared and exclusive ip 
> stack zones. Not all of the data can be sent over IP ,sometimes it is 
> doors or unix domain sockets.  So controlling which processes in a given 
> zone can be a door client can be a peer to a door server in another zone 
> is needed for them.  I can see value in expressing that policy in a 
> system like Flask rather than having to code the checks into the door 
> servers/clients using door_ucred/getpeerucred.

Thanks for this concrete example to help drive the discussion.  Given
this interest by a vendor in such controls, I'm inclined to take a look
at how to integrate Flask/FMAC with zones sooner.

In Linux, we apply a peer-to-peer check on local socket IPC, the
connectto (stream) or sendto (datagram) permission checks.  I would
expect we could do likewise for door IPC in Solaris, although I'll
confess to not having looked at the doors mechanism at all yet.  Of
course those checks were at process granularity rather than
zone/container granularity, but it wouldn't be hard to support both if
we assign Flask security contexts to zones in Solaris as well as to
processes, likely with an associate check between the zone and process
upon process creation to ensure a relationship between the zone context
and the contexts of any processes within it.  That's all just off the
top of my head though and might prove to be problematic in
implementation.

-- 
Stephen Smalley
National Security Agency



From darrenm at opensolaris.org  Wed Apr 16 12:34:43 2008
From: darrenm at opensolaris.org (Darren J Moffat)
Date: Wed, 16 Apr 2008 20:34:43 +0100
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <480629AA.3030202@sun.com>
References: <480291B3.7090602@sun.com> <4803E82C.6040305@opensolaris.org>
	<480629AA.3030202@sun.com>
Message-ID: <480654D3.9060101@opensolaris.org>

William Young wrote:
> Darren J Moffat wrote:
> 
>> For example I've been working with a vendor recently that has a need 
>> for   highly controlled channels between zones; some of this can be 
>> met using intra-zone ipfilter rules and a mix of shared and exclusive 
>> ip stack zones. Not all of the data can be sent over IP ,sometimes it 
>> is doors or unix domain sockets.  So controlling which processes in a 
>> given zone can be a door client can be a peer to a door server in 
>> another zone is needed for them.  I can see value in expressing that 
>> policy in a system like Flask rather than having to code the checks 
>> into the door servers/clients using door_ucred/getpeerucred.
> 
>     I think I have a similar but slightly different view point.  I think 
> cross zone doors and network loopback (for the shared stack) should be 
> possible but explicit whether or not TX or Flask are in use.

That would be reasonable provided the global zone is involved in the setup.

I was hoping that we could have a mechanism where the global zone is 
just setting up the policy not actually running the door server or 
setting up the door file (descriptor).

>     The ability to obtain a loopback socket reachable in another zone 
> can be met with current RBAC privileges ip_config->SO_ALLZONES and 
> allowing all-zones loopback interfaces independent of any MAC policy.
> 
>     The ability to obtain a global door should be similar.

Not just global zone doors but local zone to different local zone doors 
too - but the default for local zone to different local zone must be 
disabled.

>     TX and Flask should be preventing actions that would have succeeded 
> based on their policies not enabling functionality that is otherwise 
> non-existent.

In fact this is actually what the vendor I'm working with wants.  They 
want to control which zones can't see the doors.  For example a door 
server in zone A with the allowed clients in B an C but zone D can't 
call on the door server in zone A.  In this case the door server is NOT 
in the global zone.


-- 
Darren J Moffat


From john.weeks at sun.com  Wed Apr 16 11:48:59 2008
From: john.weeks at sun.com (John Weeks)
Date: Wed, 16 Apr 2008 11:48:59 -0700
Subject: [fmac-discuss] Integrating FMAC into OpenSolaris
In-Reply-To: <1208369140.18883.255.camel@moss-spartans.epoch.ncsc.mil>
References: <200804150046.m3F0kmKF010050@marduk.eng.sun.com>
	<1208369140.18883.255.camel@moss-spartans.epoch.ncsc.mil>
Message-ID: <48064A1B.4070700@sun.com>

Stephen Smalley wrote:
> On Mon, 2008-04-14 at 17:46 -0700, Gary Winiger wrote:
>>> - Audit and System Logging: In the Linux implementation, we started
>>> off using the system logging (sysklogd) facility for reporting
>>> permission denial messages, and later migrated to using the audit
>>> subsystem when it was created for Linux.  We will need to do
>>> something similar in Solaris; we might start with system logging if
>>> that is easier and then migrate to using audit or we could possibly
>>> start using audit from the beginning if that is straightforward to do.
>>> We will need to be able to easily feed these denials from the system
>>> logs or audit logs into tools for policy development and debugging.
>>> We will also eventually want to look at extending the audit facility
>>> to include process and object security contexts in its existing audit
>>> records and to support filters based on security contexts, as was 
>>> also done in Linux.
>> 	As the current architect for the Solaris Audit project, let
>> 	me extend you a helping hand.  As the FMAC project identifies its
>> 	interfaces, both in the kernel and in userland that are security
>> 	relevant from a audit perspective, the two projects will need
>> 	close cooperation.  All audit events and their associated records
>> 	are a necessary part of any Solaris Common Criteria Evaluation
>> 	and as is noted in
>> 	http://opensolaris.org/os/community/arc/caselog/2003/397/
>> 	are obliged to be worked with the Solaris Audit (and sometimes also
>> 	with the Solaris Evaluations) project.
>>
>> 	That said, Solaris Audit is flexible, extensible, and should be
>> 	able to accommodate the FMAC projects needs without much project
>> 	specific code.  Please contact the OpenSolaris Audit project:
>> 	audit-discuss at opensolaris.org for help early on in determining
>> 	the details.
>>
>> 	I suspect the FMAC leaders don't need additional information about
>> 	audit, but perhaps other's on the fmac-discuss list might be interested
>> 	in the Audit Policy:
>> 	http://opensolaris.org/os/community/arc/policies/audit-policy/
>>
> 
> Thanks, based on your and Darren's comments, we'll try to integrate with
> audit from the start.  I've joined the audit-discuss list, and we'll
> take the discussion up there to work out the specifics.

I completely agree as well. We'll work with Gary and the audit list to determine 
how we can make this happen.

> 


From john.weeks at sun.com  Wed Apr 16 12:14:30 2008
From: john.weeks at sun.com (John Weeks)
Date: Wed, 16 Apr 2008 12:14:30 -0700
Subject: [fmac-discuss] List working again
Message-ID: <48065016.1040006@sun.com>

It looks like the problem we were encountering has been resolved and Mailman has 
caught up.

Apologies for the inconvenience.

-John


From Jarrett.Lu at Sun.COM  Wed Apr 16 12:24:34 2008
From: Jarrett.Lu at Sun.COM (Jarrett Lu)
Date: Wed, 16 Apr 2008 12:24:34 -0700
Subject: [fmac-discuss]  Zones and Flask
Message-ID: <48065272.200@sun.com>

Stephen Smalley wrote:

> - Trusted Extensions (TX): As TX is implemented via labeled zones, I
> expect TX and FMAC to initially be orthogonal and complementary to one
> another as with zones.  Providing finer-grained isolation within a
> zone, e.g. to support huge numbers of discrete categories without
> needing a separate zone for each one, would be an interesting area to
> investigate.  We will definitely want to enable FMAC to leverage and
> use TX facilities such as labeled networking (to convey security
> contexts rather than just MLS labels) even when TX is not enabled.

Today, TX networking doesn't have much more capability beyond passing 
MLS labels. With current networking protocols, an out of band communication
is needed to pass security context. One possibility is using IPsec/IKE
as done SELinux. This may not be ideal as it forces people to use IPsec,
and IPsec SA may not be the right granularity. Older versions of Trusted
Solaris supported protocols like TSIX which is capable of passing richer
security info. We abandoned support of TSIX (and other label protocols)
in TX as they create major problems in coexisting with label unaware 
systems, among other reasons. Given the increasing popularity of Flask 
technology and the number of implementations out there, maybe it's time 
to think of a networking protocol which enables efficient exchange of 
security info (e.g. security context, privileges, etc.) as well as 
improving interoperability.


Jarrett




From William.Young at Sun.COM  Thu Apr 17 09:11:12 2008
From: William.Young at Sun.COM (Will Young)
Date: Thu, 17 Apr 2008 12:11:12 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <480654D3.9060101@opensolaris.org>
References: <480291B3.7090602@sun.com> <4803E82C.6040305@opensolaris.org>
	<480629AA.3030202@sun.com> <480654D3.9060101@opensolaris.org>
Message-ID: <480776A0.7030203@sun.com>

Darren J Moffat wrote:
> William Young wrote:
>   
>> Darren J Moffat wrote:
>>
>>     
>>> For example I've been working with a vendor recently that has a need 
>>> for   highly controlled channels between zones; some of this can be 
>>> met using intra-zone ipfilter rules and a mix of shared and exclusive 
>>> ip stack zones. Not all of the data can be sent over IP ,sometimes it 
>>> is doors or unix domain sockets.  So controlling which processes in a 
>>> given zone can be a door client can be a peer to a door server in 
>>> another zone is needed for them.  I can see value in expressing that 
>>> policy in a system like Flask rather than having to code the checks 
>>> into the door servers/clients using door_ucred/getpeerucred.
>>>       
>>     I think I have a similar but slightly different view point.  I think 
>> cross zone doors and network loopback (for the shared stack) should be 
>> possible but explicit whether or not TX or Flask are in use.
>>     
>
> That would be reasonable provided the global zone is involved in the setup.
>
> I was hoping that we could have a mechanism where the global zone is 
> just setting up the policy not actually running the door server or 
> setting up the door file (descriptor).
>
>   
>>     The ability to obtain a loopback socket reachable in another zone 
>> can be met with current RBAC privileges ip_config->SO_ALLZONES and 
>> allowing all-zones loopback interfaces independent of any MAC policy.
>>
>>     The ability to obtain a global door should be similar.
>>     
>
> Not just global zone doors but local zone to different local zone doors 
> too - but the default for local zone to different local zone must be 
> disabled.
>   
By removing the privilege from the default zone limit set.
>   
>>     TX and Flask should be preventing actions that would have succeeded 
>> based on their policies not enabling functionality that is otherwise 
>> non-existent.
>>     
>
> In fact this is actually what the vendor I'm working with wants.  They 
> want to control which zones can't see the doors.  For example a door 
> server in zone A with the allowed clients in B an C but zone D can't 
> call on the door server in zone A.  In this case the door server is NOT 
> in the global zone.
>   
    The only thing I see as special about the global zone is that it has 
the full privilege set.  In terms of some clients seeing a door and some 
not rather than the door server refusing to act, I think this is where 
MAC comes in.  In TX a door should have a label range, etc. This is 
already handled in the more complete networking implementation by 
restricting the ip the server binds to.
    -Will



From sds at tycho.nsa.gov  Fri Apr 18 07:51:15 2008
From: sds at tycho.nsa.gov (Stephen Smalley)
Date: Fri, 18 Apr 2008 10:51:15 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <48065272.200@sun.com>
References: <48065272.200@sun.com>
Message-ID: <1208530275.18883.495.camel@moss-spartans.epoch.ncsc.mil>


On Wed, 2008-04-16 at 12:24 -0700, Jarrett Lu wrote:
> Stephen Smalley wrote:
> 
> > - Trusted Extensions (TX): As TX is implemented via labeled zones, I
> > expect TX and FMAC to initially be orthogonal and complementary to one
> > another as with zones.  Providing finer-grained isolation within a
> > zone, e.g. to support huge numbers of discrete categories without
> > needing a separate zone for each one, would be an interesting area to
> > investigate.  We will definitely want to enable FMAC to leverage and
> > use TX facilities such as labeled networking (to convey security
> > contexts rather than just MLS labels) even when TX is not enabled.
> 
> Today, TX networking doesn't have much more capability beyond passing 
> MLS labels. With current networking protocols, an out of band communication
> is needed to pass security context. One possibility is using IPsec/IKE
> as done SELinux. This may not be ideal as it forces people to use IPsec,
> and IPsec SA may not be the right granularity.

Granularity was a problem in the initial labeled IPSEC implementation in
Linux, but that was later resolved by further change to it.

At present in Linux, we can convey the full security context via labeled
IPSEC (implicitly based on SA) or only the MLS portion of the security
context via NetLabel/CIPSO (with the rest of the context inheriting a
default set of values).

In earlier versions of SELinux before it was mainlined, there was an
experimental implementation of CIPSO/FIPS188 options along with an
out-of-band security context mapping protocol (SCMP) that could be used
to convey the full security context, called SelOpt.  That was described
by:
http://www.intercode.com.au/jmorris/selopt/old/selopt-overview.txt
http://www.intercode.com.au/jmorris/selopt/old/selinux-options.txt
http://www.intercode.com.au/jmorris/selopt/old/scmp-draft.txt

The NetLabel/CIPSO support in mainline Linux might eventually support
something similar.

>  Older versions of Trusted
> Solaris supported protocols like TSIX which is capable of passing richer
> security info. We abandoned support of TSIX (and other label protocols)
> in TX as they create major problems in coexisting with label unaware 
> systems, among other reasons. Given the increasing popularity of Flask 
> technology and the number of implementations out there, maybe it's time 
> to think of a networking protocol which enables efficient exchange of 
> security info (e.g. security context, privileges, etc.) as well as 
> improving interoperability.

Yes, I think that would be helpful.

-- 
Stephen Smalley
National Security Agency



From paul.moore at hp.com  Fri Apr 18 12:18:37 2008
From: paul.moore at hp.com (Paul Moore)
Date: Fri, 18 Apr 2008 15:18:37 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <1208530275.18883.495.camel@moss-spartans.epoch.ncsc.mil>
References: <48065272.200@sun.com>
	<1208530275.18883.495.camel@moss-spartans.epoch.ncsc.mil>
Message-ID: <200804181518.37304.paul.moore@hp.com>

On Friday 18 April 2008 10:51:15 am Stephen Smalley wrote:
> On Wed, 2008-04-16 at 12:24 -0700, Jarrett Lu wrote:
> > Stephen Smalley wrote:
> > > - Trusted Extensions (TX): As TX is implemented via labeled
> > > zones, I expect TX and FMAC to initially be orthogonal and
> > > complementary to one another as with zones.  Providing
> > > finer-grained isolation within a zone, e.g. to support huge
> > > numbers of discrete categories without needing a separate zone
> > > for each one, would be an interesting area to investigate.  We
> > > will definitely want to enable FMAC to leverage and use TX
> > > facilities such as labeled networking (to convey security
> > > contexts rather than just MLS labels) even when TX is not
> > > enabled.
> >
> > Today, TX networking doesn't have much more capability beyond
> > passing MLS labels. With current networking protocols, an out of
> > band communication is needed to pass security context. One
> > possibility is using IPsec/IKE as done SELinux. This may not be
> > ideal as it forces people to use IPsec, and IPsec SA may not be the
> > right granularity.
>
> Granularity was a problem in the initial labeled IPSEC implementation
> in Linux, but that was later resolved by further change to it.

I believe there will always be some inherent difficulties in using IPsec 
to convey security labels.  Scalability to large numbers of labels and 
IPsec policy rules being one of the main issues.  The other being a 
general lack of flexibility caused by requiring the use of IPsec to 
convey label information.

> At present in Linux, we can convey the full security context via
> labeled IPSEC (implicitly based on SA) or only the MLS portion of the
> security context via NetLabel/CIPSO (with the rest of the context
> inheriting a default set of values).
>
> In earlier versions of SELinux before it was mainlined, there was an
> experimental implementation of CIPSO/FIPS188 options along with an
> out-of-band security context mapping protocol (SCMP) that could be
> used to convey the full security context, called SelOpt.  That was
> described by:
> http://www.intercode.com.au/jmorris/selopt/old/selopt-overview.txt
> http://www.intercode.com.au/jmorris/selopt/old/selinux-options.txt
> http://www.intercode.com.au/jmorris/selopt/old/scmp-draft.txt
>
> The NetLabel/CIPSO support in mainline Linux might eventually support
> something similar.

This is indeed planned and is one way I hope to achieve support for the 
full security label on Linux/SELinux.  Using labeled IPsec in this case 
is particularly painful.

> >  Older versions of Trusted
> > Solaris supported protocols like TSIX which is capable of passing
> > richer security info. We abandoned support of TSIX (and other label
> > protocols) in TX as they create major problems in coexisting with
> > label unaware systems, among other reasons. Given the increasing
> > popularity of Flask technology and the number of implementations
> > out there, maybe it's time to think of a networking protocol which
> > enables efficient exchange of security info (e.g. security context,
> > privileges, etc.) as well as improving interoperability.
>
> Yes, I think that would be helpful.

I _strongly_ agree.  I also believe that any new labeling protocol needs 
to be developed in conjunction with the IETF with the goal of achieving 
at least an informational RFC.  Without IETF approval it will be 
difficult/impossible for us to get the necessary IANA reserved numbers 
which are important for interoperability with label unaware systems as 
Jarret points out.

Unfortunately, labeling protocols seem to have a bit of a rocky history 
within the IETF but the good news is that there is a new labeling 
protocol in progress, CALIPSO, which aims to provide MLS labeling for 
IPv6.  I've talked with the author about extending it to support more 
generic labeling and while he is open to the idea he would prefer to 
see generic support added at a later date.  He is concerned about the 
acceptability of a labeling protocol in general and feels a simpler, 
MLS-only protocol has the best chance.  If CALIPSO succeeds it should 
open the door for extended labeling protocols (both IPv6 and IPv4 I 
hope).

I'll try to check on the current status of CALIPSO and post an update 
when I know more.

-- 
paul moore
linux @ hp


From sommerfeld at sun.com  Fri Apr 18 13:15:03 2008
From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Fri, 18 Apr 2008 13:15:03 -0700
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <200804181518.37304.paul.moore@hp.com>
References: <48065272.200@sun.com>
	<1208530275.18883.495.camel@moss-spartans.epoch.ncsc.mil>
	<200804181518.37304.paul.moore@hp.com>
Message-ID: <1208549703.2040.4.camel@localhost>


On Fri, 2008-04-18 at 15:18 -0400, Paul Moore wrote:
> I believe there will always be some inherent difficulties in using IPsec 
> to convey security labels.  Scalability to large numbers of labels and 
> IPsec policy rules being one of the main issues. 

large numbers of labels just means large numbers of SA's; given adequate
physical memory and a little tuning, solaris can handle millions of SA's
and millions of policy rules.  actually managing that many policy rules
on the other hand is going to be interesting (and is an area I'll be
looking at once our initial labeled ipsec is integrated).

having labels, etc., as SA attributes means no additional per-packet
overhead on the wire.  

					- Bill



From alan.duboff at sun.com  Fri Apr 18 14:05:26 2008
From: alan.duboff at sun.com (Alan DuBoff)
Date: Fri, 18 Apr 2008 14:05:26 -0700 (PDT)
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <1208549703.2040.4.camel@localhost>
References: <48065272.200@sun.com>
	<1208530275.18883.495.camel@moss-spartans.epoch.ncsc.mil>
	<200804181518.37304.paul.moore@hp.com>
	<1208549703.2040.4.camel@localhost>
Message-ID: <Pine.GSO.4.64.0804181356560.28025@eagle>

On Fri, 18 Apr 2008, Bill Sommerfeld wrote:

> large numbers of labels just means large numbers of SA's; given adequate
> physical memory and a little tuning, solaris can handle millions of SA's
> and millions of policy rules.  actually managing that many policy rules
> on the other hand is going to be interesting (and is an area I'll be
> looking at once our initial labeled ipsec is integrated).

Bill,

I would like to hear what type of ideas you might have for policy 
management.

I have talked to John Weeks about some ideas I've had in regards to 
creating a management GUI that would allow to perform such a task, and one 
that would allow for the management of TX along with FMAC, this is also an 
area that has been lacking in TX for way too long. Maybe this is an 
opportunity to come up with such a tool that could kill two birds with one 
stone.

It can be argued that the lack of decent management tools are one of the 
biggist blocks to adoption, and much can be done. The SELinux community is 
doing better than OpenSolaris in that regard, and they do have some 
solutions being worked on today. Some of it in Java, so concepts can be 
adapted/ported on OpenSolaris possibly, if we like. Managing policies 
should be one of the primary focuses in this community, IMHO, aside from 
the functionality and implimentation standpoint of course.

What type of ideas have you been thinking about, of have you had time to 
give it any thought yet?

--

Alan DuBoff - Solaris x86 IHV/OEM Group


From Jarrett.Lu at Sun.COM  Fri Apr 18 15:04:13 2008
From: Jarrett.Lu at Sun.COM (Jarrett Lu)
Date: Fri, 18 Apr 2008 15:04:13 -0700
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <200804181518.37304.paul.moore@hp.com>
References: <48065272.200@sun.com>
	<1208530275.18883.495.camel@moss-spartans.epoch.ncsc.mil>
	<200804181518.37304.paul.moore@hp.com>
Message-ID: <48091ADD.6050601@sun.com>

Paul Moore wrote:
> On Friday 18 April 2008 10:51:15 am Stephen Smalley wrote:
>   
>> On Wed, 2008-04-16 at 12:24 -0700, Jarrett Lu wrote:
>>     
>>>  Older versions of Trusted
>>> Solaris supported protocols like TSIX which is capable of passing
>>> richer security info. We abandoned support of TSIX (and other label
>>> protocols) in TX as they create major problems in coexisting with
>>> label unaware systems, among other reasons. Given the increasing
>>> popularity of Flask technology and the number of implementations
>>> out there, maybe it's time to think of a networking protocol which
>>> enables efficient exchange of security info (e.g. security context,
>>> privileges, etc.) as well as improving interoperability.
>>>       
>> Yes, I think that would be helpful.
>>     
>
> I _strongly_ agree.  I also believe that any new labeling protocol needs 
> to be developed in conjunction with the IETF with the goal of achieving 
> at least an informational RFC.  Without IETF approval it will be 
> difficult/impossible for us to get the necessary IANA reserved numbers 
> which are important for interoperability with label unaware systems as 
> Jarret points out.
>   

I agree we should start at IETF and try hard this time. One of the main 
objection
to CIPSO standards from IETF community is cleartext label and the assumption
of a trusted physical network. With introduction of ongoing work on 
labeled IPsec
and labeled NFSv4, and future work on labeled routing and IP multicast, 
I hope
IETF realizes the activities and value in the labeled networking space. 
I am hopeful
we'll have better luck than the CIPSO standards effort.

> Unfortunately, labeling protocols seem to have a bit of a rocky history 
> within the IETF but the good news is that there is a new labeling 
> protocol in progress, CALIPSO, which aims to provide MLS labeling for 
> IPv6.  I've talked with the author about extending it to support more 
> generic labeling and while he is open to the idea he would prefer to 
> see generic support added at a later date.  He is concerned about the 
> acceptability of a labeling protocol in general and feels a simpler, 
> MLS-only protocol has the best chance.  If CALIPSO succeeds it should 
> open the door for extended labeling protocols (both IPv6 and IPv4 I 
> hope).
>   

I'm aware of the CALIPSO effort and am helping to make it successful.

> I'll try to check on the current status of CALIPSO and post an update 
> when I know more.
>
>   

Thanks.

Jarrett




From sommerfeld at sun.com  Fri Apr 18 15:44:50 2008
From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Fri, 18 Apr 2008 15:44:50 -0700
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <Pine.GSO.4.64.0804181356560.28025@eagle>
References: <48065272.200@sun.com>
	<1208530275.18883.495.camel@moss-spartans.epoch.ncsc.mil>
	<200804181518.37304.paul.moore@hp.com>
	<1208549703.2040.4.camel@localhost>
	<Pine.GSO.4.64.0804181356560.28025@eagle>
Message-ID: <1208558690.2040.24.camel@localhost>


On Fri, 2008-04-18 at 14:05 -0700, Alan DuBoff wrote:
> I would like to hear what type of ideas you might have for policy 
> management.

I have a lot of what I'd characterize as half-baked ideas that I need to
spend more time on once my current project is further along.

There are a bunch of avenues I think are worth exploring:

 1) extending the tn*db databases (especially the templates) with a
mechanism to also distribute IPsec SPD and IKE PAD rules.  

 2) decoupling policy from ip addresses, by instead tying it to
attributes associated with node and/or user authentication credentials.
(This would potentially greatly reduce the number of SPD rules, leaving
you with much less to manage).  

 3) specialized higher-level tools to generate the configuration for
specific combinations of systems (for instance, a fully-connected mesh
of security gateways).  






From William.Young at Sun.COM  Fri Apr 18 17:17:28 2008
From: William.Young at Sun.COM (Will Young)
Date: Fri, 18 Apr 2008 20:17:28 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <48091ADD.6050601@sun.com>
References: <48065272.200@sun.com>
	<1208530275.18883.495.camel@moss-spartans.epoch.ncsc.mil>
	<200804181518.37304.paul.moore@hp.com> <48091ADD.6050601@sun.com>
Message-ID: <48093A18.6030508@sun.com>

Jarrett Lu wrote:
> Paul Moore wrote:
>   
>> On Friday 18 April 2008 10:51:15 am Stephen Smalley wrote:
>>   
>>     
>>> On Wed, 2008-04-16 at 12:24 -0700, Jarrett Lu wrote:
>>>     
>>>       
>>>>  Older versions of Trusted
>>>> Solaris supported protocols like TSIX which is capable of passing
>>>> richer security info. We abandoned support of TSIX (and other label
>>>> protocols) in TX as they create major problems in coexisting with
>>>> label unaware systems, among other reasons. Given the increasing
>>>> popularity of Flask technology and the number of implementations
>>>> out there, maybe it's time to think of a networking protocol which
>>>> enables efficient exchange of security info (e.g. security context,
>>>> privileges, etc.) as well as improving interoperability.
>>>>       
>>>>         
>>> Yes, I think that would be helpful.
>>>     
>>>       
>> I _strongly_ agree.  I also believe that any new labeling protocol needs 
>> to be developed in conjunction with the IETF with the goal of achieving 
>> at least an informational RFC.  Without IETF approval it will be 
>> difficult/impossible for us to get the necessary IANA reserved numbers 
>> which are important for interoperability with label unaware systems as 
>> Jarret points out.
>>   
>>     
>
> I agree we should start at IETF and try hard this time. One of the main 
> objection
> to CIPSO standards from IETF community is cleartext label and the assumption
> of a trusted physical network. With introduction of ongoing work on 
> labeled IPsec
> and labeled NFSv4, and future work on labeled routing and IP multicast, 
> I hope
> IETF realizes the activities and value in the labeled networking space. 
> I am hopeful
> we'll have better luck than the CIPSO standards effort.
>   
    I'm having trouble seeing the value of separating integrity and 
labeling.  For a middle system to  correctly examine a label it needs to 
have the ability to verify integrity.  If you are using IPsec for 
integrity and want an intermediary to participate then you would have to 
be able to have an SA at the label for the tunnel to the intermediary 
and an SA for the peer for transport integrity.

    If the system requires complete paranoia each party could transmit 
the intended transport SPIs and their label and the gateway could drop 
any mismatches..  Explicit labels could eliminate that stage, but I 
don't think that warrants the pain/cost of a variable size next hop ip 
option.

    Perhaps making CALIPSO a destination option would be a better stop 
gap measure.  This would imply one could do drop by label in firewalls 
but not route by label which I don't think will ever be valid in terms 
of integrity at the IP layer.
    Labeled gateways would then want to setup auto-tunnels that have a 
destination option on the outer header for unlabeled packets and could 
at some later point have integrity..
    -Will


From paul.moore at hp.com  Sun Apr 20 06:48:45 2008
From: paul.moore at hp.com (Paul Moore)
Date: Sun, 20 Apr 2008 09:48:45 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <1208549703.2040.4.camel@localhost>
References: <48065272.200@sun.com> <200804181518.37304.paul.moore@hp.com>
	<1208549703.2040.4.camel@localhost>
Message-ID: <200804200948.46109.paul.moore@hp.com>

On Friday 18 April 2008 4:15:03 pm Bill Sommerfeld wrote:
> On Fri, 2008-04-18 at 15:18 -0400, Paul Moore wrote:
> > I believe there will always be some inherent difficulties in using
> > IPsec to convey security labels.  Scalability to large numbers of
> > labels and IPsec policy rules being one of the main issues.
>
> large numbers of labels just means large numbers of SA's; given
> adequate physical memory and a little tuning, solaris can handle
> millions of SA's and millions of policy rules.

While hardware vendors always love the throw-more-hardware-at-it 
solution, I was hoping for something a bit more elegant for platforms 
which aren't able to scale to large numbers of SAs.  I agree that for a 
modestly sized server a million SAs should not be a major problem, I 
suspect it would be an issue for smaller systems.

However, even if we step back from memory usage for a moment I believe 
there is still a concern with the overhead of re-keying that many SAs.

> actually managing 
> that many policy rules on the other hand is going to be interesting
> (and is an area I'll be looking at once our initial labeled ipsec is
> integrated).

Agreed, management seems like it is always an issue.  Also, just so I'm 
caught up, the labeled IPsec you are talking about is still a strictly 
MLS implementation correct?

> having labels, etc., as SA attributes means no additional per-packet
> overhead on the wire.

This is always an interesting argument that I've thought about quite a 
bit, and I'm not certain there is ever going to be a "right" answer.  
The problem goes back to the core issue that not all users have a need 
for IPsec since they already trust their physical network link.  I 
don't have much in the way of detail here because these users typically 
aren't interested in sharing those details, however, they have made it 
clear that IPsec is not a requirement as they have other mechanisms in 
place.  In this case labeled IPsec imposes a significant per-packet 
overhead, perhaps the number of bits consumed by the IP headers is the 
same as a labeling-only protocol but the performance overhead 
(throughput, latency, and scalability) of labeled IPsec is dramatic.

A labeling-only protocol provides so much more flexibility for security 
administrators to tailor the system to their own environment.  For 
those that have trust in their network, or bump-in-the-wire encryptors, 
they don't have to deal with the added overhead and complexity of 
labeled IPsec.  However, administrators who do not have the required 
level of trust can use a labeling-only protocol in conjunction with 
host based IPsec where I suspect the added overhead caused by the 
labeling protocol will be minor compared to the IPsec overhead.

It is also worth noting that host-based IPsec offload hardware is 
probably ill-suited for labeled IPsec.  It has been a while since I've 
looked at what is available but last I looked most of the boards that 
were worthwhile wanted to maintain SA state and apply IPsec selectors 
to traffic on the board; this would be problematic for a labeled IPsec 
implementation.

-- 
paul moore
linux @ hp


From paul.moore at hp.com  Sun Apr 20 06:55:22 2008
From: paul.moore at hp.com (Paul Moore)
Date: Sun, 20 Apr 2008 09:55:22 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <48091ADD.6050601@sun.com>
References: <48065272.200@sun.com> <200804181518.37304.paul.moore@hp.com>
	<48091ADD.6050601@sun.com>
Message-ID: <200804200955.22591.paul.moore@hp.com>

On Friday 18 April 2008 6:04:13 pm Jarrett Lu wrote:
> Paul Moore wrote:
> > On Friday 18 April 2008 10:51:15 am Stephen Smalley wrote:
> >> On Wed, 2008-04-16 at 12:24 -0700, Jarrett Lu wrote:
> >>>  Older versions of Trusted
> >>> Solaris supported protocols like TSIX which is capable of passing
> >>> richer security info. We abandoned support of TSIX (and other
> >>> label protocols) in TX as they create major problems in
> >>> coexisting with label unaware systems, among other reasons. Given
> >>> the increasing popularity of Flask technology and the number of
> >>> implementations out there, maybe it's time to think of a
> >>> networking protocol which enables efficient exchange of security
> >>> info (e.g. security context, privileges, etc.) as well as
> >>> improving interoperability.
> >>
> >> Yes, I think that would be helpful.
> >
> > I _strongly_ agree.  I also believe that any new labeling protocol
> > needs to be developed in conjunction with the IETF with the goal of
> > achieving at least an informational RFC.  Without IETF approval it
> > will be difficult/impossible for us to get the necessary IANA
> > reserved numbers which are important for interoperability with
> > label unaware systems as Jarret points out.
>
> I agree we should start at IETF and try hard this time. One of the
> main objection
> to CIPSO standards from IETF community is cleartext label and the
> assumption of a trusted physical network. With introduction of
> ongoing work on labeled IPsec
> and labeled NFSv4, and future work on labeled routing and IP
> multicast, I hope
> IETF realizes the activities and value in the labeled networking
> space. I am hopeful
> we'll have better luck than the CIPSO standards effort.

So do I.  I've also gathered that another area of concern regarding 
CIPSO was its option within an option format (the CIPSO tag concept) 
which made it difficult for the intermediate hop vendors to parse 
quickly.

> I'm aware of the CALIPSO effort and am helping to make it successful.

Great, I'm glad to hear that.  I spoke with Randall and he is currently 
on working through comments/edits from the last draft.  If CALIPSO does 
make its way through the IETF I'm certain we will be implementing it on 
Linux/SELinux.  If you end up implementing it on OpenSolaris hopefully 
we can get together and have a small bakeoff to make sure the two 
systems can interop.

-- 
paul moore
linux @ hp


From paul.moore at hp.com  Sun Apr 20 07:07:48 2008
From: paul.moore at hp.com (Paul Moore)
Date: Sun, 20 Apr 2008 10:07:48 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <48093A18.6030508@sun.com>
References: <48065272.200@sun.com> <48091ADD.6050601@sun.com>
	<48093A18.6030508@sun.com>
Message-ID: <200804201007.48828.paul.moore@hp.com>

On Friday 18 April 2008 8:17:28 pm Will Young wrote:
>     I'm having trouble seeing the value of separating integrity and
> labeling.  For a middle system to  correctly examine a label it needs
> to have the ability to verify integrity.  If you are using IPsec for
> integrity and want an intermediary to participate then you would have
> to be able to have an SA at the label for the tunnel to the
> intermediary and an SA for the peer for transport integrity.
>
>     If the system requires complete paranoia each party could
> transmit the intended transport SPIs and their label and the gateway
> could drop any mismatches..  Explicit labels could eliminate that
> stage, but I don't think that warrants the pain/cost of a variable
> size next hop ip option.

I think the above two paragraphs demonstrate how difficult it is for an 
intermediate hop to "see" the security label of a labeled IPsec packet.  
Essentially you either have to make the intermediate hop an IPsec 
endpoint or develop an out of band protocol to notify the node of the 
label/SPI paring.

The first option concerns me because it requires extra processing at the 
intermediate node where processing and memory is most likely limited 
(see my earlier email with Bill Sommerfeld regarding scalability).  The 
second option (aside from synchronization and management issues) isn't 
viable for several users who want to be able to passively audit network 
security labels; I've had at least one user comment that because of 
this reason he can't use labeled IPsec.

>     Perhaps making CALIPSO a destination option would be a better
> stop gap measure.  This would imply one could do drop by label in
> firewalls but not route by label which I don't think will ever be
> valid in terms of integrity at the IP layer.
>     Labeled gateways would then want to setup auto-tunnels that have
> a destination option on the outer header for unlabeled packets and
> could at some later point have integrity..

While I like the idea of having the labeling protocol as a hop-by-hop 
option, if that isn't acceptable then a destination option is better 
than nothing.

-- 
paul moore
linux @ hp


From method at manicmethod.com  Sun Apr 20 10:15:01 2008
From: method at manicmethod.com (Joshua Brindle)
Date: Sun, 20 Apr 2008 13:15:01 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <1208558690.2040.24.camel@localhost>
References: <48065272.200@sun.com>	<1208530275.18883.495.camel@moss-spartans.epoch.ncsc.mil>	<200804181518.37304.paul.moore@hp.com>	<1208549703.2040.4.camel@localhost>	<Pine.GSO.4.64.0804181356560.28025@eagle>
	<1208558690.2040.24.camel@localhost>
Message-ID: <480B7A15.5070203@manicmethod.com>

Bill Sommerfeld wrote:
> On Fri, 2008-04-18 at 14:05 -0700, Alan DuBoff wrote:
>   
>> I would like to hear what type of ideas you might have for policy 
>> management.
>>     
>
> I have a lot of what I'd characterize as half-baked ideas that I need to
> spend more time on once my current project is further along.
>
> There are a bunch of avenues I think are worth exploring:
>
>  1) extending the tn*db databases (especially the templates) with a
> mechanism to also distribute IPsec SPD and IKE PAD rules.  
>
>  2) decoupling policy from ip addresses, by instead tying it to
> attributes associated with node and/or user authentication credentials.
> (This would potentially greatly reduce the number of SPD rules, leaving
> you with much less to manage).  
>
>  3) specialized higher-level tools to generate the configuration for
> specific combinations of systems (for instance, a fully-connected mesh
> of security gateways).  
>   

A while back I worked on a proof of concept to use racoon with a 
translation system to only set up SA's selinux contexts that were 
relevant to the policy on both sides. Meaning instead of having 100 
different SA's because a workstation has 100 domains connecting to a 
server you could limit it to the contexts that the server cared about. 
Something like this could be used in conjunction with policy management 
to keep the number of SA's in check and keep the complexity of the 
inter-system policies down.




From sommerfeld at sun.com  Sun Apr 20 11:31:48 2008
From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Sun, 20 Apr 2008 11:31:48 -0700
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <480B7A15.5070203@manicmethod.com>
References: <48065272.200@sun.com>
	<1208530275.18883.495.camel@moss-spartans.epoch.ncsc.mil>
	<200804181518.37304.paul.moore@hp.com>
	<1208549703.2040.4.camel@localhost>
	<Pine.GSO.4.64.0804181356560.28025@eagle>
	<1208558690.2040.24.camel@localhost> <480B7A15.5070203@manicmethod.com>
Message-ID: <1208716308.1804.3.camel@localhost>


On Sun, 2008-04-20 at 13:15 -0400, Joshua Brindle wrote:

> A while back I worked on a proof of concept to use racoon with a 
> translation system to only set up SA's selinux contexts that were 
> relevant to the policy on both sides. 

The existing solaris labeled IPsec prototype does better than that by
only creating SA's when a node has something to send and there isn't an
appropriate SA already -- it falls out of our approach (within the
baseline Solaris IPsec) of only creating SA's when traffic warrants it
rather than creating all possibly useful SA's.

						- Bill



From method at manicmethod.com  Sun Apr 20 12:30:11 2008
From: method at manicmethod.com (Joshua Brindle)
Date: Sun, 20 Apr 2008 15:30:11 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <1208716308.1804.3.camel@localhost>
References: <48065272.200@sun.com>	
	<1208530275.18883.495.camel@moss-spartans.epoch.ncsc.mil>	
	<200804181518.37304.paul.moore@hp.com>
	<1208549703.2040.4.camel@localhost>	
	<Pine.GSO.4.64.0804181356560.28025@eagle>	
	<1208558690.2040.24.camel@localhost>
	<480B7A15.5070203@manicmethod.com>
	<1208716308.1804.3.camel@localhost>
Message-ID: <480B99C3.5060109@manicmethod.com>

Bill Sommerfeld wrote:
> On Sun, 2008-04-20 at 13:15 -0400, Joshua Brindle wrote:
>
>   
>> A while back I worked on a proof of concept to use racoon with a 
>> translation system to only set up SA's selinux contexts that were 
>> relevant to the policy on both sides. 
>>     
>
> The existing solaris labeled IPsec prototype does better than that by
> only creating SA's when a node has something to send and there isn't an
> appropriate SA already -- it falls out of our approach (within the
> baseline Solaris IPsec) of only creating SA's when traffic warrants it
> rather than creating all possibly useful SA's.
>
>   

Linux does that as well. I just wanted to point out that there are ways 
of handling labeled networking that allow even fewer SA's by collapsing 
eg., domain1, domain2 and domain3 into a single label when all three are 
talking to the server. If the server policy has no need to differentiate 
the three domains then it is simply wasted resources to have SA's for 
all three.

Whether or not anyone eventually uses something like this I just wanted 
to throw it out there so it was a known way of handling some of the SA 
explosion.



From William.Young at Sun.COM  Mon Apr 21 14:11:30 2008
From: William.Young at Sun.COM (Will Young)
Date: Mon, 21 Apr 2008 17:11:30 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <200804201007.48828.paul.moore@hp.com>
References: <48065272.200@sun.com> <48091ADD.6050601@sun.com>
	<48093A18.6030508@sun.com> <200804201007.48828.paul.moore@hp.com>
Message-ID: <480D0302.8080402@sun.com>

Paul Moore wrote:
> On Friday 18 April 2008 8:17:28 pm Will Young wrote:
>   
>>     I'm having trouble seeing the value of separating integrity and
>> labeling.  For a middle system to  correctly examine a label it needs
>> to have the ability to verify integrity.  If you are using IPsec for
>> integrity and want an intermediary to participate then you would have
>> to be able to have an SA at the label for the tunnel to the
>> intermediary and an SA for the peer for transport integrity.
>>
>>     If the system requires complete paranoia each party could
>> transmit the intended transport SPIs and their label and the gateway
>> could drop any mismatches..  Explicit labels could eliminate that
>> stage, but I don't think that warrants the pain/cost of a variable
>> size next hop ip option.
>>     
>
> I think the above two paragraphs demonstrate how difficult it is for an 
> intermediate hop to "see" the security label of a labeled IPsec packet.  
> Essentially you either have to make the intermediate hop an IPsec 
> endpoint or develop an out of band protocol to notify the node of the 
> label/SPI paring.
>   
    But it isn't so much difficult as wrong.  IPsec based labeling gives 
you integrity and privacy between the end points.  If you want a 
hop-by-hop secured labeling protocol you want to extend vlans to support 
complex labels or mimic a secure link layer with a secure tunnel.  The 
mix of labeled and unlabeled systems/routers interchanging labeled and 
unlabeled packets and a few routers here and there filtering and/or 
inserting labels is a disaster that looks like someone tried to design a 
network for source routing and then add a security policy to limit it.

    For hop-by-hop MAC I think it makes more sense to have labeling at 
the link layer and talk to it on its terms, i.e. by having MLS routers 
and hosts explicit access to interfaces on a labeled vlan tagging layer 
which is beneath the awareness of untrusted hosts.
> The first option concerns me because it requires extra processing at the 
> intermediate node where processing and memory is most likely limited 
> (see my earlier email with Bill Sommerfeld regarding scalability).  The 
> second option (aside from synchronization and management issues) isn't 
> viable for several users who want to be able to passively audit network 
> security labels; I've had at least one user comment that because of 
> this reason he can't use labeled IPsec.
>   

    Security through passive network auditing alone is security by 
obscurity.  The systems can ultimately send any data they want labeled 
as whatever is allowed.  The only way to know they are not is to have 
system auditing.  Such system auditing should be secure and remote and 
could be used to correctly draw the conclusions one thinks one is 
getting from network monitoring.  Where the routers could help is in 
providing additional audit data.
>>     Perhaps making CALIPSO a destination option would be a better
>> stop gap measure.  This would imply one could do drop by label in
>> firewalls but not route by label which I don't think will ever be
>> valid in terms of integrity at the IP layer.
>>     Labeled gateways would then want to setup auto-tunnels that have
>> a destination option on the outer header for unlabeled packets and
>> could at some later point have integrity..
>>     
>
> While I like the idea of having the labeling protocol as a hop-by-hop 
> option, if that isn't acceptable then a destination option is better 
> than nothing.
>   
    If there is no integrity and every host on the network is given a 
crack at forging one, what are you really getting from the hop-by-hop?  
I see an administrative nightmare that precludes any large scale labeled 
networking deployment in commercial sectors.  If you are routing based 
on it you are also getting another security problem.

    I see the immediate need for CIPSO to work to the extent it can to 
support whatever works at the moment.  But I'm not sure extending the 
same fundamental problems and incompatibilities into ipv6 is going to be 
a win for labeling in general.  I certainly wouldn't complain about 
administrative difficulty and champion it in the same email thread.. ;)
    -Will
>   



From paul.moore at hp.com  Mon Apr 21 14:38:23 2008
From: paul.moore at hp.com (Paul Moore)
Date: Mon, 21 Apr 2008 17:38:23 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <480D0302.8080402@sun.com>
References: <48065272.200@sun.com> <200804201007.48828.paul.moore@hp.com>
	<480D0302.8080402@sun.com>
Message-ID: <200804211738.23082.paul.moore@hp.com>

On Monday 21 April 2008 5:11:30 pm Will Young wrote:
> Paul Moore wrote:
> > On Friday 18 April 2008 8:17:28 pm Will Young wrote:
> >>     I'm having trouble seeing the value of separating integrity
> >> and labeling.  For a middle system to  correctly examine a label
> >> it needs to have the ability to verify integrity.  If you are
> >> using IPsec for integrity and want an intermediary to participate
> >> then you would have to be able to have an SA at the label for the
> >> tunnel to the intermediary and an SA for the peer for transport
> >> integrity.
> >>
> >>     If the system requires complete paranoia each party could
> >> transmit the intended transport SPIs and their label and the
> >> gateway could drop any mismatches..  Explicit labels could
> >> eliminate that stage, but I don't think that warrants the
> >> pain/cost of a variable size next hop ip option.
> >
> > I think the above two paragraphs demonstrate how difficult it is
> > for an intermediate hop to "see" the security label of a labeled
> > IPsec packet. Essentially you either have to make the intermediate
> > hop an IPsec endpoint or develop an out of band protocol to notify
> > the node of the label/SPI paring.
>
>     But it isn't so much difficult as wrong.  IPsec based labeling
> gives you integrity and privacy between the end points.  If you want
> a hop-by-hop secured labeling protocol you want to extend vlans to
> support complex labels or mimic a secure link layer with a secure
> tunnel.  The mix of labeled and unlabeled systems/routers
> interchanging labeled and unlabeled packets and a few routers here
> and there filtering and/or inserting labels is a disaster that looks
> like someone tried to design a network for source routing and then
> add a security policy to limit it.

I had to chuckle a bit because this is one of the more common scenarios 
that I've been told about: multiple single-label/unlabeled physical 
networks connected to a proxy/router/guard which is in turned connected 
to a labeled network and it's the proxy/router/guard's responsibility 
to ensure the routing is correct and apply/remove labels as necessary.

I promise you I'm not making this stuff up to be annoying, these are 
actual user requirements/requests.

> > The first option concerns me because it requires extra processing
> > at the intermediate node where processing and memory is most likely
> > limited (see my earlier email with Bill Sommerfeld regarding
> > scalability).  The second option (aside from synchronization and
> > management issues) isn't viable for several users who want to be
> > able to passively audit network security labels; I've had at least
> > one user comment that because of this reason he can't use labeled
> > IPsec.
>
>     Security through passive network auditing alone is security by
> obscurity.  The systems can ultimately send any data they want
> labeled as whatever is allowed.  The only way to know they are not is
> to have system auditing.  Such system auditing should be secure and
> remote and could be used to correctly draw the conclusions one thinks
> one is getting from network monitoring.  Where the routers could help
> is in providing additional audit data.

Whenever I've heard the requirement for passive network auditing it is 
in conjunction with systems that already have fairly extensive system 
auditing (and other controls) in place.  The people are very paranoid 
(we are talking four or five layers of tinfoil in their hats :)) and 
want the ability to audit everything they possibly can.

> >>     Perhaps making CALIPSO a destination option would be a better
> >> stop gap measure.  This would imply one could do drop by label in
> >> firewalls but not route by label which I don't think will ever be
> >> valid in terms of integrity at the IP layer.
> >>     Labeled gateways would then want to setup auto-tunnels that
> >> have a destination option on the outer header for unlabeled
> >> packets and could at some later point have integrity..
> >
> > While I like the idea of having the labeling protocol as a
> > hop-by-hop option, if that isn't acceptable then a destination
> > option is better than nothing.
>
>     If there is no integrity and every host on the network is given a
> crack at forging one, what are you really getting from the
> hop-by-hop?

You are assuming a network environment where the nodes are not trusted.  
Normally this is a safe and valid assumption, however, for many 
existing labeled networking users this is not the case.  Some of these 
users go through elaborate measures to ensure the security of the 
network and all the nodes that comprise the network.  Granted not 
everyone can has this luxury, but for those of us who don't there is 
good old fashioned IPsec which can safeguard and or conceal the 
security labels depending on the user's needs.

>     I see the immediate need for CIPSO to work to the extent it can
> to support whatever works at the moment.  But I'm not sure extending
> the same fundamental problems and incompatibilities into ipv6 is
> going to be a win for labeling in general.

See my earlier statements regarding physical network security and the 
use of IPsec when you don't have it.

> I certainly wouldn't complain about administrative difficulty and
> champion it in the same email thread.. ;)

 ;)

-- 
paul moore
linux @ hp


From James.Hughes at Sun.COM  Mon Apr 21 15:42:12 2008
From: James.Hughes at Sun.COM (james hughes)
Date: Mon, 21 Apr 2008 15:42:12 -0700
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <480D0302.8080402@sun.com>
References: <48065272.200@sun.com> <48091ADD.6050601@sun.com>
	<48093A18.6030508@sun.com> <200804201007.48828.paul.moore@hp.com>
	<480D0302.8080402@sun.com>
Message-ID: <D40FDFFE-6EE4-4C5E-852F-0CF8D5018718@sun.com>

Risking joinging a discussion mid thread...

On Apr 21, 2008, at 2:11 PM, Will Young wrote:
>>> On Friday 18 April 2008 8:17:28 pm Will Young wrote:
[...]
>> I think the above two paragraphs demonstrate how difficult it is  
>> for an
>> intermediate hop to "see" the security label of a labeled IPsec  
>> packet.
>> Essentially you either have to make the intermediate hop an IPsec
>> endpoint or develop an out of band protocol to notify the node of the
>> label/SPI paring.
>>
>    But it isn't so much difficult as wrong.  IPsec based labeling  
> gives
> you integrity and privacy between the end points.


privacy, Integrity _and_ authentication. The latter being more  
important IMO.

Without some key material at the intermediate hop, a check of the per  
packet label/SPI paring can not be considered a security feature for  
the traffic itself since it can easily be spoofed (MITM or sniff/ 
insert). Even if the intermediate can be securely notified about the  
label/SPI pairing, the security of the individual packets is not  
authenticated.

I will argue that if you need intermediate hop security measures, you  
need to multiply wrap the packet so that the intermediate node has  
some key material, and this key material should be unrelated from the  
end-to-end security.

While IPSEC committee used to frown on multiple encryption and tunnel  
mode, combining an innermost combined ESP/AH with one or more outer AH  
encapsulations is possible. This scheme has no more setup overhead  
than an out of band protocol to notify the node of the label/SPI  
paring while also giving the mid-point key material needed to  
authenticate individual packets. Another benefit is that there is no  
new protocol to develop.

Jim








From sommerfeld at sun.com  Mon Apr 21 15:31:03 2008
From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Mon, 21 Apr 2008 15:31:03 -0700
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <200804211738.23082.paul.moore@hp.com>
References: <48065272.200@sun.com> <200804201007.48828.paul.moore@hp.com>
	<480D0302.8080402@sun.com>  <200804211738.23082.paul.moore@hp.com>
Message-ID: <1208817063.1190.66.camel@localhost>

On Mon, 2008-04-21 at 17:38 -0400, Paul Moore wrote:
>  multiple single-label/unlabeled physical 
> networks connected to a proxy/router/guard which is in turned connected 
> to a labeled network and it's the proxy/router/guard's responsibility 
> to ensure the routing is correct and apply/remove labels as necessary.

before we go further I should warn you that I hate fuzzy terminology.
Unfortunately "router" is one such term that has gotten fuzzy
recently.  

When you say "proxy/router/guard", does the "router" part mean a
traditional router (which leaves ip header fields other than TTL and
header checksum unmolested?)  or something which may do something more
invasive? 

> You are assuming a network environment where the nodes are not trusted.  
> Normally this is a safe and valid assumption, however, for many 
> existing labeled networking users this is not the case.  Some of these 
> users go through elaborate measures to ensure the security of the 
> network and all the nodes that comprise the network.

depending on securing a set of nodes (some of which may be internal to
the network) is unavoidable; depending on securing every millimeter of
cable between them seems like asking for trouble when you can't see the
middle and both ends of every cable that matters.

					- Bill




From paul.moore at hp.com  Mon Apr 21 16:03:12 2008
From: paul.moore at hp.com (Paul Moore)
Date: Mon, 21 Apr 2008 19:03:12 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <1208817063.1190.66.camel@localhost>
References: <48065272.200@sun.com> <200804211738.23082.paul.moore@hp.com>
	<1208817063.1190.66.camel@localhost>
Message-ID: <200804211903.12865.paul.moore@hp.com>

On Monday 21 April 2008 6:31:03 pm Bill Sommerfeld wrote:
> On Mon, 2008-04-21 at 17:38 -0400, Paul Moore wrote:
> >  multiple single-label/unlabeled physical
> > networks connected to a proxy/router/guard which is in turned
> > connected to a labeled network and it's the proxy/router/guard's
> > responsibility to ensure the routing is correct and apply/remove
> > labels as necessary.
>
> before we go further I should warn you that I hate fuzzy terminology.
> Unfortunately "router" is one such term that has gotten fuzzy
> recently.
>
> When you say "proxy/router/guard", does the "router" part mean a
> traditional router (which leaves ip header fields other than TTL and
> header checksum unmolested?)  or something which may do something
> more invasive?

The term "guard" is the one I hear most often in this particular case 
and is used to represent an intermediate node which acts as a gateway 
between two differently labeled networks.  I have heard of cases where 
traffic is multiplexed/demuxed from multiple single-label/unlabeled 
networks to a single multi-label network (above example) where the only 
change to the packet is the addition or removal of a label.  I have 
also heard of instances where the guard acts more as an application 
proxy where the traffic is consumed locally, processed by one or more 
applications, and then sent back out on the wire.

The first example could arguably considered to be routing (I'll leave 
that distinction to others to make) while the second is much more than 
that.

> > You are assuming a network environment where the nodes are not
> > trusted. Normally this is a safe and valid assumption, however, for
> > many existing labeled networking users this is not the case.  Some
> > of these users go through elaborate measures to ensure the security
> > of the network and all the nodes that comprise the network.
>
> depending on securing a set of nodes (some of which may be internal
> to the network) is unavoidable; depending on securing every
> millimeter of cable between them seems like asking for trouble when
> you can't see the middle and both ends of every cable that matters.

I don't know what to say other than that these users are very security 
aware and have mechanisms in place to provide them the level of 
assurance that they need.  These people are not clueless.

-- 
paul moore
linux @ hp


From sommerfeld at sun.com  Mon Apr 21 17:57:35 2008
From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Mon, 21 Apr 2008 17:57:35 -0700
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <200804211903.12865.paul.moore@hp.com>
References: <48065272.200@sun.com> <200804211738.23082.paul.moore@hp.com>
	<1208817063.1190.66.camel@localhost>
	<200804211903.12865.paul.moore@hp.com>
Message-ID: <1208825855.1190.112.camel@localhost>


On Mon, 2008-04-21 at 19:03 -0400, Paul Moore wrote:
> > depending on securing a set of nodes (some of which may be internal
> > to the network) is unavoidable; depending on securing every
> > millimeter of cable between them seems like asking for trouble when
> > you can't see the middle and both ends of every cable that matters.
> 
> I don't know what to say other than that these users are very security 
> aware and have mechanisms in place to provide them the level of 
> assurance that they need.  These people are not clueless.

while on my current trip to CA I was introduced to the joys of in-n-out
burger.  Turns out that they have an off-menu "grilled cheese sandwich"
which is really a cheeseburger without the beef. 

we could provide these very security aware people an off-menu labeled
ESP + null auth + null encryption for use with their "other mechanisms
in place" and avoid the need to build two different label & security
attribute negotiation protocols.

						- Bill





From paul.moore at hp.com  Mon Apr 21 18:33:45 2008
From: paul.moore at hp.com (Paul Moore)
Date: Mon, 21 Apr 2008 21:33:45 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <1208825855.1190.112.camel@localhost>
References: <48065272.200@sun.com> <200804211903.12865.paul.moore@hp.com>
	<1208825855.1190.112.camel@localhost>
Message-ID: <200804212133.45556.paul.moore@hp.com>

On Monday 21 April 2008 8:57:35 pm Bill Sommerfeld wrote:
> On Mon, 2008-04-21 at 19:03 -0400, Paul Moore wrote:
> > > depending on securing a set of nodes (some of which may be
> > > internal to the network) is unavoidable; depending on securing
> > > every millimeter of cable between them seems like asking for
> > > trouble when you can't see the middle and both ends of every
> > > cable that matters.
> >
> > I don't know what to say other than that these users are very
> > security aware and have mechanisms in place to provide them the
> > level of assurance that they need.  These people are not clueless.
>
> while on my current trip to CA I was introduced to the joys of
> in-n-out burger.  Turns out that they have an off-menu "grilled
> cheese sandwich" which is really a cheeseburger without the beef.

Those clever burger folks, what will they think of next! :)

> we could provide these very security aware people an off-menu labeled
> ESP + null auth + null encryption for use with their "other
> mechanisms in place" and avoid the need to build two different label
> & security attribute negotiation protocols.

Except they would still be saddled with all of the management overhead 
of IPsec.  As an alternative, if we were to build a labeling only 
protocol it would work fine for this group of users and the rest of the 
world who wishes to use labeled networking can utilize IPsec on top of 
the labeling protocol to provide the necessary packet level security.  
Using this approach allow the greatest level of flexibility and allows 
users to leverage an existing IPsec infrastructure.  Odds are the group 
of users we are talking about have already either deployed IPsec or 
secured their networks through other means.

-- 
paul moore
linux @ hp


From Jarrett.Lu at Sun.COM  Mon Apr 21 18:43:31 2008
From: Jarrett.Lu at Sun.COM (Jarrett Lu)
Date: Mon, 21 Apr 2008 18:43:31 -0700
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <1208825855.1190.112.camel@localhost>
References: <48065272.200@sun.com> <200804211738.23082.paul.moore@hp.com>
	<1208817063.1190.66.camel@localhost>
	<200804211903.12865.paul.moore@hp.com>
	<1208825855.1190.112.camel@localhost>
Message-ID: <480D42C3.2040100@sun.com>

Bill Sommerfeld wrote:
> On Mon, 2008-04-21 at 19:03 -0400, Paul Moore wrote:
>   
>>> depending on securing a set of nodes (some of which may be internal
>>> to the network) is unavoidable; depending on securing every
>>> millimeter of cable between them seems like asking for trouble when
>>> you can't see the middle and both ends of every cable that matters.
>>>       
>> I don't know what to say other than that these users are very security 
>> aware and have mechanisms in place to provide them the level of 
>> assurance that they need.  These people are not clueless.
>>     
>
> while on my current trip to CA I was introduced to the joys of in-n-out
> burger.  Turns out that they have an off-menu "grilled cheese sandwich"
> which is really a cheeseburger without the beef. 
>
> we could provide these very security aware people an off-menu labeled
> ESP + null auth + null encryption for use with their "other mechanisms
> in place" and avoid the need to build two different label & security
> attribute negotiation protocols.
>   

This may be a reasonable place to start. Different people will have 
different
needs based on security of their networks, their scalability 
requirements, and
overhead they are willing to accept. If we can use an existing mechanism and
offer options ranging from null encryption to double encryption, it 
sounds like
a good starting point to me. This doesn't stop us from assessing user's pain
points as we go. FMAC project should not depend on creation of a new 
protocol
as designing a non-controversial protocol at IETF is a multi-year effort 
nowadays.
This approach applies to both IPv4 and IPv6 where as CALIPSO is v6 only.

Jarrett


> 						- Bill
>
>
>
>   



From paul.moore at hp.com  Mon Apr 21 19:05:03 2008
From: paul.moore at hp.com (Paul Moore)
Date: Mon, 21 Apr 2008 22:05:03 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <480D42C3.2040100@sun.com>
References: <48065272.200@sun.com> <1208825855.1190.112.camel@localhost>
	<480D42C3.2040100@sun.com>
Message-ID: <200804212205.03937.paul.moore@hp.com>

On Monday 21 April 2008 9:43:31 pm Jarrett Lu wrote:
> Bill Sommerfeld wrote:
> > On Mon, 2008-04-21 at 19:03 -0400, Paul Moore wrote:
> >>> depending on securing a set of nodes (some of which may be
> >>> internal to the network) is unavoidable; depending on securing
> >>> every millimeter of cable between them seems like asking for
> >>> trouble when you can't see the middle and both ends of every
> >>> cable that matters.
> >
> > we could provide these very security aware people an off-menu
> > labeled ESP + null auth + null encryption for use with their "other
> > mechanisms in place" and avoid the need to build two different
> > label & security attribute negotiation protocols.
>
> This may be a reasonable place to start. Different people will have
> different needs based on security of their networks, their scalability
> requirements, and overhead they are willing to accept. If we can use
> an existing mechanism and offer options ranging from null encryption
> to double encryption, it sounds like a good starting point to me.

The problem is that there is not an IETF published specification which 
offers generic network labeling.  While there are some provisions for 
MLS labels in IKEv1 (I believe they were removed from IKEv2, need to 
verify this) there was never a generic label mechanism.  The current 
labeled IPsec implementation used by SELinux is non-standard and 
actually infringes on an existing IPsec/IKE specification.

-- 
paul moore
linux @ hp


From sommerfeld at sun.com  Mon Apr 21 18:59:30 2008
From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Mon, 21 Apr 2008 18:59:30 -0700
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <200804212133.45556.paul.moore@hp.com>
References: <48065272.200@sun.com> <200804211903.12865.paul.moore@hp.com>
	<1208825855.1190.112.camel@localhost>
	<200804212133.45556.paul.moore@hp.com>
Message-ID: <1208829570.1190.121.camel@localhost>

On Mon, 2008-04-21 at 21:33 -0400, Paul Moore wrote:
> Except they would still be saddled with all of the management overhead 
> of IPsec.

maybe it's a matter of what you're used to always looking easier than
the unfamilar, but in my experience, the administrative overhead of
setting up IPsec is trivial compared with the administrative overhead of
setting up sensitivity labeling.  The stuff that Flask-type systems
looks even more complex than setting up sensitivity labels.  

if ipsec could be configured "for free" would your objection go away?

						- Bill





From sommerfeld at sun.com  Mon Apr 21 19:13:08 2008
From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Mon, 21 Apr 2008 19:13:08 -0700
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <200804212205.03937.paul.moore@hp.com>
References: <48065272.200@sun.com> <1208825855.1190.112.camel@localhost>
	<480D42C3.2040100@sun.com>  <200804212205.03937.paul.moore@hp.com>
Message-ID: <1208830388.1190.127.camel@localhost>


On Mon, 2008-04-21 at 22:05 -0400, Paul Moore wrote:
> The problem is that there is not an IETF published specification which 
> offers generic network labeling.  While there are some provisions for 
> MLS labels in IKEv1 (I believe they were removed from IKEv2, need to 
> verify this) there was never a generic label mechanism. 

They were removed from IKEv2 (because of lack of implementation
experience with them in IKEv1).  IKEv2 could be extended to add them
and/or other label-like attributes.

I'm reluctant to approach the IETF without implementation experience in
hand to help drive the IETF processes to a speedy convergence. 

> The current 
> labeled IPsec implementation used by SELinux is non-standard and 
> actually infringes on an existing IPsec/IKE specification.

As a platform-neutral protocol I would suggest using something a little
less SELinux-specific than an unstructured character string security
context.  

						- Bill






From Jarrett.Lu at Sun.COM  Mon Apr 21 19:43:16 2008
From: Jarrett.Lu at Sun.COM (Jarrett Lu)
Date: Mon, 21 Apr 2008 19:43:16 -0700
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <200804212205.03937.paul.moore@hp.com>
References: <48065272.200@sun.com> <1208825855.1190.112.camel@localhost>
	<480D42C3.2040100@sun.com> <200804212205.03937.paul.moore@hp.com>
Message-ID: <480D50C4.3050201@sun.com>

Paul Moore wrote:
> On Monday 21 April 2008 9:43:31 pm Jarrett Lu wrote:
>   
>> Bill Sommerfeld wrote:
>>     
>>> On Mon, 2008-04-21 at 19:03 -0400, Paul Moore wrote:
>>>       
>>>>> depending on securing a set of nodes (some of which may be
>>>>> internal to the network) is unavoidable; depending on securing
>>>>> every millimeter of cable between them seems like asking for
>>>>> trouble when you can't see the middle and both ends of every
>>>>> cable that matters.
>>>>>           
>>> we could provide these very security aware people an off-menu
>>> labeled ESP + null auth + null encryption for use with their "other
>>> mechanisms in place" and avoid the need to build two different
>>> label & security attribute negotiation protocols.
>>>       
>> This may be a reasonable place to start. Different people will have
>> different needs based on security of their networks, their scalability
>> requirements, and overhead they are willing to accept. If we can use
>> an existing mechanism and offer options ranging from null encryption
>> to double encryption, it sounds like a good starting point to me.
>>     
>
> The problem is that there is not an IETF published specification which 
> offers generic network labeling.  While there are some provisions for 
> MLS labels in IKEv1 (I believe they were removed from IKEv2, need to 
> verify this) there was never a generic label mechanism.  The current 
> labeled IPsec implementation used by SELinux is non-standard and 
> actually infringes on an existing IPsec/IKE specification.
>
>   

As Bill said, the labeling text was removed due to lack implementation. 
I believe
the consensus was that the labeling text will go back in when people 
actually
implement labels.

I believe an IETF specification on network labeling is very desirable. I 
just
don't think FMAC should wait for or depend on this specification. Such a
protocol specification can be controversial, as hinted by discussion so far
on this discussion thread. We should start by what asking what problem we
want to solve with a new labeling protocol. Without proper scope, I doubt
we will get very far.

Jarrett




From paul.moore at hp.com  Mon Apr 21 19:50:43 2008
From: paul.moore at hp.com (Paul Moore)
Date: Mon, 21 Apr 2008 22:50:43 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <1208829570.1190.121.camel@localhost>
References: <48065272.200@sun.com> <200804212133.45556.paul.moore@hp.com>
	<1208829570.1190.121.camel@localhost>
Message-ID: <200804212250.43274.paul.moore@hp.com>

On Monday 21 April 2008 9:59:30 pm Bill Sommerfeld wrote:
> On Mon, 2008-04-21 at 21:33 -0400, Paul Moore wrote:
> > Except they would still be saddled with all of the management
> > overhead of IPsec.
>
> maybe it's a matter of what you're used to always looking easier than
> the unfamilar, but in my experience, the administrative overhead of
> setting up IPsec is trivial compared with the administrative overhead
> of setting up sensitivity labeling.  The stuff that Flask-type
> systems looks even more complex than setting up sensitivity labels.

While IPsec can be difficult to configure and manage, the complexity of 
configuring security labels on some of these systems can be amazingly 
complex.  However, the administrators have to configure the security 
labels regardless of the presence of IPsec.

> if ipsec could be configured "for free" would your objection go away?

To me, IPsec is a poor choice for a labeling protocol; there are the 
reasons that have already been mentioned as well as a few other reasons 
related to implementation details and the loose connection of IPsec SAs 
to application layer sockets.  In my mind fixing the IPsec management 
problem helps but it doesn't solve the underlying problem that IPsec is 
ill suited for labeling.

-- 
paul moore
linux @ hp


From paul.moore at hp.com  Mon Apr 21 19:52:51 2008
From: paul.moore at hp.com (Paul Moore)
Date: Mon, 21 Apr 2008 22:52:51 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <1208830388.1190.127.camel@localhost>
References: <48065272.200@sun.com> <200804212205.03937.paul.moore@hp.com>
	<1208830388.1190.127.camel@localhost>
Message-ID: <200804212252.51734.paul.moore@hp.com>

On Monday 21 April 2008 10:13:08 pm Bill Sommerfeld wrote:
> On Mon, 2008-04-21 at 22:05 -0400, Paul Moore wrote:
> > The problem is that there is not an IETF published specification
> > which offers generic network labeling.  While there are some
> > provisions for MLS labels in IKEv1 (I believe they were removed
> > from IKEv2, need to verify this) there was never a generic label
> > mechanism.
>
> They were removed from IKEv2 (because of lack of implementation
> experience with them in IKEv1).  IKEv2 could be extended to add them
> and/or other label-like attributes.
>
> I'm reluctant to approach the IETF without implementation experience
> in hand to help drive the IETF processes to a speedy convergence.

Whatever we agree on I hope we can both prototype our own 
implementations as the drafts progress.

> > The current
> > labeled IPsec implementation used by SELinux is non-standard and
> > actually infringes on an existing IPsec/IKE specification.
>
> As a platform-neutral protocol I would suggest using something a
> little less SELinux-specific than an unstructured character string
> security context.

Agreed.  In addition to the security label itself we should also include 
a DOI value for the label.  Once again, this should apply to any 
labeling solution.

-- 
paul moore
linux @ hp


From sds at tycho.nsa.gov  Tue Apr 22 05:23:44 2008
From: sds at tycho.nsa.gov (Stephen Smalley)
Date: Tue, 22 Apr 2008 08:23:44 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <1208830388.1190.127.camel@localhost>
References: <48065272.200@sun.com> <1208825855.1190.112.camel@localhost>
	<480D42C3.2040100@sun.com>  <200804212205.03937.paul.moore@hp.com>
	<1208830388.1190.127.camel@localhost>
Message-ID: <1208867024.15796.104.camel@moss-spartans.epoch.ncsc.mil>


On Mon, 2008-04-21 at 19:13 -0700, Bill Sommerfeld wrote:
> On Mon, 2008-04-21 at 22:05 -0400, Paul Moore wrote:
> > The problem is that there is not an IETF published specification which 
> > offers generic network labeling.  While there are some provisions for 
> > MLS labels in IKEv1 (I believe they were removed from IKEv2, need to 
> > verify this) there was never a generic label mechanism. 
> 
> They were removed from IKEv2 (because of lack of implementation
> experience with them in IKEv1).  IKEv2 could be extended to add them
> and/or other label-like attributes.
> 
> I'm reluctant to approach the IETF without implementation experience in
> hand to help drive the IETF processes to a speedy convergence. 
> 
> > The current 
> > labeled IPsec implementation used by SELinux is non-standard and 
> > actually infringes on an existing IPsec/IKE specification.
> 
> As a platform-neutral protocol I would suggest using something a little
> less SELinux-specific than an unstructured character string security
> context.  

A variable-length octet array would be fine.  What we don't want to do
is wire the security label fields/content interpretation into the
protocol - that is encapsulated by the security server aka policy engine
and partly defined through policy configuration.

-- 
Stephen Smalley
National Security Agency



From William.Young at Sun.COM  Tue Apr 22 06:45:34 2008
From: William.Young at Sun.COM (William Young)
Date: Tue, 22 Apr 2008 09:45:34 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <1208867024.15796.104.camel@moss-spartans.epoch.ncsc.mil>
References: <48065272.200@sun.com> <1208825855.1190.112.camel@localhost>
	<480D42C3.2040100@sun.com> <200804212205.03937.paul.moore@hp.com>
	<1208830388.1190.127.camel@localhost>
	<1208867024.15796.104.camel@moss-spartans.epoch.ncsc.mil>
Message-ID: <480DEBFE.2010207@sun.com>

Stephen Smalley wrote:
> On Mon, 2008-04-21 at 19:13 -0700, Bill Sommerfeld wrote:
>> On Mon, 2008-04-21 at 22:05 -0400, Paul Moore wrote:
>>> The problem is that there is not an IETF published specification which 
>>> offers generic network labeling.  While there are some provisions for 
>>> MLS labels in IKEv1 (I believe they were removed from IKEv2, need to 
>>> verify this) there was never a generic label mechanism. 
>> They were removed from IKEv2 (because of lack of implementation
>> experience with them in IKEv1).  IKEv2 could be extended to add them
>> and/or other label-like attributes.
>>
>> I'm reluctant to approach the IETF without implementation experience in
>> hand to help drive the IETF processes to a speedy convergence. 
>>
>>> The current 
>>> labeled IPsec implementation used by SELinux is non-standard and 
>>> actually infringes on an existing IPsec/IKE specification.
>> As a platform-neutral protocol I would suggest using something a little
>> less SELinux-specific than an unstructured character string security
>> context.  
> 
> A variable-length octet array would be fine.  What we don't want to do
> is wire the security label fields/content interpretation into the
> protocol - that is encapsulated by the security server aka policy engine
> and partly defined through policy configuration.
	I don't follow.  Why would you think the other system has the same 
policy engine?
	I think you do need to encode abstract DOI + label...  The old neutral 
proposal was IPSO, I think CALIPSO would not be a bad choice in this 
context.
	-Will

> 



From sds at tycho.nsa.gov  Tue Apr 22 06:52:33 2008
From: sds at tycho.nsa.gov (Stephen Smalley)
Date: Tue, 22 Apr 2008 09:52:33 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <480DEBFE.2010207@sun.com>
References: <48065272.200@sun.com> <1208825855.1190.112.camel@localhost>
	<480D42C3.2040100@sun.com> <200804212205.03937.paul.moore@hp.com>
	<1208830388.1190.127.camel@localhost>
	<1208867024.15796.104.camel@moss-spartans.epoch.ncsc.mil>
	<480DEBFE.2010207@sun.com>
Message-ID: <1208872353.15796.108.camel@moss-spartans.epoch.ncsc.mil>


On Tue, 2008-04-22 at 09:45 -0400, William Young wrote:
> Stephen Smalley wrote:
> > On Mon, 2008-04-21 at 19:13 -0700, Bill Sommerfeld wrote:
> >> On Mon, 2008-04-21 at 22:05 -0400, Paul Moore wrote:
> >>> The problem is that there is not an IETF published specification which 
> >>> offers generic network labeling.  While there are some provisions for 
> >>> MLS labels in IKEv1 (I believe they were removed from IKEv2, need to 
> >>> verify this) there was never a generic label mechanism. 
> >> They were removed from IKEv2 (because of lack of implementation
> >> experience with them in IKEv1).  IKEv2 could be extended to add them
> >> and/or other label-like attributes.
> >>
> >> I'm reluctant to approach the IETF without implementation experience in
> >> hand to help drive the IETF processes to a speedy convergence. 
> >>
> >>> The current 
> >>> labeled IPsec implementation used by SELinux is non-standard and 
> >>> actually infringes on an existing IPsec/IKE specification.
> >> As a platform-neutral protocol I would suggest using something a little
> >> less SELinux-specific than an unstructured character string security
> >> context.  
> > 
> > A variable-length octet array would be fine.  What we don't want to do
> > is wire the security label fields/content interpretation into the
> > protocol - that is encapsulated by the security server aka policy engine
> > and partly defined through policy configuration.
> 	I don't follow.  Why would you think the other system has the same 
> policy engine?

We wouldn't.  As you said, there would be a DOI followed by the
unstructured variable-length octet array (which in our case is a
string).  

> 	I think you do need to encode abstract DOI + label...  The old neutral 
> proposal was IPSO, I think CALIPSO would not be a bad choice in this 
> context.

Except that it sounds like they are making the mistake of the past again
and limiting themselves to MLS-only labels.  Which is unfortunate when
there are flexible MAC systems in production use already, probably more
of them than MLS systems.

-- 
Stephen Smalley
National Security Agency



From sds at tycho.nsa.gov  Tue Apr 22 07:08:40 2008
From: sds at tycho.nsa.gov (Stephen Smalley)
Date: Tue, 22 Apr 2008 10:08:40 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <200804212250.43274.paul.moore@hp.com>
References: <48065272.200@sun.com> <200804212133.45556.paul.moore@hp.com>
	<1208829570.1190.121.camel@localhost>
	<200804212250.43274.paul.moore@hp.com>
Message-ID: <1208873320.15796.115.camel@moss-spartans.epoch.ncsc.mil>


On Mon, 2008-04-21 at 22:50 -0400, Paul Moore wrote:
> On Monday 21 April 2008 9:59:30 pm Bill Sommerfeld wrote:
> > On Mon, 2008-04-21 at 21:33 -0400, Paul Moore wrote:
> > > Except they would still be saddled with all of the management
> > > overhead of IPsec.
> >
> > maybe it's a matter of what you're used to always looking easier than
> > the unfamilar, but in my experience, the administrative overhead of
> > setting up IPsec is trivial compared with the administrative overhead
> > of setting up sensitivity labeling.  The stuff that Flask-type
> > systems looks even more complex than setting up sensitivity labels.
> 
> While IPsec can be difficult to configure and manage, the complexity of 
> configuring security labels on some of these systems can be amazingly 
> complex.  However, the administrators have to configure the security 
> labels regardless of the presence of IPsec.
> 
> > if ipsec could be configured "for free" would your objection go away?
> 
> To me, IPsec is a poor choice for a labeling protocol; there are the 
> reasons that have already been mentioned as well as a few other reasons 
> related to implementation details and the loose connection of IPsec SAs 
> to application layer sockets.  In my mind fixing the IPsec management 
> problem helps but it doesn't solve the underlying problem that IPsec is 
> ill suited for labeling.

Just to clarify - the above is Paul's view, and not necessarily shared
by the rest of us (not by me, in particular).  I'll certainly agree that
the implementation of labeled IPSEC was complicated to get right in
Linux, but I think coupling protection and labeling is the right model.

-- 
Stephen Smalley
National Security Agency



From paul.moore at hp.com  Tue Apr 22 07:27:55 2008
From: paul.moore at hp.com (Paul Moore)
Date: Tue, 22 Apr 2008 10:27:55 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <1208873320.15796.115.camel@moss-spartans.epoch.ncsc.mil>
References: <48065272.200@sun.com> <200804212250.43274.paul.moore@hp.com>
	<1208873320.15796.115.camel@moss-spartans.epoch.ncsc.mil>
Message-ID: <200804221027.55986.paul.moore@hp.com>

On Tuesday 22 April 2008 10:08:40 am Stephen Smalley wrote:
> On Mon, 2008-04-21 at 22:50 -0400, Paul Moore wrote:
> > To me, IPsec is a poor choice for a labeling protocol; there are
> > the reasons that have already been mentioned as well as a few other
> > reasons related to implementation details and the loose connection
> > of IPsec SAs to application layer sockets.  In my mind fixing the
> > IPsec management problem helps but it doesn't solve the underlying
> > problem that IPsec is ill suited for labeling.
>
> Just to clarify - the above is Paul's view, and not necessarily
> shared by the rest of us (not by me, in particular).  I'll certainly
> agree that the implementation of labeled IPSEC was complicated to get
> right in Linux, but I think coupling protection and labeling is the
> right model.

I can only speak for myself and what I believe is the right way forward; 
I've never claimed otherwise.  I'm also sticking with the labeling-only 
protocol not to be difficult but because I truly feel it is the best 
solution to the problems that users are facing.  There are obviously 
some rather smart people (Stephen, Bill, and others) who disagree with 
me and I think this is a good thing.  Debate, while sometimes painful, 
creates better designs in the end.

-- 
paul moore
linux @ hp


From sds at tycho.nsa.gov  Tue Apr 22 08:17:58 2008
From: sds at tycho.nsa.gov (Stephen Smalley)
Date: Tue, 22 Apr 2008 11:17:58 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <200804221027.55986.paul.moore@hp.com>
References: <48065272.200@sun.com> <200804212250.43274.paul.moore@hp.com>
	<1208873320.15796.115.camel@moss-spartans.epoch.ncsc.mil>
	<200804221027.55986.paul.moore@hp.com>
Message-ID: <1208877478.15796.133.camel@moss-spartans.epoch.ncsc.mil>


On Tue, 2008-04-22 at 10:27 -0400, Paul Moore wrote:
> On Tuesday 22 April 2008 10:08:40 am Stephen Smalley wrote:
> > On Mon, 2008-04-21 at 22:50 -0400, Paul Moore wrote:
> > > To me, IPsec is a poor choice for a labeling protocol; there are
> > > the reasons that have already been mentioned as well as a few other
> > > reasons related to implementation details and the loose connection
> > > of IPsec SAs to application layer sockets.  In my mind fixing the
> > > IPsec management problem helps but it doesn't solve the underlying
> > > problem that IPsec is ill suited for labeling.
> >
> > Just to clarify - the above is Paul's view, and not necessarily
> > shared by the rest of us (not by me, in particular).  I'll certainly
> > agree that the implementation of labeled IPSEC was complicated to get
> > right in Linux, but I think coupling protection and labeling is the
> > right model.
> 
> I can only speak for myself and what I believe is the right way forward; 
> I've never claimed otherwise.

Sure - but I'm not sure it was clear to the other participants whether
it was only your view or the view of the SELinux project as a whole.
Now, admittedly, your view is pretty important since you are now the
labeled networking maintainer for Linux ;)

>   I'm also sticking with the labeling-only 
> protocol not to be difficult but because I truly feel it is the best 
> solution to the problems that users are facing.  There are obviously 
> some rather smart people (Stephen, Bill, and others) who disagree with 
> me and I think this is a good thing.  Debate, while sometimes painful, 
> creates better designs in the end.

Agreed.  And it isn't that I think that IPSEC was designed or
implemented in a manner that makes it well suited to labeling, but just
that I believe that coupling protection and labeling is desirable, as
we've previously discussed.    Both to enable selection of cryptographic
protection suites based on label and to ensure real separation of data
of differing labels.

-- 
Stephen Smalley
National Security Agency



From Jarrett.Lu at Sun.COM  Tue Apr 22 08:29:48 2008
From: Jarrett.Lu at Sun.COM (Jarrett Lu)
Date: Tue, 22 Apr 2008 08:29:48 -0700
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <1208872353.15796.108.camel@moss-spartans.epoch.ncsc.mil>
References: <48065272.200@sun.com> <1208825855.1190.112.camel@localhost>
	<480D42C3.2040100@sun.com> <200804212205.03937.paul.moore@hp.com>
	<1208830388.1190.127.camel@localhost>
	<1208867024.15796.104.camel@moss-spartans.epoch.ncsc.mil>
	<480DEBFE.2010207@sun.com>
	<1208872353.15796.108.camel@moss-spartans.epoch.ncsc.mil>
Message-ID: <480E046C.6070704@sun.com>

Stephen Smalley wrote:
> On Tue, 2008-04-22 at 09:45 -0400, William Young wrote:
>   
>> Stephen Smalley wrote:
>>     
>>>
>>> A variable-length octet array would be fine.  What we don't want to do
>>> is wire the security label fields/content interpretation into the
>>> protocol - that is encapsulated by the security server aka policy engine
>>> and partly defined through policy configuration.
>>>       
>> 	I don't follow.  Why would you think the other system has the same 
>> policy engine?
>>     
>
> We wouldn't.  As you said, there would be a DOI followed by the
> unstructured variable-length octet array (which in our case is a
> string).  
>
>   
>> 	I think you do need to encode abstract DOI + label...  The old neutral 
>> proposal was IPSO, I think CALIPSO would not be a bad choice in this 
>> context.
>>     
>
> Except that it sounds like they are making the mistake of the past again
> and limiting themselves to MLS-only labels.  Which is unfortunate when
> there are flexible MAC systems in production use already, probably more
> of them than MLS systems.
>
>   

A bit background info: The CALIPSO draft is evolved from an old draft 
(SIPSO),
written by M. StJohns in 1990s. It's intent is to create a v6 version of 
CIPSO
standard, without the complex tag type of CIPSO so that it's easier for 
routers to
handle labeled packets. MLS system customers are thinking about migrating to
IPv6 and have the desire for a standard. So I think the CALIPSO draft 
will stay
the way it is today. If possible, we actually like to see more 
simplifications in the
current draft so that it'd be easier to implement and less 
controversial. Having
CALIPSO as an RFC paves road for future standards work in labeled 
networking
space.

Jarrett



From paul.moore at hp.com  Tue Apr 22 08:39:48 2008
From: paul.moore at hp.com (Paul Moore)
Date: Tue, 22 Apr 2008 11:39:48 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <1208877478.15796.133.camel@moss-spartans.epoch.ncsc.mil>
References: <48065272.200@sun.com> <200804221027.55986.paul.moore@hp.com>
	<1208877478.15796.133.camel@moss-spartans.epoch.ncsc.mil>
Message-ID: <200804221139.48996.paul.moore@hp.com>

On Tuesday 22 April 2008 11:17:58 am Stephen Smalley wrote:
> On Tue, 2008-04-22 at 10:27 -0400, Paul Moore wrote:
> > On Tuesday 22 April 2008 10:08:40 am Stephen Smalley wrote:
> > > Just to clarify - the above is Paul's view, and not necessarily
> > > shared by the rest of us (not by me, in particular).  I'll
> > > certainly agree that the implementation of labeled IPSEC was
> > > complicated to get right in Linux, but I think coupling
> > > protection and labeling is the right model.
> >
> > I can only speak for myself and what I believe is the right way
> > forward; I've never claimed otherwise.
>
> Sure - but I'm not sure it was clear to the other participants
> whether it was only your view or the view of the SELinux project as a
> whole. Now, admittedly, your view is pretty important since you are
> now the labeled networking maintainer for Linux ;)

I'm pretty sure all the labeled networking maintainer title means is 
that I'm the guy who gets the blame when the system decides to puke all 
over itself ... not that the blame is misplaced mind you ;)

> >   I'm also sticking with the labeling-only
> > protocol not to be difficult but because I truly feel it is the
> > best solution to the problems that users are facing.  There are
> > obviously some rather smart people (Stephen, Bill, and others) who
> > disagree with me and I think this is a good thing.  Debate, while
> > sometimes painful, creates better designs in the end.
>
> Agreed.  And it isn't that I think that IPSEC was designed or
> implemented in a manner that makes it well suited to labeling, but
> just that I believe that coupling protection and labeling is
> desirable, as we've previously discussed.    Both to enable selection
> of cryptographic protection suites based on label and to ensure real
> separation of data of differing labels.

I still believe we can achieve both of those goals within the existing 
IPsec specification through the use of a separate labeling protocol.

Also, one more point to consider.  If we take a historical look at the 
labeling protocols that were developed to meet user requirements and 
deployed in real world environments ([R]IPSO, CIPSO, TSIX/MaxSix) we 
see  that all of these approaches were labeling-only protocols; they 
leveraged other mechanisms, including standard IPsec, to provide packet 
level security.  This trend is also not strictly historical.  The 
recent SIPSO/CALIPSO effort is intentionally a labeling only protocol 
and like the older protocols was created due to user requests.  In 
contrast, the labeling capabilities offered in IPsec/IKEv1 were dropped 
from the recent versions because there was a lack of interest.

-- 
paul moore
linux @ hp


From sommerfeld at sun.com  Mon Apr 21 20:05:16 2008
From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Mon, 21 Apr 2008 20:05:16 -0700
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <200804212250.43274.paul.moore@hp.com>
References: <48065272.200@sun.com> <200804212133.45556.paul.moore@hp.com>
	<1208829570.1190.121.camel@localhost>
	<200804212250.43274.paul.moore@hp.com>
Message-ID: <1208833516.1190.135.camel@localhost>


On Mon, 2008-04-21 at 22:50 -0400, Paul Moore wrote:
> In my mind fixing the IPsec management 
> problem helps but it doesn't solve the underlying problem that IPsec is 
> ill suited for labeling.

this seems to be a matter of opinion and experience.

having built a labeled ipsec prototype on top of solaris, my
implementation experience tells me the exact opposite -- IPsec is
already involved in almost all of codepaths that labeling is involved in
and IPsec is ideally suited for labeling; adding labels as a new SA
attribute was straightforward and most of the code just worked on the
first or second try.

the IKEv1 negotiation to exchange sensitivity labels also just worked.

AH/ESP already has a better grip on MTU discovery (which has caused us
significant grief with CIPSO).  

					- Bill








From paul.moore at hp.com  Tue Apr 22 10:30:55 2008
From: paul.moore at hp.com (Paul Moore)
Date: Tue, 22 Apr 2008 13:30:55 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <1208833516.1190.135.camel@localhost>
References: <48065272.200@sun.com> <200804212250.43274.paul.moore@hp.com>
	<1208833516.1190.135.camel@localhost>
Message-ID: <200804221330.55457.paul.moore@hp.com>

On Monday 21 April 2008 11:05:16 pm Bill Sommerfeld wrote:
> On Mon, 2008-04-21 at 22:50 -0400, Paul Moore wrote:
> > In my mind fixing the IPsec management
> > problem helps but it doesn't solve the underlying problem that
> > IPsec is ill suited for labeling.
>
> this seems to be a matter of opinion and experience.

It is, which is why I prefaced the statement with "In my mind ...".  
Arguably we all speak based on our own experience and the opinions that 
have developed as a result of that.

-- 
paul moore
linux @ hp


From sommerfeld at sun.com  Tue Apr 22 10:36:04 2008
From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Tue, 22 Apr 2008 10:36:04 -0700
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <200804221330.55457.paul.moore@hp.com>
References: <48065272.200@sun.com> <200804212250.43274.paul.moore@hp.com>
	<1208833516.1190.135.camel@localhost>
	<200804221330.55457.paul.moore@hp.com>
Message-ID: <1208885764.1919.10.camel@localhost>


On Tue, 2008-04-22 at 13:30 -0400, Paul Moore wrote:
> It is, which is why I prefaced the statement with "In my mind ...".  
> Arguably we all speak based on our own experience and the opinions that 
> have developed as a result of that.

my intent is to (as soon as humanly possible) let the code speak for
itself.

						- Bill



From paul.moore at hp.com  Tue Apr 22 11:06:39 2008
From: paul.moore at hp.com (Paul Moore)
Date: Tue, 22 Apr 2008 14:06:39 -0400
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <1208885764.1919.10.camel@localhost>
References: <48065272.200@sun.com> <200804221330.55457.paul.moore@hp.com>
	<1208885764.1919.10.camel@localhost>
Message-ID: <200804221406.39373.paul.moore@hp.com>

On Tuesday 22 April 2008 1:36:04 pm Bill Sommerfeld wrote:
> On Tue, 2008-04-22 at 13:30 -0400, Paul Moore wrote:
> > It is, which is why I prefaced the statement with "In my mind ...".
> > Arguably we all speak based on our own experience and the opinions
> > that have developed as a result of that.
>
> my intent is to (as soon as humanly possible) let the code speak for
> itself.

Agreed.  Although I do feel there is value in sharing personal 
experience as long as it is clear that it is opinion.  In the end it 
really is a moot point since we are both working on systems where the 
source is publically available; those who are genuinely interested can 
go look-at/listen-to the code.

-- 
paul moore
linux @ hp


From gww at eng.sun.com  Tue Apr 22 12:57:38 2008
From: gww at eng.sun.com (Gary Winiger)
Date: Tue, 22 Apr 2008 12:57:38 -0700 (PDT)
Subject: [fmac-discuss] Zones and Flask
Message-ID: <200804221957.m3MJvcqY021422@marduk.eng.sun.com>


> > > The current 
> > > labeled IPsec implementation used by SELinux is non-standard and 
> > > actually infringes on an existing IPsec/IKE specification.
> > 
> > As a platform-neutral protocol I would suggest using something a little
> > less SELinux-specific than an unstructured character string security
> > context.  
> 
> A variable-length octet array would be fine.  What we don't want to do
> is wire the security label fields/content interpretation into the
> protocol - that is encapsulated by the security server aka policy engine
> and partly defined through policy configuration.

	Agreed, and that's exactly with Olin Sibert and I invented the
	Domain of Interpretation when we did the precursor work to what
	ended up as the FIPS CIPSO.  A bucket of bits is fine as long
	as there are rules for what to do if you don't know what to do
	with them; and rules for how to interpret them even if those	
	rules are handled out of band with some sort of agreement.

Gary..


From sommerfeld at sun.com  Tue Apr 22 13:07:31 2008
From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Tue, 22 Apr 2008 13:07:31 -0700
Subject: [fmac-discuss] Zones and Flask
In-Reply-To: <1208877478.15796.133.camel@moss-spartans.epoch.ncsc.mil>
References: <48065272.200@sun.com> <200804212250.43274.paul.moore@hp.com>
	<1208873320.15796.115.camel@moss-spartans.epoch.ncsc.mil>
	<200804221027.55986.paul.moore@hp.com>
	<1208877478.15796.133.camel@moss-spartans.epoch.ncsc.mil>
Message-ID: <1208894851.1919.29.camel@localhost>


On Tue, 2008-04-22 at 11:17 -0400, Stephen Smalley wrote:
> >   I'm also sticking with the labeling-only 
> > protocol not to be difficult but because I truly feel it is the best 
> > solution to the problems that users are facing.  There are obviously 
> > some rather smart people (Stephen, Bill, and others) who disagree with 
> > me and I think this is a good thing.  Debate, while sometimes painful, 
> > creates better designs in the end.
> 
> Agreed.  And it isn't that I think that IPSEC was designed or
> implemented in a manner that makes it well suited to labeling, but just
> that I believe that coupling protection and labeling is desirable, as
> we've previously discussed.  

There's more than one IPsec implementation at issue here.

The solaris IPsec implementation was built by people who had labeling in
mind from the start (we left a few XXX MLS comments here and there since
we knew we wouldn't get back to it for a while..).  that may explain at
least some of the "YMMV" here.

>   Both to enable selection of cryptographic
> protection suites based on label and to ensure real separation of data
> of differing labels.

.. as well as a presenting an opportunity to do cross-checks between the
offered label and the peer's cryptographic credentials...

						- Bill