Where to specific the handling of unknown kernel classes and perms

Where to specific the handling of unknown kernel classes and perms

[Eric Paris]

I just sent out a kernel patch with the tristate flag to change kernel
handling of unknown classes and permissions.  The idea is that when the
policy is created someone can set the flag to any of the three options
(deny/reject/allow) and the kernel will act accordingly.  My problem is
I don't understand the userspace tools which create policy.  I patched
libsepol to support this new flag when it reads or writes a policydb,
which allows me to edit my policy.21 by hand in hex and then call
load_policy to test my kernel.  My problem now is that I don't know
where a user should be specifying how they want the flags to be set.  To
be perfectly honest after a bit of searching I'm not even sure where
policy.21 gets created when I build a policy.

So really I'm just looking for a pointer on what now-a-days creates that
policy.21 which gets loaded on boot up and where in the whole policy
build process would be the best place to specify how the policy should
handle unknowns.  I figure somewhere on some command line I need to add
some --handle-unknown=accept (or other such option) to the build
process, but I don't even know what program would be the right one to
process that input.....

-Eric

(patch for libsepol below)

diff -Naupr libsepol-2.0.3/include/sepol/policydb/policydb.h libsepol-2.0.3.handle_unknown/include/sepol/policydb/policydb.h
--- libsepol-2.0.3/include/sepol/policydb/policydb.h	2007-04-17 08:34:08.000000000 -0400
+++ libsepol-2.0.3.handle_unknown/include/sepol/policydb/policydb.h	2007-04-27 15:29:30.000000000 -0400
@@ -469,6 +469,8 @@ typedef struct policydb {
 	ebitmap_t *attr_type_map;	/* not saved in the binary policy */
 
 	unsigned policyvers;
+
+	unsigned handle_unknown;
 } policydb_t;
 
 struct sepol_policydb {
@@ -599,6 +601,15 @@ extern int policydb_write(struct policyd
 
 #define POLICYDB_CONFIG_MLS    1
 
+/* the config flags related to unknown classes/perms are bits 2 and 3 */
+#define POLICYDB_CONFIG_UNKNOWN_MASK   6
+#define POLICYDB_CONFIG_UNKNOWN_SHIFT  1
+
+enum policy_with_unknown_perms {
+	 DENY_UNKNOWN = 0,
+	 REJECT_UNKNOWN = 1,
+	 ALLOW_UNKNOWN = 2
+};
 #define OBJECT_R "object_r"
 #define OBJECT_R_VAL 1
 
--- libsepol-2.0.3/src/policydb.c	2007-04-17 08:34:08.000000000 -0400
+++ libsepol-2.0.3.handle_unknown/src/policydb.c	2007-05-02 14:35:13.000000000 -0400
@@ -3057,6 +3057,9 @@ int policydb_read(policydb_t * p, struct
 		p->mls = 0;
 	}
 
+	p->handle_unknown = buf[bufindex] & POLICYDB_CONFIG_UNKNOWN_MASK;
+	p->handle_unknown = p->handle_unknown >>= POLICYDB_CONFIG_UNKNOWN_SHIFT;
+
 	bufindex++;
 
 	info = policydb_lookup_compat(r_policyvers, policy_type);
diff -Naupr libsepol-2.0.3/src/write.c libsepol-2.0.3.handle_unknown/src/write.c
--- libsepol-2.0.3/src/write.c	2007-04-17 08:34:08.000000000 -0400
+++ libsepol-2.0.3.handle_unknown/src/write.c	2007-04-27 15:41:17.000000000 -0400
@@ -1533,6 +1533,9 @@ int policydb_write(policydb_t * p, struc
 	config = 0;
 	if (p->mls)
 		config |= POLICYDB_CONFIG_MLS;
+	i = POLICYDB_CONFIG_UNKNOWN_MASK & (p->handle_unknown << POLICYDB_CONFIG_UNKNOWN_SHIFT);
+	if (i)
+		config |= i;
 
 	/* Write the magic number and string identifiers. */
 	items = 0;



--
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: Where to specific the handling of unknown kernel classes and perms

[Joshua Brindle]

Eric Paris wrote:
> I just sent out a kernel patch with the tristate flag to change kernel
> handling of unknown classes and permissions.  The idea is that when the
> policy is created someone can set the flag to any of the three options
> (deny/reject/allow) and the kernel will act accordingly.  My problem is
> I don't understand the userspace tools which create policy.  I patched
> libsepol to support this new flag when it reads or writes a policydb,
> which allows me to edit my policy.21 by hand in hex and then call
> load_policy to test my kernel.  My problem now is that I don't know
> where a user should be specifying how they want the flags to be set.  To
> be perfectly honest after a bit of searching I'm not even sure where
> policy.21 gets created when I build a policy.
>
>   
It should be setable in semanage.conf or by checkpolicy if building a 
monolithic policy.

> So really I'm just looking for a pointer on what now-a-days creates that
> policy.21 which gets loaded on boot up and where in the whole policy
> build process would be the best place to specify how the policy should
> handle unknowns.  I figure somewhere on some command line I need to add
> some --handle-unknown=accept (or other such option) to the build
> process, but I don't even know what program would be the right one to
> process that input.....
>
>   
So... when you add a module to your policy (eg., semodule -i foo.pp) 
libsemanage eventually calls sepol_link_packages and 
sepol_expand_module. sepol_expand_module is where the policy that is 
written to disk and loaded at bootup is created.

If you look semanage_store.c in the semanage_expand_sandbox function 
you'll see:

        int policyvers = sh->conf->policyvers;
        if (sepol_policydb_set_vers(out, policyvers)) {

where out is the new policy being created. It should be pretty simple to 
add a new option to the semanage conf struct and conf parser and add a 
call in this function to set the option.

In checkpolicy.c policy options are set directly (since its statically 
linked against libsepol):

                policydb.policy_type = POLICY_KERN;
                policydb.policyvers = policyvers;

look for those lines and your option should go there.
> -Eric
>
> (patch for libsepol below)
>
> diff -Naupr libsepol-2.0.3/include/sepol/policydb/policydb.h libsepol-2.0.3.handle_unknown/include/sepol/policydb/policydb.h
> --- libsepol-2.0.3/include/sepol/policydb/policydb.h	2007-04-17 08:34:08.000000000 -0400
> +++ libsepol-2.0.3.handle_unknown/include/sepol/policydb/policydb.h	2007-04-27 15:29:30.000000000 -0400
> @@ -469,6 +469,8 @@ typedef struct policydb {
>  	ebitmap_t *attr_type_map;	/* not saved in the binary policy */
>  
>  	unsigned policyvers;
> +
> +	unsigned handle_unknown;
>  } policydb_t;
>  
>  struct sepol_policydb {
> @@ -599,6 +601,15 @@ extern int policydb_write(struct policyd
>  
>  #define POLICYDB_CONFIG_MLS    1
>  
> +/* the config flags related to unknown classes/perms are bits 2 and 3 */
> +#define POLICYDB_CONFIG_UNKNOWN_MASK   6
> +#define POLICYDB_CONFIG_UNKNOWN_SHIFT  1
> +
> +enum policy_with_unknown_perms {
> +	 DENY_UNKNOWN = 0,
> +	 REJECT_UNKNOWN = 1,
> +	 ALLOW_UNKNOWN = 2
> +};
>  #define OBJECT_R "object_r"
>  #define OBJECT_R_VAL 1
>  
> --- libsepol-2.0.3/src/policydb.c	2007-04-17 08:34:08.000000000 -0400
> +++ libsepol-2.0.3.handle_unknown/src/policydb.c	2007-05-02 14:35:13.000000000 -0400
> @@ -3057,6 +3057,9 @@ int policydb_read(policydb_t * p, struct
>  		p->mls = 0;
>  	}
>  
> +	p->handle_unknown = buf[bufindex] & POLICYDB_CONFIG_UNKNOWN_MASK;
> +	p->handle_unknown = p->handle_unknown >>= POLICYDB_CONFIG_UNKNOWN_SHIFT;
> +
>  	bufindex++;
>  
>  	info = policydb_lookup_compat(r_policyvers, policy_type);
> diff -Naupr libsepol-2.0.3/src/write.c libsepol-2.0.3.handle_unknown/src/write.c
> --- libsepol-2.0.3/src/write.c	2007-04-17 08:34:08.000000000 -0400
> +++ libsepol-2.0.3.handle_unknown/src/write.c	2007-04-27 15:41:17.000000000 -0400
> @@ -1533,6 +1533,9 @@ int policydb_write(policydb_t * p, struc
>  	config = 0;
>  	if (p->mls)
>  		config |= POLICYDB_CONFIG_MLS;
> +	i = POLICYDB_CONFIG_UNKNOWN_MASK & (p->handle_unknown << POLICYDB_CONFIG_UNKNOWN_SHIFT);
> +	if (i)
> +		config |= i;
>  
>  	/* Write the magic number and string identifiers. */
>  	items = 0;
>
>
>
>   


--
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: Where to specific the handling of unknown kernel classes and perms

[Joshua Brindle]

Eric Paris wrote:
> I just sent out a kernel patch with the tristate flag to change kernel
> handling of unknown classes and permissions.  The idea is that when the
> policy is created someone can set the flag to any of the three options
> (deny/reject/allow) and the kernel will act accordingly.  My problem is
> I don't understand the userspace tools which create policy.  I patched
> libsepol to support this new flag when it reads or writes a policydb,
> which allows me to edit my policy.21 by hand in hex and then call
> load_policy to test my kernel.  My problem now is that I don't know
> where a user should be specifying how they want the flags to be set.  To
> be perfectly honest after a bit of searching I'm not even sure where
> policy.21 gets created when I build a policy.
>
> So really I'm just looking for a pointer on what now-a-days creates that
> policy.21 which gets loaded on boot up and where in the whole policy
> build process would be the best place to specify how the policy should
> handle unknowns.  I figure somewhere on some command line I need to add
> some --handle-unknown=accept (or other such option) to the build
> process, but I don't even know what program would be the right one to
> process that input.....
>
> -Eric
>
> (patch for libsepol below)
>
> diff -Naupr libsepol-2.0.3/include/sepol/policydb/policydb.h libsepol-2.0.3.handle_unknown/include/sepol/policydb/policydb.h
> --- libsepol-2.0.3/include/sepol/policydb/policydb.h	2007-04-17 08:34:08.000000000 -0400
> +++ libsepol-2.0.3.handle_unknown/include/sepol/policydb/policydb.h	2007-04-27 15:29:30.000000000 -0400
> @@ -469,6 +469,8 @@ typedef struct policydb {
>  	ebitmap_t *attr_type_map;	/* not saved in the binary policy */
>  
>  	unsigned policyvers;
> +
> +	unsigned handle_unknown;
>  } policydb_t;
>  
>  struct sepol_policydb {
> @@ -599,6 +601,15 @@ extern int policydb_write(struct policyd
>  
>  #define POLICYDB_CONFIG_MLS    1
>  
> +/* the config flags related to unknown classes/perms are bits 2 and 3 */
> +#define POLICYDB_CONFIG_UNKNOWN_MASK   6
>   
it would be easier to understand if unknown perms options were #defined 
and the mask was just all of them or'd together
> +#define POLICYDB_CONFIG_UNKNOWN_SHIFT  1
> +
>   
not sure why it would ever move and if you make the perms into defines 
this wouldn't be necessary.

> +enum policy_with_unknown_perms {
> +	 DENY_UNKNOWN = 0,
> +	 REJECT_UNKNOWN = 1,
> +	 ALLOW_UNKNOWN = 2
> +};
>   
for better or worse we don't use enums in this library.
>  #define OBJECT_R "object_r"
>  #define OBJECT_R_VAL 1
>  
> --- libsepol-2.0.3/src/policydb.c	2007-04-17 08:34:08.000000000 -0400
> +++ libsepol-2.0.3.handle_unknown/src/policydb.c	2007-05-02 14:35:13.000000000 -0400
> @@ -3057,6 +3057,9 @@ int policydb_read(policydb_t * p, struct
>  		p->mls = 0;
>  	}
>  
> +	p->handle_unknown = buf[bufindex] & POLICYDB_CONFIG_UNKNOWN_MASK;
> +	p->handle_unknown = p->handle_unknown >>= POLICYDB_CONFIG_UNKNOWN_SHIFT;
> +
>  	bufindex++;
>  
>  	info = policydb_lookup_compat(r_policyvers, policy_type);
> diff -Naupr libsepol-2.0.3/src/write.c libsepol-2.0.3.handle_unknown/src/write.c
> --- libsepol-2.0.3/src/write.c	2007-04-17 08:34:08.000000000 -0400
> +++ libsepol-2.0.3.handle_unknown/src/write.c	2007-04-27 15:41:17.000000000 -0400
> @@ -1533,6 +1533,9 @@ int policydb_write(policydb_t * p, struc
>  	config = 0;
>  	if (p->mls)
>  		config |= POLICYDB_CONFIG_MLS;
> +	i = POLICYDB_CONFIG_UNKNOWN_MASK & (p->handle_unknown << POLICYDB_CONFIG_UNKNOWN_SHIFT);
> +	if (i)
> +		config |= i;
>   
again, this would be easier to read if you used defines for the options
>  
>  	/* Write the magic number and string identifiers. */
>  	items = 0;
>
>
>
> --
> 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.
>
>   


--
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: Where to specific the handling of unknown kernel classes and perms

[Karl MacMillan]

On Wed, 2007-05-02 at 20:46 -0400, Joshua Brindle wrote:
> Eric Paris wrote:
> > I just sent out a kernel patch with the tristate flag to change kernel
> > handling of unknown classes and permissions.  The idea is that when the
> > policy is created someone can set the flag to any of the three options
> > (deny/reject/allow) and the kernel will act accordingly.  My problem is
> > I don't understand the userspace tools which create policy.  I patched
> > libsepol to support this new flag when it reads or writes a policydb,
> > which allows me to edit my policy.21 by hand in hex and then call
> > load_policy to test my kernel.  My problem now is that I don't know
> > where a user should be specifying how they want the flags to be set.  To
> > be perfectly honest after a bit of searching I'm not even sure where
> > policy.21 gets created when I build a policy.
> >
> >   
> It should be setable in semanage.conf or by checkpolicy if building a 
> monolithic policy.
> 

The other option, I guess, is to set the flag on the base module and
have that propagated to the kernel policy.

Karl


--
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: Where to specific the handling of unknown kernel classes and perms

[Stephen Smalley]

On Wed, 2007-05-02 at 20:46 -0400, Joshua Brindle wrote:
> Eric Paris wrote:
> > I just sent out a kernel patch with the tristate flag to change kernel
> > handling of unknown classes and permissions.  The idea is that when the
> > policy is created someone can set the flag to any of the three options
> > (deny/reject/allow) and the kernel will act accordingly.  My problem is
> > I don't understand the userspace tools which create policy.  I patched
> > libsepol to support this new flag when it reads or writes a policydb,
> > which allows me to edit my policy.21 by hand in hex and then call
> > load_policy to test my kernel.  My problem now is that I don't know
> > where a user should be specifying how they want the flags to be set.  To
> > be perfectly honest after a bit of searching I'm not even sure where
> > policy.21 gets created when I build a policy.
> >
> >   
> It should be setable in semanage.conf or by checkpolicy if building a 
> monolithic policy.

Hmm...actually, I would have argued that it should only be settable by
checkpolicy/checkmodule, and always inherited from the base module in
the link/expand case.  That way we can always know what the kernel
behavior is by looking at the base module, vs. having to separately look
at semanage.conf.  It is a tradeoff though in terms of analyzability vs.
ease of customization.

-- 
Stephen Smalley
National Security Agency


--
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: Where to specific the handling of unknown kernel classes and perms

[Joshua Brindle]

Stephen Smalley wrote:
> On Wed, 2007-05-02 at 20:46 -0400, Joshua Brindle wrote:
>   
>> Eric Paris wrote:
>>     
>>> I just sent out a kernel patch with the tristate flag to change kernel
>>> handling of unknown classes and permissions.  The idea is that when the
>>> policy is created someone can set the flag to any of the three options
>>> (deny/reject/allow) and the kernel will act accordingly.  My problem is
>>> I don't understand the userspace tools which create policy.  I patched
>>> libsepol to support this new flag when it reads or writes a policydb,
>>> which allows me to edit my policy.21 by hand in hex and then call
>>> load_policy to test my kernel.  My problem now is that I don't know
>>> where a user should be specifying how they want the flags to be set.  To
>>> be perfectly honest after a bit of searching I'm not even sure where
>>> policy.21 gets created when I build a policy.
>>>
>>>   
>>>       
>> It should be setable in semanage.conf or by checkpolicy if building a 
>> monolithic policy.
>>     
>
> Hmm...actually, I would have argued that it should only be settable by
> checkpolicy/checkmodule, and always inherited from the base module in
> the link/expand case.  That way we can always know what the kernel
> behavior is by looking at the base module, vs. having to separately look
> at semanage.conf.  It is a tradeoff though in terms of analyzability vs.
> ease of customization
Even if it is propagated from the base policy I think it should be 
overridable in semanage.conf. Propagating it from base means we'll have 
to extend the policy server object model to cover it but that is no big 
deal. The reason semanage.conf would be nice is to change the behavior 
locally on RH systems without rebuilding the base policy.

--
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: Where to specific the handling of unknown kernel classes and perms

[Stephen Smalley]

On Thu, 2007-05-03 at 09:20 -0400, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Wed, 2007-05-02 at 20:46 -0400, Joshua Brindle wrote:
> >   
> >> Eric Paris wrote:
> >>     
> >>> I just sent out a kernel patch with the tristate flag to change kernel
> >>> handling of unknown classes and permissions.  The idea is that when the
> >>> policy is created someone can set the flag to any of the three options
> >>> (deny/reject/allow) and the kernel will act accordingly.  My problem is
> >>> I don't understand the userspace tools which create policy.  I patched
> >>> libsepol to support this new flag when it reads or writes a policydb,
> >>> which allows me to edit my policy.21 by hand in hex and then call
> >>> load_policy to test my kernel.  My problem now is that I don't know
> >>> where a user should be specifying how they want the flags to be set.  To
> >>> be perfectly honest after a bit of searching I'm not even sure where
> >>> policy.21 gets created when I build a policy.
> >>>
> >>>   
> >>>       
> >> It should be setable in semanage.conf or by checkpolicy if building a 
> >> monolithic policy.
> >>     
> >
> > Hmm...actually, I would have argued that it should only be settable by
> > checkpolicy/checkmodule, and always inherited from the base module in
> > the link/expand case.  That way we can always know what the kernel
> > behavior is by looking at the base module, vs. having to separately look
> > at semanage.conf.  It is a tradeoff though in terms of analyzability vs.
> > ease of customization
> Even if it is propagated from the base policy I think it should be 
> overridable in semanage.conf. Propagating it from base means we'll have 
> to extend the policy server object model to cover it but that is no big 
> deal. The reason semanage.conf would be nice is to change the behavior 
> locally on RH systems without rebuilding the base policy.

I understand that, but as semanage.conf is not "managed" (just a config
file to rpm and not managed by libsemanage itself) and changes to it are
not audited, this means that you won't be able to tell easily what
behavior was in effect at a given time.  That's the tradeoff.

Regardless, for Eric's purposes, it would be sufficient for basic
operation to add a command line flag to checkpolicy and checkmodule to
set these flags in monolithic policy and base modules, and to modify
libsepol (in particular, expand_module()) to propagate the base flags in
the same manner as it already does for the mls flag.  Then he or we can
separately add a libsepol interface to mutate the flag and modify
libsemanage to use that interface and have a new semanage.conf setting.

-- 
Stephen Smalley
National Security Agency


--
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: Where to specific the handling of unknown kernel classes and perms

[Joshua Brindle]

Stephen Smalley wrote:
> On Thu, 2007-05-03 at 09:20 -0400, Joshua Brindle wrote:
>   
>> Stephen Smalley wrote:
>>     
>>> On Wed, 2007-05-02 at 20:46 -0400, Joshua Brindle wrote:
>>>   
>>>       
>>>> Eric Paris wrote:
>>>>     
>>>>         
>>>>> I just sent out a kernel patch with the tristate flag to change kernel
>>>>> handling of unknown classes and permissions.  The idea is that when the
>>>>> policy is created someone can set the flag to any of the three options
>>>>> (deny/reject/allow) and the kernel will act accordingly.  My problem is
>>>>> I don't understand the userspace tools which create policy.  I patched
>>>>> libsepol to support this new flag when it reads or writes a policydb,
>>>>> which allows me to edit my policy.21 by hand in hex and then call
>>>>> load_policy to test my kernel.  My problem now is that I don't know
>>>>> where a user should be specifying how they want the flags to be set.  To
>>>>> be perfectly honest after a bit of searching I'm not even sure where
>>>>> policy.21 gets created when I build a policy.
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>> It should be setable in semanage.conf or by checkpolicy if building a 
>>>> monolithic policy.
>>>>     
>>>>         
>>> Hmm...actually, I would have argued that it should only be settable by
>>> checkpolicy/checkmodule, and always inherited from the base module in
>>> the link/expand case.  That way we can always know what the kernel
>>> behavior is by looking at the base module, vs. having to separately look
>>> at semanage.conf.  It is a tradeoff though in terms of analyzability vs.
>>> ease of customization
>>>       
>> Even if it is propagated from the base policy I think it should be 
>> overridable in semanage.conf. Propagating it from base means we'll have 
>> to extend the policy server object model to cover it but that is no big 
>> deal. The reason semanage.conf would be nice is to change the behavior 
>> locally on RH systems without rebuilding the base policy.
>>     
>
> I understand that, but as semanage.conf is not "managed" (just a config
> file to rpm and not managed by libsemanage itself) and changes to it are
> not audited, this means that you won't be able to tell easily what
> behavior was in effect at a given time.  That's the tradeoff.
>
> Regardless, for Eric's purposes, it would be sufficient for basic
> operation to add a command line flag to checkpolicy and checkmodule to
> set these flags in monolithic policy and base modules, and to modify
> libsepol (in particular, expand_module()) to propagate the base flags in
> the same manner as it already does for the mls flag.  Then he or we can
> separately add a libsepol interface to mutate the flag and modify
> libsemanage to use that interface and have a new semanage.conf setting.
>
>   

Ok, I agree, we can work out how to change it on end systems without 
rebuilding the policy later. This should certainly be a managed setting 
so that we can enforce access control on it and audit if necessary.

--
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: Where to specific the handling of unknown kernel classes and perms

[Daniel J Walsh]

Joshua Brindle wrote:
> Stephen Smalley wrote:
>> On Thu, 2007-05-03 at 09:20 -0400, Joshua Brindle wrote:
>>  
>>> Stephen Smalley wrote:
>>>    
>>>> On Wed, 2007-05-02 at 20:46 -0400, Joshua Brindle wrote:
>>>>        
>>>>> Eric Paris wrote:
>>>>>            
>>>>>> I just sent out a kernel patch with the tristate flag to change 
>>>>>> kernel
>>>>>> handling of unknown classes and permissions.  The idea is that 
>>>>>> when the
>>>>>> policy is created someone can set the flag to any of the three 
>>>>>> options
>>>>>> (deny/reject/allow) and the kernel will act accordingly.  My 
>>>>>> problem is
>>>>>> I don't understand the userspace tools which create policy.  I 
>>>>>> patched
>>>>>> libsepol to support this new flag when it reads or writes a 
>>>>>> policydb,
>>>>>> which allows me to edit my policy.21 by hand in hex and then call
>>>>>> load_policy to test my kernel.  My problem now is that I don't know
>>>>>> where a user should be specifying how they want the flags to be 
>>>>>> set.  To
>>>>>> be perfectly honest after a bit of searching I'm not even sure where
>>>>>> policy.21 gets created when I build a policy.
>>>>>>
>>>>>>                   
>>>>> It should be setable in semanage.conf or by checkpolicy if 
>>>>> building a monolithic policy.
>>>>>             
>>>> Hmm...actually, I would have argued that it should only be settable by
>>>> checkpolicy/checkmodule, and always inherited from the base module in
>>>> the link/expand case.  That way we can always know what the kernel
>>>> behavior is by looking at the base module, vs. having to separately 
>>>> look
>>>> at semanage.conf.  It is a tradeoff though in terms of 
>>>> analyzability vs.
>>>> ease of customization
>>>>       
>>> Even if it is propagated from the base policy I think it should be 
>>> overridable in semanage.conf. Propagating it from base means we'll 
>>> have to extend the policy server object model to cover it but that 
>>> is no big deal. The reason semanage.conf would be nice is to change 
>>> the behavior locally on RH systems without rebuilding the base policy.
>>>     
>>
>> I understand that, but as semanage.conf is not "managed" (just a config
>> file to rpm and not managed by libsemanage itself) and changes to it are
>> not audited, this means that you won't be able to tell easily what
>> behavior was in effect at a given time.  That's the tradeoff.
>>
>> Regardless, for Eric's purposes, it would be sufficient for basic
>> operation to add a command line flag to checkpolicy and checkmodule to
>> set these flags in monolithic policy and base modules, and to modify
>> libsepol (in particular, expand_module()) to propagate the base flags in
>> the same manner as it already does for the mls flag.  Then he or we can
>> separately add a libsepol interface to mutate the flag and modify
>> libsemanage to use that interface and have a new semanage.conf setting.
>>
>>   
>
> Ok, I agree, we can work out how to change it on end systems without 
> rebuilding the policy later. This should certainly be a managed 
> setting so that we can enforce access control on it and audit if 
> necessary.
>
> -- 
> 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.
Is this possible to be a boolean?  Tunable eventually.

--
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: Where to specific the handling of unknown kernel classes and perms

[Karl MacMillan]

On Fri, 2007-05-04 at 11:37 -0400, Daniel J Walsh wrote:
> Joshua Brindle wrote:
> > Stephen Smalley wrote:

<snip>

> >
> > Ok, I agree, we can work out how to change it on end systems without 
> > rebuilding the policy later. This should certainly be a managed 
> > setting so that we can enforce access control on it and audit if 
> > necessary.
> >

<snip>

> Is this possible to be a boolean?  Tunable eventually.
> 

Nope - but it could be an semanage command eventually (which would be
nice since it would generate audit messages).

Karl


--
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: Where to specific the handling of unknown kernel classes and perms

[Daniel J Walsh]

Karl MacMillan wrote:
> On Fri, 2007-05-04 at 11:37 -0400, Daniel J Walsh wrote:
>   
>> Joshua Brindle wrote:
>>     
>>> Stephen Smalley wrote:
>>>       
>
> <snip>
>
>   
>>> Ok, I agree, we can work out how to change it on end systems without 
>>> rebuilding the policy later. This should certainly be a managed 
>>> setting so that we can enforce access control on it and audit if 
>>> necessary.
>>>
>>>       
>
> <snip>
>
>   
>> Is this possible to be a boolean?  Tunable eventually.
>>
>>     
>
> Nope - but it could be an semanage command eventually (which would be
> nice since it would generate audit messages).
>
> Karl
>
>   
Ok my question stunk.  The real question is can we make it easy for the 
user
semanage kernel_deny_unknown=1
Which rebuilds and reloads policy.



--
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.