Loading things into policy

Loading things into policy

[Ivan Gyurdiev]

So, I have a question regarding customizations to policy.

I plan to support those functions in all databases:
add() - add a new thing, or fail if it exists
           (maybe add a configurable parameter saying whether we should 
fail, or only warn if it exists)
modify() - add a new thing, or modify it if it exists

In addition, I'm thinking of adding:
set() - modify a thing, but don't add it if it doesn't exist (for booleans).

=====================

Which of those functions should be used to load things into policy?  
Should the load function be configurable per database? That way we can 
specify whether each database allows overrides of the in-policy 
defaults, or adding new things..etc.

For example, for ports only additive changes make sense to me, so we 
could make add() as the default load function. For booleans we want 
set() to be the default function...etc.. Maybe for users we want to 
allow overrides as well?

Should I even support all of them at the sepol layer? It might be 
simpler to just support the one that gets used for loading in sepol, 
since policy modifications will be done by rebuilding the policy anyway, 
so a single load function will be used for modifications. Then 
libsemanage could support the others on the flat file (but the 
modification gets applied to policy by rebuilding, and calling the 
default load function). Thoughts?

--
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: Loading things into policy

[Ivan Gyurdiev]

Oh... and if we'll only be loading things into the policy by rebuilding, 
should I drop the del_user function from sepol?
(and either the add or modify one?)

If we only support one type of load function - should be called "load," 
or should it correspond to the semanage definition (add vs modify vs 
set)? I sent a patch that renamed things to the specific name some time 
ago, but I can change that back if you prefer (but there's not much 
point to changing things back and forth - maybe specific name is better).


--
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: Loading things into policy

[Joshua Brindle]

Ivan Gyurdiev wrote:
> So, I have a question regarding customizations to policy.
> 
> I plan to support those functions in all databases:
> add() - add a new thing, or fail if it exists
>           (maybe add a configurable parameter saying whether we should 
> fail, or only warn if it exists)
> modify() - add a new thing, or modify it if it exists
> 
> In addition, I'm thinking of adding:
> set() - modify a thing, but don't add it if it doesn't exist (for 
> booleans).
> 

these seem sufficient, I'm not sure if they are all totally necessary, 
this seems like a huge amount of complexity for a relatively simple 
problem (adding and removing fields from a flat text file)

> 
> Which of those functions should be used to load things into policy?  
> Should the load function be configurable per database? That way we can 
> specify whether each database allows overrides of the in-policy 
> defaults, or adding new things..etc.
> 
IMO the files should just be written at commit time, whatever is in the 
database at that time is what gets put into the files and thus what gets 
added to the file during linking/expanded.

> For example, for ports only additive changes make sense to me, so we 
> could make add() as the default load function. For booleans we want 
> set() to be the default function...etc.. Maybe for users we want to 
> allow overrides as well?
> 
What if you want to change a port that is already in your local.ports 
file? How do you prioritize ports in the base policy and in local.ports? 
How do you handle port ranges?

BTW, this is why I don't think the policydb databases are helpful. You 
shouldn't be modifying anything inside a module (including the base 
module) The only reason they are helpful is for querying and I'm not 
sure why you'd want to query the base policy, if you want to change a 
port context you want to change it regardless of what the base policy 
has. Querying for what the base policy has in order to decide whether to 
change it via ports.local isn't ideal because a subsequent base module 
upgrade could change the port definition.

> Should I even support all of them at the sepol layer? It might be 
> simpler to just support the one that gets used for loading in sepol, 
> since policy modifications will be done by rebuilding the policy anyway, 
> so a single load function will be used for modifications. Then 
> libsemanage could support the others on the flat file (but the 
> modification gets applied to policy by rebuilding, and calling the 
> default load function). Thoughts?
> 

I have no idea what the above paragraph says. Any local modifications 
(booleans, users.local, ports.local) are applied on rebuild at probably 
expand time. I'm not sure what the others are you are refering to.

--
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: Loading things into policy

[Ivan Gyurdiev]

