KaiGai Kohei | 1 Apr 02:30 2009
Picon

Re: [RFC] Security policy reworks for SE-PostgreSQL

Chris,

The attached patch also reworks and fixes a few bugs in MLS/MCS policy
for SE-PostgreSQL. Could you check it please?

List of updates:
 * db_catalog, db_schema, db_sequence classes are newly constrained.
 * Removed permissions (db_database:{get_param set_param} and
   db_xxx:{use}) have gone away.
 * bugfix: MCS didn't constrain db_xxx:{getattr} permission.
 * bugfix: MCS didn't constrain db_procedure:{ drop getattr
           setattr relabelfrom } permission.
 * bugfix: MLS didn't constrain writer permission in db_procedure class.

Thanks,

KaiGai Kohei wrote:
> As we have discussed for the recent week, I have a plan to rework
> some of security policy for SE-PostgreSQL.
> 
> The attached patch adds the significan changes, as follows.
> Could you give me any suggestion, approval or opposition?
> 
> New object classes and permissions
> ----------------------------------
>  * db_catalog class
>    It shows the top level namespace in the database, and has a capability
>    to store a set of schemas. Some of implementation does not support
>    catalogs. In this case, we simply ignore this class and any schemas
>    are placed under the db_database directly.
(Continue reading)

KaiGai Kohei | 1 Apr 03:07 2009
Picon

[PATCH] Permissive domain in userspace object manager

This patch enables applications to handle permissive domain correctly.

Since the v2.6.26 kernel, SELinux has supported an idea of permissive
domain which allows certain processes to work as if permissive mode,
even if the global setting is enforcing mode.
However, we don't have an application program interface to inform
what domains are permissive one, and what domains are not.
It means applications focuses on SELinux (XACE/SELinux, SE-PostgreSQL
and so on) cannot handle permissive domain correctly.

This patch add the sixth field (flags) on the reply of the /selinux/access
interface which is used to make an access control decision from userspace.
If the first bit of the flags field is positive, it means the required
access control decision is on permissive domain, so application should
allow any required actions, as the kernel doing.

This patch also has a side benefit. The av_decision.flags is set at
context_struct_compute_av(). It enables to check required permissions
without read_lock(&policy_rwlock).

 Signed-off-by: KaiGai Kohei <kaigai@...>
--
 security/selinux/avc.c              |    2 +-
 security/selinux/include/security.h |    4 +++-
 security/selinux/selinuxfs.c        |    4 ++--
 security/selinux/ss/services.c      |   30 +++++-------------------------
 4 files changed, 11 insertions(+), 29 deletions(-)

diff --git a/security/selinux/avc.c b/security/selinux/avc.c
index 7f9b5fa..b2ab608 100644
(Continue reading)

KaiGai Kohei | 1 Apr 03:41 2009
Picon

Re: [PATCH] Permissive domain in userspace object manager

The attached patch is for libselinux.
Most of part is unchanged from the previous one, expect for manpage.

KaiGai Kohei wrote:
> This patch enables applications to handle permissive domain correctly.
> 
> Since the v2.6.26 kernel, SELinux has supported an idea of permissive
> domain which allows certain processes to work as if permissive mode,
> even if the global setting is enforcing mode.
> However, we don't have an application program interface to inform
> what domains are permissive one, and what domains are not.
> It means applications focuses on SELinux (XACE/SELinux, SE-PostgreSQL
> and so on) cannot handle permissive domain correctly.
> 
> This patch add the sixth field (flags) on the reply of the /selinux/access
> interface which is used to make an access control decision from userspace.
> If the first bit of the flags field is positive, it means the required
> access control decision is on permissive domain, so application should
> allow any required actions, as the kernel doing.
> 
> This patch also has a side benefit. The av_decision.flags is set at
> context_struct_compute_av(). It enables to check required permissions
> without read_lock(&policy_rwlock).
> 
>  Signed-off-by: KaiGai Kohei <kaigai@...>
> --
>  security/selinux/avc.c              |    2 +-
>  security/selinux/include/security.h |    4 +++-
>  security/selinux/selinuxfs.c        |    4 ++--
>  security/selinux/ss/services.c      |   30 +++++-------------------------
(Continue reading)

Jarrett Lu | 1 Apr 05:33 2009
Picon

Re: [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

Nicolas Williams wrote:
> On Mon, Mar 30, 2009 at 10:59:15PM -0700, Jarrett Lu wrote:
>   
>> That's certainly one option. We can say DOI + an opaque field is what we 
>> will add to NFSv4 protocol. Use the information as you see fit. Going 
>>     
>
> That's what David's I-D and what my RPCSEC_GSSv3 I-D both say now.
>   

If we stop here, we don't have much of an interoperability story. I 
thought it is one of the things we are aiming for. We can say "give us 
an opaque field and we (the MAC systems) will decide how and when to use 
it. NFSv4 WG and ADs still want to know how this opaque field may be 
used. They are less willing to hand out "opaque" field just because 
someone asked for one. At least this is the impression I got at IETF74 
in SF.

> It's also what CALIPSO does (except that the label must be MLS and the
> bits on the wire are defined, though the actual sentivity levels and
> compartment naming and mapping to bits is not).
>   

