SELinux on NFS.

SELinux on NFS.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We really want to get SELinux labeled files on NFS into Fedora 11.  But
it seems to be getting bogged down in the standards process.  I think we
need to simplify.

All Fedora  needs for SELinux on NFS is the ability to store and enforce
file labels from the client side on the server.  This has to work with
full Unix authentication model (Trusted Host) as well as the full
kerberos authentication model.

I think we can treat the server side as a dumb server.  NFS servers
tends to fully trust the client to do the "right thing" on disk
partitions that the server shares.  Our first version of SELinux NFS
should do the same.  Getting bogged down in the server worrying about
which process on the client created a file/file_label is not something
that is necessary for the first version.  And probably not something
that is required for the vast majority of situations for the next few
years.  The servers will/should not have a requirement to run SELinux.

But labelled NFS on the client side has potential great benefits for us.
 Especially with work in svirt where we want to be able to share virtual
image files via NFS and have them isolated by SELinux.

How close are we to getting this functionality working and do you think
the upstream kernel would accept your changes to allow this?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkkPeA4ACgkQrlYvE4MpobPo0gCeIRWkQ4BNwN5qGkekCL4bTpeX
6g0AoJ9wDiM46Rd/Yz96AyyaNBRL4Qbu
=SuLv
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux on NFS.

[David P. Quigley]

On Mon, 2008-11-03 at 17:15 -0500, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> We really want to get SELinux labeled files on NFS into Fedora 11.  But
> it seems to be getting bogged down in the standards process.  I think we
> need to simplify.
> 
> All Fedora  needs for SELinux on NFS is the ability to store and enforce
> file labels from the client side on the server.  This has to work with
> full Unix authentication model (Trusted Host) as well as the full
> kerberos authentication model.
> 
> I think we can treat the server side as a dumb server.  NFS servers
> tends to fully trust the client to do the "right thing" on disk
> partitions that the server shares.  Our first version of SELinux NFS
> should do the same.  Getting bogged down in the server worrying about
> which process on the client created a file/file_label is not something
> that is necessary for the first version.  And probably not something
> that is required for the vast majority of situations for the next few
> years.  The servers will/should not have a requirement to run SELinux.
> 
> But labelled NFS on the client side has potential great benefits for us.
>  Especially with work in svirt where we want to be able to share virtual
> image files via NFS and have them isolated by SELinux.
> 
> How close are we to getting this functionality working and do you think
> the upstream kernel would accept your changes to allow this?
> 

[CCing Trond and Bruce]

Dan: To answer your question we have everything that you want already in
the prototype. In terms of getting it upstreamed Trond and Bruce want to
see some consensus from the standards body before they consider
upstreaming the code. 

Trond & Bruce: I am going to be at IETF 73 in a couple of weeks are
either of you going to be there? I'd like to have a meeting with you
about what it is that you want to see happen before mainlining. This way
we can come up with the criteria we need to meet before we can mainline
the code. If neither of you are going to be at that meeting can we
organize some sort of telecon to discuss this?

Dave


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux on NFS.

[David P. Quigley]

On Tue, 2008-11-04 at 15:28 -0500, Trond Myklebust wrote:
> On Tue, 2008-11-04 at 12:46 -0500, David P. Quigley wrote:
> > Trond & Bruce: I am going to be at IETF 73 in a couple of weeks are
> > either of you going to be there? I'd like to have a meeting with you
> > about what it is that you want to see happen before mainlining. This way
> > we can come up with the criteria we need to meet before we can mainline
> > the code. If neither of you are going to be at that meeting can we
> > organize some sort of telecon to discuss this?
> 
> Hi Dave,
> 
> As far as I know, only beepy and Mike Eisler will be representing NetApp
> at the next IETF, so a conf call might be a better idea.
> 
> However, to start the conversation: My basic worry about mainlining at
> this point is that I don't want to merge something that will need to
> maintained as a legacy protocol for the benefit of Linux users if in 1
> year, everybody goes off and produces a similar but not quite the
> identical protocol within the NFSv4 minor version framework and the
> IETF.
> 
> IOW: my concern is that I want to do SELinux on NFS once only.
> 
> Cheers
>   Trond

So this brings up a concept that I don't think the WG has grasped yet.
Our goal is not to put SELinux into NFS but to provide the necessary
extensions to allow MAC systems in general to work with NFS. With FMAC
and Solaris Trusted Extensions the guys at Sun would like to see this
done in a way that they can leverage it as well. From what I've seen so
far the list of MAC systems that could use these extensions are 