>> So, I have a question regarding customizations to policy.
>>
>> I plan to support those functions in all databases:
>> add() - add a new thing, or fail if it exists
>>           (maybe add a configurable parameter saying whether we 
>> should fail, or only warn if it exists)
>> modify() - add a new thing, or modify it if it exists
>>
>> In addition, I'm thinking of adding:
>> set() - modify a thing, but don't add it if it doesn't exist (for 
>> booleans).
>>
>
> these seem sufficient, I'm not sure if they are all totally necessary, 
> this seems like a huge amount of complexity for a relatively simple 
> problem (adding and removing fields from a flat text file)
They're not entirely necessary, since one can usually be implemented in 
terms of the others... However, I think it's better if they're all 
implemented, since they can usually be implemented better when you know 
how the backend works. There is absolutely no "huge amount of 
complexity" added, and there's no guarantee that you'll be working with 
a flat text file in the future.

>> Which of those functions should be used to load things into policy?  
>> Should the load function be configurable per database? That way we 
>> can specify whether each database allows overrides of the in-policy 
>> defaults, or adding new things..etc.
>>
> IMO the files should just be written at commit time, whatever is in 
> the database at that time is what gets put into the files and thus 
> what gets added to the file during linking/expanded.
There's two databases, which have to be synchronized. One is a file, the 
other is a policy object, constructed from modules.
The question is whether things in the file should be overriding things 
in the policy.
>> For example, for ports only additive changes make sense to me, so we 
>> could make add() as the default load function. For booleans we want 
>> set() to be the default function...etc.. Maybe for users we want to 
>> allow overrides as well?
>>
> What if you want to change a port that is already in your local.ports 
> file? 
That won't be a problem - overriding things in the FILE is allowed 
(that's why I have all those functions above).
> How do you prioritize ports in the base policy and in local.ports?
That was the question I was asking - should we disallow conflicting 
changes in local.ports that modify base?
> How do you handle port ranges?
Port ranges will be a problem - I currently match any port within the 
range with the range. That's fine for queries, but probably not what you 
want for modifications - I'd have to think about that a bit more.

> BTW, this is why I don't think the policydb databases are helpful. You 
> shouldn't be modifying anything inside a module (including the base 
> module)
I need at least one function to be called internally on commit to do 
loading... Also, we might decide to allow modifications to a module 
outside commit at some point - I'd have to think about usage scenarios.

> The only reason they are helpful is for querying and I'm not sure why 
> you'd want to query the base policy, if you want to change a port 
> context you want to change it regardless of what the base policy has.
The policy is stored in a binary format, which is not particularly 
user-friendly. An admin might want to look and see what is it, exactly, 
that policy is doing. An analysis program might want to get information 
about the policy. imho, it's very useful to have policy query functions.