Right. This makes it easier for systems speaking CALIPSO protocol to 
interoperate at IP layer. Compliant hosts and routers know how to deal 
with packets with that option. Label translation between different DOIs 
is out of scope.

>   
>> this route, we basically punt on the label interpretation / translation 
(Continue reading)

Casey Schaufler | 1 Apr 05:42 2009

Re: [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

Nicolas Williams wrote:
> On Mon, Mar 30, 2009 at 08:07:02PM -0700, Casey Schaufler wrote:
>   
>> Not to throw a puppy in the gears, but sophisticated handshaking and
>> negotiation protocols are not the answer. We had TSIG session management
>> for doing that and it is just not enough. How would you negotiate the
>> differences between two SELinux policies?
>>     
>
> You don't.  You either establish that they are the same (or that one or
> both peers are translating to a common policy) or that they are not.  In
> the latter case you fail to communicate further.  It seems quite
> reasonable to me to have a single policy for a site -- that seems doable
> for MLS, but for DTE it's more likely that there will be OS-specific
> parts of a site policy, and the potential need to map between existing
> OS-specific policies and something else seems daunting, at least at
> first glance, but I'm an optimist, so I think it must be doable :)
>   

You only get common policy on a single system image. Oh, with MLS
you can limit it to MLS hosts and unlabeled hosts, but you'll always
have at least the two. Even with MLS you'll have machines that are
disallowed each other's levels and/or categories. This situation
had a major impact on the Smack design, where there is no interpretation
of the label at all.

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
(Continue reading)

James Morris | 1 Apr 08:58 2009