SELinux
Smack
Solaris w/Trusted Extensions
Solaris FMAC
SEDarwin
SEBSD
Traditional MLS systems

Not only in the case of Solaris TX and SELinux are the models completely
different but the access decision points may differ as well (I'm not
100% sure on this I'd have to ask Glenn or Nico). Even within the same
model we see a different set of access checks. While Solaris FMAC and
SELinux are both DTE systems we've found that we were able to remove
some cruft from the SELinux object classes when dealing with FMAC and
that we needed additional classes since Solaris has more file types than
Linux does.

So there are two components to getting this system working. One is
providing the capability for NFS to store and transport per-file
security labels. We have this already and I'm pretty sure our
description of it is solid. By deciding to go with a recommended
attribute it provides us with the ability to atomically assign the label
on object creation and also prevents the server from exposing the file
before it is labeled. I'm not sure anyone really disagrees with this
method of assigning labels to files. Mike Eisler wanted to see some step
by step examples of how this works and I am working on slides for this
to use in the IETF 73 presentation.

This is the functionality that Dan and company are look at for inclusion
so they can use it in F11. This is an area where Dan and company need
weaker MAC guarantees than we do but luckily the guarantees we need are
an extension of the first component.

The second component which we see as necessary for the stronger MAC
guarantees that we need but not for Dan's needs is the ability to
transport the process label for use by the server. In Dan's scenario he
is trusting the client to make MAC policy decisions. In one of our
earlier documents to the working group we presented this as a "Dumb
Server" model. This is where the server would just store the labels and
send them over the client for policy enforcement. In our system we want
both the client and the server to be involved in the access control
decision. 

Initially we devised several methods for process label transport none of
which were optimal. We have been talking with Nico Williams and he
proposed a method of providing the guarantees we need to protect and
transport the process label solely at the RPC layer. This makes it so we
don't need to make invasive changes to the mechanisms used in RPCSECGSS.
This method is still in it's early stages but it is not necessary to
provide the functionality that Dan needs.

I think the main point of contention for the patch set at the moment is
that there isn't a satisfactory method for process label transport. I
think that if we drop process label transport for now until I can see
the document for the RPCSECGSS v3 extensions that Nico is proposing and
then implement those extensions we can get what Dan and company are
looking for while still maintaining process label transport out of tree
for those who need it until we have developed an upstreamable solution. 

Dave




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux on NFS.

[David P. Quigley]

On Tue, 2008-11-04 at 15:28 -0500, Trond Myklebust wrote:
> On Tue, 2008-11-04 at 12:46 -0500, David P. Quigley wrote:
> > Trond & Bruce: I am going to be at IETF 73 in a couple of weeks are
> > either of you going to be there? I'd like to have a meeting with you
> > about what it is that you want to see happen before mainlining. This way
> > we can come up with the criteria we need to meet before we can mainline
> > the code. If neither of you are going to be at that meeting can we
> > organize some sort of telecon to discuss this?
> 
> Hi Dave,
> 
> As far as I know, only beepy and Mike Eisler will be representing NetApp
> at the next IETF, so a conf call might be a better idea.
> 
> However, to start the conversation: My basic worry about mainlining at
> this point is that I don't want to merge something that will need to
> maintained as a legacy protocol for the benefit of Linux users if in 1
> year, everybody goes off and produces a similar but not quite the
> identical protocol within the NFSv4 minor version framework and the
> IETF.
> 
> IOW: my concern is that I want to do SELinux on NFS once only.
> 
> Cheers
>   Trond

Hello,
    It is after IETF 73 so I figured that I would try to organize our
conference call now for some time next week. I spoke with Mike Eisler,
Lars Eggert and Spencer Shepler and they seem happy from a technical
perspective about what we are proposing. After the meeting I asked them
what I need to do to move forward about getting this added to the
working group charter and they said I need to get support from members
within the working group who are willing to do some of the work in
reviewing the documents. 

    So the main thing I would like to discuss is what would you and
Bruce like to see done that you would feel comfortable publicallty
supporting this work. Since you want to see something more concrete from
the working group before we work on merging code into mainline I need to
start drumming up support as soon as possible. Tim Polk expressed his
support at IETF 72 in Dublin so hopefully he will do that again if I ask
him. We have a few people at Sun who support the work and some people at
Netapp have been getting questions about SELinux support from their
customers so I believe they may be willing as well.


P.S I will be out of the office until Monday so I added my personal
email address to the CC so I can have access to this at home.

Dave


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.