>> Should I even support all of them at the sepol layer? It might be 
>> simpler to just support the one that gets used for loading in sepol, 
>> since policy modifications will be done by rebuilding the policy 
>> anyway, so a single load function will be used for modifications. 
>> Then libsemanage could support the others on the flat file (but the 
>> modification gets applied to policy by rebuilding, and calling the 
>> default load function). Thoughts?
>>
>
> I have no idea what the above paragraph says. Any local modifications 
> (booleans, users.local, ports.local) are applied on rebuild at 
> probably expand time. I'm not sure what the others are you are 
> refering to.
I am saying... should I have a single function in sepol to load objects 
into policy...or multiple ones. Having a single function seems like the 
way to go, especially since, at the moment we'll only be using one 
function (since changes rebuild 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: Loading things into policy

[Stephen Smalley]

On Wed, 2005-10-19 at 12:31 -0400, Ivan Gyurdiev wrote:
> I am saying... should I have a single function in sepol to load objects 
> into policy...or multiple ones. Having a single function seems like the 
> way to go, especially since, at the moment we'll only be using one 
> function (since changes rebuild policy).

Yes, this makes sense to me - ignore my first response.
And I would tend to think that we would want the add-or-modify behavior
in all cases other than booleans (interfaces, ports, users), with the
modify-only-if-exists behavior for booleans.

-- 
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: Loading things into policy

[Stephen Smalley]

On Tue, 2005-10-18 at 20:33 -0400, Ivan Gyurdiev wrote:
> So, I have a question regarding customizations to policy.
> 
> I plan to support those functions in all databases:
> add() - add a new thing, or fail if it exists
>            (maybe add a configurable parameter saying whether we should 
> fail, or only warn if it exists)
> modify() - add a new thing, or modify it if it exists
> 
> In addition, I'm thinking of adding:
> set() - modify a thing, but don't add it if it doesn't exist (for booleans).

add() and set() as described above seem to be fundamental primitives;
modify() seems optional as it can be constructed by the caller from the
other two, i.e. if (add() < 0 && errno == EEXIST) { set(); }.

> Which of those functions should be used to load things into policy?  
> Should the load function be configurable per database? That way we can 
> specify whether each database allows overrides of the in-policy 
> defaults, or adding new things..etc.
> 
> For example, for ports only additive changes make sense to me, so we 
> could make add() as the default load function. For booleans we want 
> set() to be the default function...etc.. Maybe for users we want to 
> allow overrides as well?

I'm not clear on why you wouldn't support overrides for ports,
particularly as the base policy maps everything else left unspecified in
the reserved port range to reserved_port_t.  You might argue that should
be moved out of the base module and into the local file, but I expect
some people will need to override the base module port contexts for
specific needs no matter how much we prune it.  User overrides also can
make sense, e.g. some people may want to strip root of sysadm_r

> Should I even support all of them at the sepol layer? It might be 
> simpler to just support the one that gets used for loading in sepol, 
> since policy modifications will be done by rebuilding the policy anyway, 
> so a single load function will be used for modifications. Then 
> libsemanage could support the others on the flat file (but the 
> modification gets applied to policy by rebuilding, and calling the 
> default load function). Thoughts?

libsemanage links and expands the modules yielding a policydb, and then
libsemanage mutates the policydb via libsepol for local customizations,
and then libsemanage writes out the final binary policy image via
sepol_policydb_write.  So you still have to have the appropriate
modifiers available via libsepol to manipulate the in-memory policydb.

-- 
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: Loading things into policy

[Stephen Smalley]

On Wed, 2005-10-19 at 13:20 -0400, Stephen Smalley wrote:
> On Tue, 2005-10-18 at 20:33 -0400, Ivan Gyurdiev wrote:
> > Should I even support all of them at the sepol layer? It might be 
> > simpler to just support the one that gets used for loading in sepol, 
> > since policy modifications will be done by rebuilding the policy anyway, 
> > so a single load function will be used for modifications. Then 
> > libsemanage could support the others on the flat file (but the 
> > modification gets applied to policy by rebuilding, and calling the 
> > default load function). Thoughts?
> 
> libsemanage links and expands the modules yielding a policydb, and then
> libsemanage mutates the policydb via libsepol for local customizations,
> and then libsemanage writes out the final binary policy image via
> sepol_policydb_write.  So you still have to have the appropriate
> modifiers available via libsepol to manipulate the in-memory policydb.

Ah, sorry, I didn't understand your question.  Yes, given that you are
always "loading" entries from the local files into an existing policydb,
where "loading" constitutes either an add-or-modify (most kinds of
records) or a modify-only-if-exists (boolean records), it makes sense
for libsepol to only support a single interface per record type for this
operation.

-- 
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: Loading things into policy

[Stephen Smalley]

On Wed, 2005-10-19 at 13:20 -0400, Stephen Smalley wrote:
> I'm not clear on why you wouldn't support overrides for ports,
> particularly as the base policy maps everything else left unspecified in
> the reserved port range to reserved_port_t.  You might argue that should
> be moved out of the base module and into the local file, but I expect
> some people will need to override the base module port contexts for
> specific needs no matter how much we prune it.  User overrides also can
> make sense, e.g. some people may want to strip root of sysadm_r

BTW, the ordering of the object context specifications matters for nodes
(hosts) and ports.  See what checkpolicy does for nodes (hosts) in
define_ipv4/ipv6_node_context and for ports in define_port_context.

Given this, you can support selective overrides within the reserved port
range just by inserting the individual port or more specific port range
entry at the beginning of the list, so that they will be matched before
reaching the general catch-all range for all reserved ports otherwise
unspecified.
  
-- 
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: Loading things into policy

[Ivan Gyurdiev]

>> I plan to support those functions in all databases:
>> add() - add a new thing, or fail if it exists
>>            (maybe add a configurable parameter saying whether we should 
>> fail, or only warn if it exists)
>> modify() - add a new thing, or modify it if it exists
>>
>> In addition, I'm thinking of adding:
>> set() - modify a thing, but don't add it if it doesn't exist (for booleans).
>>     
>
> add() and set() as described above seem to be fundamental primitives;
> modify() seems optional as it can be constructed by the caller from the
> other two, i.e. if (add() < 0 && errno == EEXIST) { set(); }.
>   
Now, make add() take O(n) time, make set take O(n) time, and you're most 
likely taking twice as much time in modify() as you should be. Yes, I 
agree it's optional, but it's still useful to have... just like 
iterate() and list() can be implemented on top of each other (though 
iterate() over list() is a much worse idea than list() over iterate()).
> I'm not clear on why you wouldn't support overrides for ports,
> particularly as the base policy maps everything else left unspecified in
> the reserved port range to reserved_port_t. 
Hmm.. okay you might be right...
>  You might argue that should
> be moved out of the base module and into the local file, but I expect
> some people will need to override the base module port contexts for
> specific needs no matter how much we prune it.  User overrides also can
> make sense, e.g. some people may want to strip root of sysadm_r
>   
Yes, I realize overrides are useful in some cases - I was wondering 
whether they're useful in all cases.
Hmm... it sounds like we want modify() in all cases, and set() for 
booleans...to be the default function
to call on commit.
>> Should I even support all of them at the sepol layer? It might be 
>> simpler to just support the one that gets used for loading in sepol, 
>> since policy modifications will be done by rebuilding the policy anyway, 
>> so a single load function will be used for modifications. Then 
>> libsemanage could support the others on the flat file (but the 
>> modification gets applied to policy by rebuilding, and calling the 
>> default load function). Thoughts?
>>     
>
> libsemanage links and expands the modules yielding a policydb, and then
> libsemanage mutates the policydb via libsepol for local customizations,
> and then libsemanage writes out the final binary policy image via
> sepol_policydb_write.  So you still have to have the appropriate
> modifiers available via libsepol to manipulate the in-memory policydb.
>   
Well.... we need to choose one modifier to be the default for loading 
that entire file, because I don't keep track of which modifier you want 
per record - I don't keep track of deltas, I keep track of the contents 
of the file. So, there's usually a single modifier you'll be using on 
commit to load that entire file in policy.

In other words, you still have control of which modifier to use when 
working with the file, but I was only planning to support one modifier 
to load that file into policy, when commit() is called.

======
Now, you could say you want add(), modify(), and set() to work as I've 
described above with respect to policy, and not the local file... but 
that's not the way I've been thinking about it so far. That's a 
different kind of design - it would need to do an exists() test in both 
local files, and policy, before it took any action.


--
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: Loading things into policy

[Ron Kuris]

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

Ivan Gyurdiev wrote:

>>> add() - add a new thing, or fail if it exists (maybe add a
>>> configurable parameter saying whether we should fail, or only
>>> warn if it exists) modify() - add a new thing, or modify it if
>>> it exists
>>>
>>> In addition, I'm thinking of adding: set() - modify a thing,
>>> but don't add it if it doesn't exist (for booleans).
>>>
>>
>>
>> add() and set() as described above seem to be fundamental
>> primitives; modify() seems optional as it can be constructed by
>> the caller from the other two, i.e. if (add() < 0 && errno ==
>> EEXIST) { set(); }.
>>
>
> I plan to support those functions in all databases: Now, make add()
> take O(n) time, make set take O(n) time, and you're most likely
> taking twice as much time in modify() as you should be. Yes, I
> agree it's optional, but it's still useful to have... just like
> iterate() and list() can be implemented on top of each other
> (though iterate() over list() is a much worse idea than list() over
> iterate()).

Another interesting point is that your pseudo-code suffers from a race
condition: what if two processes try to add() at the same time?

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

iD8DBQFDVozkVkC/44kdyuYRAmetAKDXOnQYpFQXEPe9INwWigoZ8D6uiACeLDQM
0A6ZMw89JEpm5l/h9DFATtU=
=yY0K
-----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: Loading things into policy

[Stephen Smalley]

On Wed, 2005-10-19 at 11:13 -0700, Ron Kuris wrote:
> Another interesting point is that your pseudo-code suffers from a race
> condition: what if two processes try to add() at the same time?

This is an interface exposed by one shared library (libsepol) for use by
another shared library (libsemanage) acting on an in-memory data
structure (policydb) private to the calling process, so that wasn't an
issue. 

But it is moot in any case, see the follow-up discussion...

-- 
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: Loading things into policy

[Ivan Gyurdiev]

> Another interesting point is that your pseudo-code suffers from a race
> condition: what if two processes try to add() at the same time?
>   
That's actually not a problem, because you'd be in a transaction when 
you executed this code. If I was implementing modify internally to be 
based on add and set, I'd just need to do a transaction check around 
that code.

--
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: Loading things into policy

[Ivan Gyurdiev]

> Now, you could say you want add(), modify(), and set() to work as I've 
> described above with respect to policy, and not the local file... but 
> that's not the way I've been thinking about it so far. That's a 
> different kind of design - it would need to do an exists() test in 
> both local files, and policy, before it took any action.
Actually that's fairly easy to implement, and I'd do it without caring 
what the backend is for various things (I can do this, because of the 
abstractions, which everyone dislikes so much).

Currently I am planning two separate interfaces - one for local objects, 
and one for in-policy objects. To implement an interface that integrates 
those two, I would:
1) suffix the local objects functions with local (which is probably a 
good idea anyway, since their names are a bit misleading).
2) write new functions that are written on top of the local/in-policy 
interfaces (not implementations).
They'd do a query in both databases for queries. For modifications, 
they'd do exist() test in both databases, and add stuff only in the 
local files database.