Re: [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

On Tue, 31 Mar 2009, Jarrett Lu wrote:

> I'm in general agreement with you on this. I am not sure to what extent 
> the extensibility stuff makes sense, e.g. how much may be enough? I 
> guess we need to study more use scenarios. I suspect TE systems may have 
> more challenges in this area, just because security policies on TE 
> systems tend to be more flexible. For example, how many things are 
> critical in order to translate label correctly, OS version, vendor, 
> label parser, security policy file? How likely DTE systems are 
> configured with exact same policy files? Does it make sense that a 
> (harmless) update to security policy file causes label translation 
> failures from that point on?

With SELinux systems, policies do not need to be identical to be 
considered part of the same DOI.  Generally, labels need to remain 
semantically equivalent (i.e. mean the same thing on each system), and the 
policies need to be managed within the same administrative boundary. 
Systems may restrict which labels they'll interpret from remote systems 
(similar to root_squash).

- James
--

-- 
James Morris
<jmorris <at> namei.org>
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

(Continue reading)

KaiGai Kohei | 1 Apr 09:26 2009
Picon

Correct manner to handler undefined classes/permissions? (Re: Some ideas in SE-PostgreSQL enhancement)

> 5. Handle unsupported object classes/access vectors
> 
> What is the correct behavior for userspace object managers,
> when it tries to check undefined object classes or access
> vectors?
> 
> For example, we don't define db_database:{superuser} in the
> security policy. We cannot decide whether it is denied, or not.
> How the SE-PostgreSQL should perform for this?
> 
> In the current implementation, it simply ignores undefined
> permissions because string_to_av_perm() cannot return a valid
> access vector.
> 
> One possible idea is it performs according to /selinux/deny_unknown.
> If so, a new interface on libselinux is desirable.

This topic has been left for a week.

How should it be handled when we cannot find required classes or
permissions in the security policy?

The kernel allows anything or nothing for undefined object classes
based on policydb.allow_unknown. However, if the security policy
does not have a definition of the required access vector, it is
always denied (due to lack of explicit permission).

My preference is filling up the undefined access vectores with
policydb.allow_unknown. It seems to me quite natural.

(Continue reading)

Jarrett Lu | 1 Apr 09:46 2009
Picon

Re: [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

On 3/31/2009 7:47 AM, Paul Moore wrote:
On Monday 30 March 2009 11:07:02 pm Casey Schaufler wrote:
Jarrett Lu wrote:
Maybe we can do something better 15 years later. The first step is to figure out how much information is needed and then look into how to get this info across securely. GSS_SEC may be able to help us. To make NFSv4 work, only TCP is needed. So peer information is needed per session vs. per packet, I believe. Evidently, there is more work to do in figuring this all out.
Not to throw a puppy in the gears, but sophisticated handshaking and negotiation protocols are not the answer. We had TSIG session management for doing that and it is just not enough. How would you negotiate the differences between two SELinux policies?
I'm with Casey, I don't think it is worth spending a whole lot of time right now finding out how to pass information across the network in a secure manner. There are plenty of ways of to do that which are well established, interoperable and generally regarded as "secure".

I'm not reinventing another secure way to pass information. I thought kerberos gss api may be a good candidate. I also agree that sophisticated handshaking negotiation protocol or complicated security attribute mapping between various systems is not the way to go.

From my point of view the real issue is how do we translate/resolve security labels defined by DOI X to an internal, security model/policy specific label? Some have mentioned a mechanism which would serve up label encoding data whenever a new system joined the network; unfortunately, I believe this only works when you know the security policy of the system before hand (or can restrict the security policy, after all a TSOL label encodings file will do nothing for SELinux and/or Smack). While I think it is reasonable to assume a limited number of on-the-wire label encodings and DOIs I think it would be a mistake to assume a limited number of security models and or policies.

True. The first question is whether we should try to solve, or at least ease, the label interpretation / translation problem in the context of NFSv4 protocol. I don't know if we can solve it, but it seems worthwhile to explore further, to gain more understanding if nothing else. The challenge of interpreting and translating labels is that one system needs to know a lot of info about its peer. And there is no good way to describe the (sometimes subtle) difference. I think this problem may be harder on DTE systems than on MLS systems, I believe.

Ultimately I believe that the required label translation information (wire/DOI label to internal and the other way around) is going to need to be bundled with the system's security policy and distributed as a single "package". Granted this does require prior knowledge of the DOIs in use but I believe this is a much easier requirement than the opposite. From a practical point of view this isn't too far removed from the notion of sending sending label encoding data upon joining the network, the big difference is that we are sending both security policy and label encoding/DOI-translation data at the same time (in the TSOL case I suspect this would just be the label encoding data, which may mean the original poster had this in mind).

Depending how different the systems are, the "package" content will be different. Assuming we can assemble all the information required to do label translation correctly into a package, passing that around the systems seem inefficient, non-scalable, and probably outside the scope of labeled NFSv4 enhancement. So realistically, I think the DOI + opaque label is useful between very compatible systems. Given that limitation, may be the "package" is small enough and can be passed in RPC layer during authentication so that MLS can share files with like MLS systems, and same is true for DTE, fmac, smack, ....


Jarrett


_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Jarrett Lu | 1 Apr 10:09 2009
Picon

Re: [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

On 3/31/2009 11:58 PM, James Morris wrote:
On Tue, 31 Mar 2009, Jarrett Lu wrote:
I'm in general agreement with you on this. I am not sure to what extent the extensibility stuff makes sense, e.g. how much may be enough? I guess we need to study more use scenarios. I suspect TE systems may have more challenges in this area, just because security policies on TE systems tend to be more flexible. For example, how many things are critical in order to translate label correctly, OS version, vendor, label parser, security policy file? How likely DTE systems are configured with exact same policy files? Does it make sense that a (harmless) update to security policy file causes label translation failures from that point on?
With SELinux systems, policies do not need to be identical to be considered part of the same DOI. Generally, labels need to remain semantically equivalent (i.e. mean the same thing on each system), and the policies need to be managed within the same administrative boundary. Systems may restrict which labels they'll interpret from remote systems (similar to root_squash).

Understood. My point is that a signature on a policy file may not always be the right tool to determine whether label translation should be done. When policies are different on two systems, how does one system know labels or types are semantically equivalent or not? Are you also saying that DOI is tied to administrative boundary, and the fact that systems using the same DOI implies the label and type definitions in each policy are always semantically equivalent?


Jarrett

- James

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
James Morris | 1 Apr 11:49 2009

Re: [Labeled-nfs] New MAC label support Internet Draft posted to IETF website

On Wed, 1 Apr 2009, Jarrett Lu wrote:

> > With SELinux systems, policies do not need to be identical to be
> > considered part of the same DOI.  Generally, labels need to remain
> > semantically equivalent (i.e. mean the same thing on each system), and the
> > policies need to be managed within the same administrative boundary.
> > Systems may restrict which labels they'll interpret from remote systems
> > (similar to root_squash).
> > 
> >    
> 
> Understood. My point is that a signature on a policy file may not always be
> the right tool to determine whether label translation should be done. When
> policies are different on two systems, how does one system know labels or
> types are semantically equivalent or not?

This should be determined via the DOI.

> Are you also saying that DOI is tied
> to administrative boundary, and the fact that systems using the same DOI
> implies the label and type definitions in each policy are always semantically
> equivalent?

For DOIs designed to function like this, yes.  i.e. it's not a property 
inherent to DOIs, but of how they're administered.

- James
--

-- 
James Morris
<jmorris <at> namei.org>
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4


Gmane