...at this point Joshua's argument about why adding ports based on 
existence of other ports in global policy is bad...starts to make some 
sense to me. I did not understand his argument before, because it didn't 
make sense when you were checking existence in the local database only, 
and had a default handler to use on commit() for the in-policy objects.



--
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: Loading things into policy

[Ivan Gyurdiev]

>> Now, you could say you want add(), modify(), and set() to work as 
>> I've described above with respect to policy, and not the local 
>> file... but that's not the way I've been thinking about it so far. 
>> That's a different kind of design - it would need to do an exists() 
>> test in both local files, and policy, before it took any action.
> Actually that's fairly easy to implement, and I'd do it without caring 
> what the backend is for various things (I can do this, because of the 
> abstractions, which everyone dislikes so much).
>
> Currently I am planning two separate interfaces - one for local 
> objects, and one for in-policy objects. To implement an interface that 
> integrates those two, I would:
> 1) suffix the local objects functions with local (which is probably a 
> good idea anyway, since their names are a bit misleading).
> 2) write new functions that are written on top of the local/in-policy 
> interfaces (not implementations).
> They'd do a query in both databases for queries. For modifications, 
> they'd do exist() test in both databases, and add stuff only in the 
> local files database.
>
> ...at this point Joshua's argument about why adding ports based on 
> existence of other ports in global policy is bad...starts to make some 
> sense to me. I did not understand his argument before, because it 
> didn't make sense when you were checking existence in the local 
> database only, and had a default handler to use on commit() for the 
> in-policy objects.

Also, I'm forgetting that in-policy objects include local objects, since 
I'm working on policy.kern, not base.pp.
So, in short, I don't think I'll be writing such an interface at all - 
no point discussing it.

What I will do, however, is to:
1) expose the in-policy queries to libsemanage clients
2) rename the in-policy queries to  have no suffix (so instead of: 
semanage_user_iterate_policy -> semanage_user_iterate).
3) rename the local queries to have a suffix (so instead of: 
semanage_user_add -> semanage_user_add_local) /
                                                                (    
instead of: semanage_user_iterate -> semanage_user_iterate_local).

Does that seem like an improvement?


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