file contexts and modularity

file contexts and modularity

[Ivan Gyurdiev]

So, I know Tresys is working on binary policy modules.

What's the plan for dealing with the file_contexts file?

In particular, will this continue to be stored
as a single giant flat file, or will it be broken up
(or stored differently..)

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

I ask, because I am trying to figure out how to 
recover which contexts belong to which user, when parsing
the file_context.homedirs file, as part of my 
useradd/usermod/userdel patch.

This isn't as simple as it sounds, since
I can't use the user field (<<none>> contexts).
I suppose I could regenerate the right contexts from the
template, but that seems like bad design. Basically
it's exactly the same problem as establishing which
file_contexts relate to which app, so I'm wondering
what's the planned solution for that? Is there a plan?

If we're going to keep this in a big flat file, 
there should be some sort of way to indicate
a container for file contexts... (a dependency
keyword(s) or something)... or we could split it up
into multiple files.

Reminds me of the XML thread for some reason :)
But on the other hand XML-style requires strict nesting
relationship, while it would seem better to just do something like:

regexp class context [ dep_keyword1 dep_keyword2... ] 
(same row, brackets required).

Keywords could be users, applications, booleans, tunables, whatever..

-- 
Ivan Gyurdiev <ivg2@cornell.edu>
Cornell University


--
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: file contexts and modularity

[Karl MacMillan]

> -----Original Message-----
> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov] On
> Behalf Of Ivan Gyurdiev
> Sent: Wednesday, June 22, 2005 11:01 PM
> To: selinux@tycho.nsa.gov
> Cc: Daniel J Walsh
> Subject: file contexts and modularity
> 
> So, I know Tresys is working on binary policy modules.
> 

It's not just the modules that are an issue - it is the policy server as well.

> What's the plan for dealing with the file_contexts file?
> 
> In particular, will this continue to be stored
> as a single giant flat file, or will it be broken up
> (or stored differently..)
> 

There are no plans to have the resulting file stored differently for the policy
modules. Each loadable module contains the file_contexts for that module. These
are concatenated together to create the standard file_contexts file that is put
in the same place. This does cause some problems with ordering, which we have a
partial fix for that I will sent out in a separate email.

We haven't made any decisions for the policy server other than we want the
policy server to encapsulate all policy access including file context
information. The details aren't clear to me and I would like some input about
this. See
http://sepolicy-server.sourceforge.net/index.php?page=policy-management-design
for some information about this.

> ============
> 
> I ask, because I am trying to figure out how to
> recover which contexts belong to which user, when parsing
> the file_context.homedirs file, as part of my
> useradd/usermod/userdel patch.
> 
> This isn't as simple as it sounds, since
> I can't use the user field (<<none>> contexts).
> I suppose I could regenerate the right contexts from the
> template, but that seems like bad design. Basically
> it's exactly the same problem as establishing which
> file_contexts relate to which app, so I'm wondering
> what's the planned solution for that? Is there a plan?
> 
> If we're going to keep this in a big flat file,
> there should be some sort of way to indicate
> a container for file contexts... (a dependency
> keyword(s) or something)... or we could split it up
> into multiple files.
> 
> Reminds me of the XML thread for some reason :)
> But on the other hand XML-style requires strict nesting
> relationship, while it would seem better to just do something like:
> 
> regexp class context [ dep_keyword1 dep_keyword2... ]
> (same row, brackets required).
> 
> Keywords could be users, applications, booleans, tunables, whatever..
> 

I think that I missed something - why do you need to know which contexts are
associated with an app or user?

Karl

> --
> Ivan Gyurdiev <ivg2@cornell.edu>
> Cornell University
> 
> 

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134

> --
> 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: file contexts and modularity

[Ivan Gyurdiev]

> I think that I missed something - why do you need to know which contexts are
> associated with an app or user?

So that I can get rid of them once the user's removed (userdel).

It seems like I'll just put each user in a separate .fc file
for now... but then if you wanted to remove an app, you'd
have to remove the app's .fc file, and the app's entries
in each user file as well (and any template entries)...
or alternatively you'd have to regenerate everything.





--
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: file contexts and modularity

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:ivg2@cornell.edu]
> Sent: Thursday, June 23, 2005 2:05 PM
> To: Karl MacMillan
> Cc: selinux@tycho.nsa.gov; 'Daniel J Walsh'
> Subject: RE: file contexts and modularity
> 
> 
> > I think that I missed something - why do you need to know which contexts are
> > associated with an app or user?
> 
> So that I can get rid of them once the user's removed (userdel).
> 
> It seems like I'll just put each user in a separate .fc file
> for now... but then if you wanted to remove an app, you'd
> have to remove the app's .fc file, and the app's entries
> in each user file as well (and any template entries)...
> or alternatively you'd have to regenerate everything.
> 
> 

Regenerating seems easier and more likely to be correct to me.

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134




--
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: file contexts and modularity

[Ivan Gyurdiev]

> Regenerating seems easier

...seems harder to me - I'm doing this from a C library,
and I already have written code to delete stuff from a single file.

Running around the filesystem to piece together a new file
will be a pain...

>  and more likely to be correct to me.

...how so?







--
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: file contexts and modularity

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:ivg2@cornell.edu]
> Sent: Thursday, June 23, 2005 2:25 PM
> To: Karl MacMillan
> Cc: selinux@tycho.nsa.gov; 'Daniel J Walsh'
> Subject: RE: file contexts and modularity
> 
> 
> > Regenerating seems easier
> 
> ...seems harder to me - I'm doing this from a C library,
> and I already have written code to delete stuff from a single file.
> 
> Running around the filesystem to piece together a new file
> will be a pain...
>

Are you intending to do away with genhomedircon so that everything will be in
libselinux? Why are you going to have to run around the file system? Isn't this
a matter for taking the file contexts file that still has ROLE and HOMEDIR
statements and processing that?

Can you give an overview of these patches - what you are trying to accomplish in
more detail and the design?
 
> >  and more likely to be correct to me.
> 
> ...how so?
> 
> 

Deleting specific lines from the file contexts file seems difficult and error
prone while regenerating is straight forward. Only one code path (generation)
instead of many (add, remove, change, etc).

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134

> 
> 




--
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: file contexts and modularity

[Ivan Gyurdiev]

> Are you intending to do away with genhomedircon so that everything will be in
> libselinux?

libsepol...

The problem is that genhomedircon is in python, and useradd is in C.
Furthermore genhomedircon doesn't do what I want.

>  Why are you going to have to run around the file system? Isn't this
> a matter for taking the file contexts file that still has ROLE and HOMEDIR
> statements and processing that?

If I have a separate file for each user, I have to concat them together
for matchpathcon, is that not the case? I guess I can do that, but I'd
rather not..

If you take the more general case of removing an application - imagine
you want to remove mozilla, and have its contexts gone - you have
to reconstruct the entire file_contexts file from all the .fc files.

> Can you give an overview of these patches - what you are trying to accomplish in
> more detail and the design?

Well I was trying to accomplish the following:

- add -R flag to useradd, and have it automatically validate
and add user roles, and generate user contexts (and add user to running
policy)

- have userdel undo the above

- have usermod modify user roles in file and policy, and on default
role change, recreate the contexts.

- expose the net_contexts file through the libsepol library

In addition I am doing the following changes, which affect you:

- modify all libsepol functions to work via policydb and 
not (data,len) image (because there's no reason to policydb_read
on each function call...)

- make policydb an opaque data structure to address the
exposure created above

- separate genusers policy and parsing, to allow for alternative
data source in the future for the user information than the flat file.


This is accomplished by defining a "record" structure for
each configuration group (for example, the user record contains
the user's name, roles, default role, and mls info (and I've
bundled home dir for other purposes)). The fscon record
contains a regexp, a class (-b, -p), and a context. I'm
currently trying to break out the context as its own record,
since that makes sense to me.

Each record has a bunch of _file methods that define how
it can be parsed from a file, and written to a file.

Then I have a central routine called record_iterate,
and another one called record_modify_file that loop
over a file, and parse records (based on a table
of functions that explains how to do that),
and execute arbitrary handlers. Modify_file
is pretty similar to iterate, except it 
copies records to a second stream while
it's iterating, and then overwrites
the original at the end. Those functions
support events like delete, and match
that can be signaled by the handler, and support
configuring whether certain errors are fatal..




--
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: file contexts and modularity

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:ivg2@cornell.edu]
> Sent: Thursday, June 23, 2005 3:00 PM
> To: Karl MacMillan
> Cc: selinux@tycho.nsa.gov; 'Daniel J Walsh'
> Subject: RE: file contexts and modularity
> 
> 
> > Are you intending to do away with genhomedircon so that everything will be
> in
> > libselinux?
> 
> libsepol...
> 
> The problem is that genhomedircon is in python, and useradd is in C.

Not objecting - just checking.

> Furthermore genhomedircon doesn't do what I want.
> 
> >  Why are you going to have to run around the file system? Isn't this
> > a matter for taking the file contexts file that still has ROLE and HOMEDIR
> > statements and processing that?
> 
> If I have a separate file for each user, I have to concat them together
> for matchpathcon, is that not the case? I guess I can do that, but I'd
> rather not..
> 

Why have a file per user?

> If you take the more general case of removing an application - imagine
> you want to remove mozilla, and have its contexts gone - you have
> to reconstruct the entire file_contexts file from all the .fc files.
> 

The module infrastructure already handles this - it produces a flat
file_contexts file. Seems like this could be run through what is essentially
genhomedircon to produce another flat text file for matchpathcon. This would
obviously be backward compatible with the current source policies.

> > Can you give an overview of these patches - what you are trying to
> accomplish in
> > more detail and the design?
> 
> Well I was trying to accomplish the following:
> 
> - add -R flag to useradd, and have it automatically validate
> and add user roles, and generate user contexts (and add user to running
> policy)
> 
> - have userdel undo the above
> 
> - have usermod modify user roles in file and policy, and on default
> role change, recreate the contexts.
> 

We were planning on deprecating seuser because of general bit rot. It does do
all of this (through wrappers, etc) so if any of that code is useful feel free
to grab it (it's GPL).

> - expose the net_contexts file through the libsepol library
> 

Changes or just query?

> In addition I am doing the following changes, which affect you:
> 
> - modify all libsepol functions to work via policydb and
> not (data,len) image (because there's no reason to policydb_read
> on each function call...)
> 

Definitely a good idea.

> - make policydb an opaque data structure to address the
> exposure created above
> 

Great - and then various helper functions can be added incrementally until there
is a full API.

> - separate genusers policy and parsing, to allow for alternative
> data source in the future for the user information than the flat file.
> 
> 
> This is accomplished by defining a "record" structure for
> each configuration group (for example, the user record contains
> the user's name, roles, default role, and mls info (and I've
> bundled home dir for other purposes)). The fscon record
> contains a regexp, a class (-b, -p), and a context. I'm
> currently trying to break out the context as its own record,
> since that makes sense to me.
> 
> Each record has a bunch of _file methods that define how
> it can be parsed from a file, and written to a file.
> 
> Then I have a central routine called record_iterate,
> and another one called record_modify_file that loop
> over a file, and parse records (based on a table
> of functions that explains how to do that),
> and execute arbitrary handlers. Modify_file
> is pretty similar to iterate, except it
> copies records to a second stream while
> it's iterating, and then overwrites
> the original at the end. Those functions
> support events like delete, and match
> that can be signaled by the handler, and support
> configuring whether certain errors are fatal..
> 

Hmm . . . why have the records so directly tied to files? Seems like the API
needs to be a little higher level to actually make it work with something like
an LDAP backend.

Thanks for the overview - it has clarified some things for me. I'm trying to get
a handle on how we want things to look in the future. One concern is that this
api uses libsepol - e.g. it makes it clear to the caller that it is manipulating
a policy file. We have been discussing / imagining an API that will be forward
portable to the policy server where the act of adding a user might involve and
IPC call to the server and be significantly more abstract than a policy
manipulation. Not certain, therefore, that libsepol is the correct place for the
client api (e.g. the one used by useradd). Thoughts?

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134



--
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: file contexts and modularity

[Ivan Gyurdiev]

[-- Attachment #1: Type: text/plain, Size: 4597 bytes --]


> Why have a file per user?

I thought that's what you were suggesting - store per user contexts
in their own file, and then re-generate the end result from that.

Alternatively it could all be in one big file, but then I 
don't have any information what came from where. Regenerating
the regexps from the template (1) requires delete
to have the same information as add, which is otherwise
not necessary. Currently that consists of the home dirs, but
in the future it could consist of other stuff too, and
(2) requires me to match every line in homedirs against
every template expression, which just seems unnecessary.

> > > Can you give an overview of these patches - what you are trying to
> > accomplish in
> > > more detail and the design?
> > 
> > Well I was trying to accomplish the following:
> > 
> > - add -R flag to useradd, and have it automatically validate
> > and add user roles, and generate user contexts (and add user to running
> > policy)
> > 
> > - have userdel undo the above
> > 
> > - have usermod modify user roles in file and policy, and on default
> > role change, recreate the contexts.
> > 
> 
> We were planning on deprecating seuser because of general bit rot. It does do
> all of this (through wrappers, etc) so if any of that code is useful feel free
> to grab it (it's GPL).

Is seuser a library or a command line tool? I want to write a library..

I'm not sure how much help I need, since I have already made sufficient
progress on this - I can successfully complete add, and 
then delete and modify shouldn't be all that hard, once
I decide what to do about finding the user contexts.

I still need to add more validation, and rollback...

> > - expose the net_contexts file through the libsepol library
> > 
> 
> Changes or just query?

Changes, eventually.
Actually Dan's telling me that for starters I need to
get net_contexts.local set up, but I'm looking forward
to manipulating this file automatically in the future.

> > In addition I am doing the following changes, which affect you:
> > 
> > - modify all libsepol functions to work via policydb and
> > not (data,len) image (because there's no reason to policydb_read
> > on each function call...)
> > 
> 
> Definitely a good idea.

it still takes 4 seconds for useradd to load the policy.
It's awfully slow.... that's 2x policydb_read, because of
the verify-after-write. 

> > - make policydb an opaque data structure to address the
> > exposure created above
> > 
> 
> Great - and then various helper functions can be added incrementally until there
> is a full API.

Right....however I'm making an incompatible change here.
policydb_destroy has been changed to free the policy, which
requires all policydb structures to be created on the heap 
via policydb_create. I have to fix existing users.

> 
> Hmm . . . why have the records so directly tied to files? Seems like the API
> needs to be a little higher level to actually make it work with something like
> an LDAP backend.

They are not... the record structure itself is located in a separate 
file. The create/destroy/set/get methods are packaged with the record.
The record thing isn't much more than a wrapper around a struct.
I don't use internal selinux datums for this, because I want to stay
close to the format used in the outside world (human readable strings).

The parse/print methods are packaged separately, because they are
file dependent. The record_iterate and record_modify_file are obviously
file dependent. Someone can implement the top level functions
in a different way with a different backend. 

> Thanks for the overview - it has clarified some things for me. I'm trying to get
> a handle on how we want things to look in the future. One concern is that this
> api uses libsepol - e.g. it makes it clear to the caller that it is manipulating
> a policy file. We have been discussing / imagining an API that will be forward
> portable to the policy server where the act of adding a user might involve and
> IPC call to the server and be significantly more abstract than a policy
> manipulation. 

Take a look at attached headers, and see if you can make suggestions.
Yes, I know I should probably prefix those records with something sane,
but I haven't done that yet.

I'm considering removing the user/type/role/mls fields from 
port and fscon, and making that part of the common context_record.h
instead.

> Not certain, therefore, that libsepol is the correct place for the
> client api (e.g. the one used by useradd). Thoughts?

It's difficult to me to write forward portable code, when I don't
know the future :) 

[-- Attachment #2: booleans_extern.h --]
[-- Type: text/x-chdr, Size: 300 bytes --]

#ifndef _SEPOL_BOOLEANS_EXTERN_H
#define _SEPOL_BOOLEANS_EXTERN_H

#include <sepol/policydb_extern.h>

extern int sepol_load_booleans(
	policydb_ref_t policydb, 
	const char *sel_path);

extern int sepol_load_booleans_array(
	policydb_ref_t policydb, 
	char **names, int *values, 
	int nel);

#endif

[-- Attachment #3: context_record_extern.h --]
[-- Type: text/x-chdr, Size: 868 bytes --]

#ifndef _SEPOL_CONTEXT_RECORD_EXTERN_H_
#define _SEPOL_CONTEXT_RECORD_EXTERN_H_ 

#include <stdlib.h>
#include <string.h>

struct context_record;
typedef struct context_record* context_record_t;

/* User */
extern const char* cr_get_user(context_record_t con);
extern int cr_set_user(context_record_t con, const char* user);

/* Role */
extern const char* cr_get_role(context_record_t con);
extern int cr_set_role(context_record_t con, const char* role);

/* Type */
extern const char* cr_get_type(context_record_t con);
extern int cr_set_type(context_record_t con, const char* type);

/* MLS */
extern const char* cr_get_mls(context_record_t con);
extern int cr_set_mls(context_record_t con, const char* mls_range);

/* Create/Destroy */
extern context_record_t cr_create();
extern void cr_destroy(context_record_t con);

#endif /* _SEPOL_CONTEXT_RECORD_EXTERN_H_ */

[-- Attachment #4: file_record_extern.h --]
[-- Type: text/x-chdr, Size: 1277 bytes --]

#ifndef _SEPOL_FILE_RECORD_EXTERN_H_
#define _SEPOL_FILE_RECORD_EXTERN_H_ 

#include <stdlib.h>
#include <string.h>

struct file_record;
typedef struct file_record* file_record_t;

#define FR_CLASS_ALL   0
#define FR_CLASS_REG   1
#define FR_CLASS_DIR   2
#define FR_CLASS_CHAR  3
#define FR_CLASS_BLOCK 4
#define FR_CLASS_SOCK  5
#define FR_CLASS_LINK  6
#define FR_CLASS_FIFO  7

/* Expression */
extern const char* fr_get_expr(file_record_t file);
extern int fr_set_expr(file_record_t file, const char* expr);

/* Class */
extern int fr_get_class(file_record_t file);
extern void fr_set_class(file_record_t file, int class);

/* User */
extern const char* fr_get_user(file_record_t file);
extern int fr_set_user(file_record_t file, const char* user);

/* Role */
extern const char* fr_get_role(file_record_t file);
extern int fr_set_role(file_record_t file, const char* role);

/* Type */
extern const char* fr_get_type(file_record_t file);
extern int fr_set_type(file_record_t file, const char* type);

/* MLS */
extern const char* fr_get_mls(file_record_t file);
extern int fr_set_mls(file_record_t file, const char* mls_range);

/* Create/Destroy */
extern file_record_t fr_create();
extern void fr_destroy(file_record_t file);

#endif /* _SEPOL_FILE_RECORD_EXTERN_H_ */

[-- Attachment #5: fscon_file_extern.h --]
[-- Type: text/x-chdr, Size: 360 bytes --]

#ifndef _SEPOL_USERS_FILE_EXTERN_H
#define _SEPOL_USERS_FILE_EXTERN_H

#include <sepol/user_record_extern.h>
#include <sepol/policydb_extern.h>

extern int sepol_fscon_user_add(
	policydb_ref_t policydb,
	user_record_t user,
	const char* sel_root);

extern int sepol_fscon_user_del(
	policydb_ref_t policydb,
	const char* name,
	const char* sel_root);

#endif

[-- Attachment #6: policydb_extern.h --]
[-- Type: text/x-chdr, Size: 390 bytes --]

#ifndef _SEPOL_POLICYDB_EXTERN_H_
#define _SEPOL_POLICYDB_EXTERN_H_

struct policydb;

typedef struct policydb* policydb_ref_t;

extern int policydb_create(policydb_ref_t* p);

extern void policydb_destroy(policydb_ref_t p);

extern int policydb_from_image(void* data, size_t len, policydb_ref_t* p);

extern int policydb_to_image(policydb_ref_t p, void **newdata, size_t *newlen);

#endif

[-- Attachment #7: port_record_extern.h --]
[-- Type: text/x-chdr, Size: 1079 bytes --]

#ifndef _SEPOL_PORT_RECORD_EXTERN_H_
#define _SEPOL_PORT_RECORD_EXTERN_H_ 

#include <stdlib.h>
#include <string.h>

struct port_record;
typedef struct port_record* port_record_t;

#define PR_PROTO_UDP 0
#define PR_PROTO TCP 1

/* Protocol */
extern int pr_get_proto(port_record_t pr);
extern void pr_set_proto(port_record_t pr, int proto);

/* Port */
extern int pr_get_port(port_record_t pr);
extern void pr_set_port(port_record_t pr, int port);

/* User */
extern const char* pr_get_user(port_record_t pr);
extern int pr_set_user(port_record_t pr, const char* user);

/* Role */
extern const char* pr_get_role(port_record_t pr);
extern int pr_set_role(port_record_t pr, const char* role);

/* Type */
extern const char* pr_get_type(port_record_t pr);
extern int pr_set_type(port_record_t pr, const char* type);

/* MLS */
extern const char* pr_get_mls(port_record_t pr);
extern int pr_set_mls(port_record_t pr, const char* mls_range);

/* Create/Destroy */
extern port_record_t pr_create();
extern void pr_destroy(port_record_t pr);

#endif /* _SEPOL_PORT_RECORD_EXTERN_H_ */

[-- Attachment #8: user_record_extern.h --]
[-- Type: text/x-chdr, Size: 1359 bytes --]

#ifndef _SEPOL_USER_RECORD_EXTERN_H_
#define _SEPOL_USER_RECORD_EXTERN_H_

#include <string.h>

struct user_record;
typedef struct user_record* user_record_t;

/* Name */
extern const char* ur_get_name(user_record_t user);
extern int ur_set_name(user_record_t user, const char* name);

/* Home directory */
extern const char* ur_get_home(user_record_t user);
extern int ur_set_home(user_record_t user, const char* home);

/* MLS */
extern const char* ur_get_mls_level(user_record_t user);
extern int ur_set_mls_level(user_record_t user, const char* mls_level);
extern const char* ur_get_mls_range(user_record_t user);
extern int ur_set_mls_range(user_record_t user, const char* mls_range);

/* Role management */
extern int ur_get_num_roles(user_record_t user);
extern const char* ur_get_def_role(user_record_t user);
extern int ur_add_role(user_record_t user, const char* role);
extern int ur_del_role(user_record_t user, const char* role);
extern int ur_has_role(user_record_t user, const char* role);
extern int ur_set_def_role(user_record_t user, const char* role);
extern int ur_reset_roles(user_record_t user);
extern void ur_iter_init(user_record_t user);
extern const char* ur_next_role(user_record_t user);

/* Create/destroy */
extern user_record_t ur_create();
extern void ur_destroy(user_record_t user);

#endif /* _SEPOL_USER_RECORD_EXTERN_H_ */

[-- Attachment #9: users_file_extern.h --]
[-- Type: text/x-chdr, Size: 858 bytes --]

#ifndef _SEPOL_USERS_FILE_EXTERN_H
#define _SEPOL_USERS_FILE_EXTERN_H

#include <sepol/user_record_extern.h>
#include <sepol/policydb_extern.h>

extern int sepol_load_users_file(
	policydb_ref_t policydb,
	const char* sel_root);

extern int sepol_add_user_file(
	policydb_ref_t policydb,
	const char* sel_root,
	user_record_t user);

extern int sepol_del_user_file(
	policydb_ref_t policydb,
	const char* sel_root,
	const char* username);

extern int sepol_set_roles_file(
	policydb_ref_t policydb,
	const char* sel_root,
	const char* username,
	const char** roles);

extern int sepol_add_role_file(
	policydb_ref_t policydb,
	const char* sel_root,
	const char* username,
	const char* role);

extern int sepol_del_role_file(
	policydb_ref_t policydb,
	const char* sel_root,
	const char* username,
	const char* role);

#endif /* _SEPOL_USERS_FILE_EXTERN_H */

[-- Attachment #10: users_policy_extern.h --]
[-- Type: text/x-chdr, Size: 641 bytes --]

#ifndef _SEPOL_USERS_POLICY_EXTERN_H_
#define _SEPOL_USERS_POLICY_EXTERN_H_

#include <sepol/policydb_extern.h>
#include <sepol/user_record_extern.h>

/* Del users */
extern void sepol_set_delusers(int on);

/* Clear unused users */
extern void sepol_clear_unused_users(
	policydb_ref_t policydb);

/* Add/delete/load users from the policy */
extern int sepol_add_user_policy(
	policydb_ref_t policydb, 
	user_record_t user);

extern int sepol_del_user_policy(
	policydb_ref_t policydb, 
	const char *username);

extern int sepol_load_user_policy(
	policydb_ref_t policydb, 
	user_record_t user);

#endif /* _SEPOL_USERS_POLICY_EXTERN_H_ */

RE: file contexts and modularity

[Ivan Gyurdiev]

[-- Attachment #1: Type: text/plain, Size: 157 bytes --]


> Take a look at attached headers,

More of them.

In selinux.h, search for create_policydb.

That's a library function for policycoreutils/load_policy.c.


[-- Attachment #2: sepol.h --]
[-- Type: text/x-chdr, Size: 2421 bytes --]

#ifndef _SEPOL_H_
#define _SEPOL_H_

#include <sys/types.h>
#include <stdio.h>
#include <stdarg.h>

/* Draw in extra headers that should be visible from outside */

#include <sepol/booleans_extern.h>
#include <sepol/policydb_extern.h>

#include <sepol/user_record_extern.h>
#include <sepol/file_record_extern.h>
#include <sepol/port_record_extern.h>

#include <sepol/users_policy_extern.h>
#include <sepol/users_file_extern.h>
#include <sepol/fscon_file_extern.h>

/*==== Backwards Compatibility definitions ==== */

/* Given an existing binary policy (starting at 'data', with length 'len')
   and a boolean configuration file named by 'boolpath', rewrite the binary
   policy for the boolean settings in the boolean configuration file.
   The binary policy is rewritten in place in memory.
   Returns 0 upon success, or -1 otherwise. */
extern int sepol_genbools(void *data, size_t len, char *boolpath);

/* Given an existing binary policy (starting at 'data', with length 'len')
   and boolean settings specified by the parallel arrays ('names', 'values')
   with 'nel' elements, rewrite the binary policy for the boolean settings.  
   The binary policy is rewritten in place in memory.
   Returns 0 upon success or -1 otherwise. */
extern int sepol_genbools_array(
	void *data, size_t len, 
	char **names, int *values, int nel);

/* Given an existing binary policy (starting at 'data with length 'len')
   and user configurations living in 'usersdir', generate a new binary
   policy for the new user configurations.  Sets '*newdata' and '*newlen'
   to refer to the new binary policy image. */
extern int sepol_genusers(
	void *data, size_t len, 
	const char *usersdir,
	void **newdata, size_t *newlen);

static inline int sepol_genbools_policydb(
	policydb_ref_t policydb, char *boolpath) {

	return sepol_load_booleans(policydb, boolpath);
}

static inline int sepol_genusers_policydb( 
	policydb_ref_t policydb, const char* usersdir) {

	return sepol_load_users_file(policydb, usersdir);
}

/* ==== End backwards compatibility ==== */

/* Set internal policydb from a file for subsequent service calls. */
extern int sepol_set_policydb(policydb_ref_t policydb);
extern int sepol_set_policydb_from_file(FILE *fp);

/* Check context validity against currently set binary policy. */
extern int sepol_check_context(char *context);

/* Turn on or off sepol error messages. */
extern void sepol_debug(int on);

#endif

[-- Attachment #3: selinux.h --]
[-- Type: text/x-chdr, Size: 12611 bytes --]

#ifndef _SELINUX_H_
#define _SELINUX_H_

#include <stdlib.h>
#include <sys/types.h>
#include <stdarg.h>
#include <sepol/sepol.h>

#ifdef __cplusplus
extern "C"
{
#endif

extern void security_debug(int on);

/* Return 1 if we are running on a SELinux kernel, or 0 if not or -1 if we get an error. */
extern int is_selinux_enabled(void);
/* Return 1 if we are running on a SELinux MLS kernel, or 0 otherwise. */
extern int is_selinux_mls_enabled(void);

typedef char* security_context_t;

/* Free the memory allocated for a context by any of the below get* calls. */
extern void freecon(security_context_t con);

/* Free the memory allocated for a context array by security_compute_user. */
extern void freeconary(security_context_t *con);

/* Wrappers for the /proc/pid/attr API. */

/* Get current context, and set *con to refer to it.
   Caller must free via freecon. */
extern int getcon(security_context_t *con);

/* Set the current security context to con.  
   Note that use of this function requires that the entire application
   be trusted to maintain any desired separation between the old and new 
   security contexts, unlike exec-based transitions performed via setexeccon.  
   When possible, decompose your application and use setexeccon()+execve() 
   instead. Note that the application may lose access to its open descriptors
   as a result of a setcon() unless policy allows it to use descriptors opened
   by the old context. */
extern int setcon(security_context_t con);

/* Get context of process identified by pid, and 
   set *con to refer to it.  Caller must free via freecon. */
extern int getpidcon(pid_t pid, security_context_t *con);

/* Get previous context (prior to last exec), and set *con to refer to it.
   Caller must free via freecon. */
extern int getprevcon(security_context_t *con);

/* Get exec context, and set *con to refer to it.
   Sets *con to NULL if no exec context has been set, i.e. using default.
   If non-NULL, caller must free via freecon. */
extern int getexeccon(security_context_t *con);

/* Set exec security context for the next execve. 
   Call with NULL if you want to reset to the default. */
extern int setexeccon(security_context_t con);

/* Get fscreate context, and set *con to refer to it.
   Sets *con to NULL if no fs create context has been set, i.e. using default.
   If non-NULL, caller must free via freecon. */
extern int getfscreatecon(security_context_t *con);

/* Set the fscreate security context for subsequent file creations.
   Call with NULL if you want to reset to the default. */
extern int setfscreatecon(security_context_t context);


/* Wrappers for the xattr API. */

/* Get file context, and set *con to refer to it.
   Caller must free via freecon. */
extern int getfilecon(const char *path, security_context_t *con);
extern int lgetfilecon(const char *path, security_context_t *con);
extern int fgetfilecon(int fd, security_context_t *con);

/* Set file context */
extern int setfilecon(const char *path, security_context_t con);
extern int lsetfilecon(const char *path, security_context_t con);
extern int fsetfilecon(int fd, security_context_t con);


/* Wrappers for the socket API */

/* Get context of peer socket, and set *con to refer to it.
   Caller must free via freecon. */
extern int getpeercon(int fd, security_context_t *con);


/* Wrappers for the selinuxfs (policy) API. */

typedef unsigned int access_vector_t;
typedef unsigned short security_class_t;

struct av_decision {
	access_vector_t allowed;
	access_vector_t decided;
	access_vector_t auditallow;
	access_vector_t auditdeny;
	unsigned int seqno;
};

/* Compute an access decision. */
extern int security_compute_av(security_context_t scon,
			       security_context_t tcon,
			       security_class_t tclass,
			       access_vector_t requested,
			       struct av_decision *avd);

/* Compute a labeling decision and set *newcon to refer to it.
   Caller must free via freecon. */
extern int security_compute_create(security_context_t scon,
				   security_context_t tcon,
				   security_class_t tclass,
				   security_context_t *newcon);

/* Compute a relabeling decision and set *newcon to refer to it.
   Caller must free via freecon. */
extern int security_compute_relabel(security_context_t scon,
				    security_context_t tcon,
				    security_class_t tclass,
				    security_context_t *newcon);

/* Compute a polyinstantiation member decision and set *newcon to refer to it.
   Caller must free via freecon. */
extern int security_compute_member(security_context_t scon,
				   security_context_t tcon,
				   security_class_t tclass,
				   security_context_t *newcon);

/* Compute the set of reachable user contexts and set *con to refer to 
   the NULL-terminated array of contexts.  Caller must free via freeconary. */
extern int security_compute_user(security_context_t scon,
				 const char *username,
				 security_context_t **con);

/* Translate boolean strict to name value pair. */
typedef struct {
	char *name;
	int value; 
} SELboolean;
	/* save a list of booleans in a single transaction.  */
extern int security_set_boolean_list(size_t boolcnt, 
				     SELboolean *boollist, 
				     int permanent);

/* Load policy boolean settings.
   Path may be NULL, in which case the booleans are loaded from
   the active policy boolean configuration file. */
extern int security_load_booleans(char *path);

/* Check the validity of a security context. */
extern int security_check_context(security_context_t con);

/* Get the enforce flag value. */
extern int security_getenforce(void);

/* Set the enforce flag value. */
extern int security_setenforce(int value);

/* Disable SELinux at runtime (must be done prior to initial policy load). */
extern int security_disable(void);

/* Get the policy version number. */
extern int security_policyvers(void);

/* Get the boolean names */
extern int security_get_boolean_names(char ***names, int *len);

/* Get the pending value for the boolean */
extern int security_get_boolean_pending(const char *name);

/* Get the active value for the boolean */
extern int security_get_boolean_active(const char *name);

/* Set the pending value for the boolean */
extern int security_set_boolean(const char *name, int value);

/* Commit the pending values for the booleans */
extern int security_commit_booleans(void);

/* Common helpers */

/* Return the security class value for a given class name. */
extern security_class_t string_to_security_class(const char *name);

/* Return an access vector for a given class and permission name. */
extern access_vector_t string_to_av_perm(security_class_t tclass, const char *name);

/* Display an access vector in a string representation. */
extern void print_access_vector(security_class_t tclass, access_vector_t av);

/* Set the function used by matchpathcon_init when displaying
   errors about the file_contexts configuration.  If not set,
   then this defaults to fprintf(stderr, fmt, ...). */
extern void set_matchpathcon_printf(void (*f)(const char *fmt, ...));

/* Set the function used by matchpathcon_init when checking the
   validity of a context in the file contexts configuration.  If not set,
   then this defaults to a test based on security_check_context().  
   The function is also responsible for reporting any such error, and
   may include the 'path' and 'lineno' in such error messages. */
extern void set_matchpathcon_invalidcon(int (*f)(const char *path, 
						 unsigned lineno, 
						 char *context));

/* Set flags controlling operation of matchpathcon_init or matchpathcon. */
#define MATCHPATHCON_BASEONLY 1 /* Only process the base file_contexts file. */
extern void set_matchpathcon_flags(unsigned int flags);

/* Load the file contexts configuration specified by 'path'
   into memory for use by subsequent matchpathcon calls.  
   If 'path' is NULL, then load the active file contexts configuration,
   i.e. the path returned by selinux_file_context_path().
   Unless the MATCHPATHCON_BASEONLY flag has been set, this
   function also checks for a 'path'.homedirs file and 
   a 'path'.local file and loads additional specifications 
   from them if present. */
extern int matchpathcon_init(const char *path);

/* Match the specified pathname and mode against the file contexts
   configuration and set *con to refer to the resulting context.
   'mode' can be 0 to disable mode matching.
   Caller must free via freecon.
   If matchpathcon_init has not already been called, then this function
   will call it upon its first invocation with a NULL path. */
extern int matchpathcon(const char *path,
			mode_t mode,
			security_context_t *con);

/* Same as above, but return a specification index for 
   later use in a matchpathcon_filespec_add() call - see below. */
extern int matchpathcon_index(const char *path,
			      mode_t mode,
			      security_context_t *con);

/* Maintain an association between an inode and a specification index,
   and check whether a conflicting specification is already associated
   with the same inode (e.g. due to multiple hard links).  If so, then
   use the latter of the two specifications based on their order in the 
   file contexts configuration.  Return the used specification index. */
extern int matchpathcon_filespec_add(ino_t ino, int specind, const char *file);

/* Destroy any inode associations that have been added, e.g. to restart
   for a new filesystem. */
extern void matchpathcon_filespec_destroy(void);

/* Display statistics on the hash table usage for the associations. */
extern void matchpathcon_filespec_eval(void);

/* Check to see whether any specifications had no matches and report them.
   The 'str' is used as a prefix for any warning messages. */
extern void matchpathcon_checkmatches(char *str);

/* Match the specified media and against the media contexts 
   configuration and set *con to refer to the resulting context.
   Caller must free con via freecon. */
extern int matchmediacon(const char *media,
		 security_context_t *con);

/*
  selinux_getenforcemode reads the /etc/selinux/config file and determines 
  whether the machine should be started in enforcing (1), permissive (0) or 
  disabled (-1) mode.
 */
extern int selinux_getenforcemode(int *enforce);

/*
  selinux_policy_root reads the /etc/selinux/config file and returns 
  the directory path under which the compiled policy file and context 
  configuration files exist.
 */
extern const char *selinux_policy_root(void);

/* These functions return the paths to specific files under the 
   policy root directory. */
extern const char *selinux_binary_policy_path(void);
extern const char *selinux_failsafe_context_path(void);
extern const char *selinux_removable_context_path(void);
extern const char *selinux_default_context_path(void);
extern const char *selinux_user_contexts_path(void);
extern const char *selinux_file_context_path(void);
extern const char *selinux_media_context_path(void);
extern const char *selinux_contexts_path(void);
extern const char *selinux_booleans_path(void);
extern const char *selinux_customizable_types_path(void);
extern const char *selinux_users_path(void);

/* Check a permission in the passwd class.
   Return 0 if granted or -1 otherwise. */
extern int checkPasswdAccess(access_vector_t requested);

/* Set the path to the selinuxfs mount point explicitly.
   Normally, this is determined automatically during libselinux 
   initialization, but this is not always possible, e.g. for /sbin/init
   which performs the initial mount of selinuxfs. */
void set_selinuxmnt(char *mnt);

/* Execute a helper for rpm in an appropriate security context. */
extern int rpm_execcon(unsigned int verified, 
		       const char *filename, 
		       char *const argv[], char *const envp[]);

/* Returns whether a file context is customizable, and should not 
   be relabeled . */
extern int is_context_customizable (security_context_t scontext);

/* Create a policy database */
extern int security_create_policydb(
	policydb_ref_t* policydb,
	const char* sel_root,
	int setbools_arg);

/* Create a policydb from the default configuration */
static inline int security_create_default_policydb(policydb_ref_t* policydb) {
	return security_create_policydb(policydb, selinux_policy_root(), 1);
}

/* Destroy a policy database */
static inline void security_destroy_policydb(policydb_ref_t policydb) {
	policydb_destroy(policydb);
}

/* Load a policy database */
extern int security_load_policydb(policydb_ref_t policydb);

/* Load a policy image. */
extern int security_load_policy(void *data, size_t len);


#ifdef __cplusplus
}
#endif

#endif

RE: file contexts and modularity

[Ivan Gyurdiev]

[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]


> Deleting specific lines from the file contexts file seems difficult and error
> prone while regenerating is straight forward. Only one code path (generation)
> instead of many (add, remove, change, etc).

You know... there is something good about regenerating things - it makes
sure the file is correct.

And my current way to add records to file is error prone - basically
I seek to the end of file, and add stuff there. That (1) doesn't
validate the rest of the file, and (2) is not atomic. I might
want to validate the rest of the file whether or not 
I think the errors are fatal (just to warn the user).

I've changed my modify_file function to do adds as well... 
The handler can now signal SIGADD to modify(), as well
as SIGDEL (and SIGOK/SIGERR/SIGEXIT/SIGMATCH). Then
there's a feedback record that the handler can pass
to be written. 

This:
- ensures atomicity (rename() call in the end)
- allows me to write records in the middle of the file if I please
- allows me to do validation (against policy), since the file 
might as well be checked while it's being parsed

Now I just need to figure out how to rollback handler side effects
(like loading users into the policy...)

Internal header attached.

To answer your question as to what's specific to the file backend - 
basically most of this... but not the record data structures.



[-- Attachment #2: records_file.h --]
[-- Type: text/x-chdr, Size: 2602 bytes --]

#ifndef _SEPOL_RECORD_FILE_H_
#define _SEPOL_RECORD_FILE_H_

#ifndef RECORD_DEFINED
typedef void* record_t;
#define RECORD_DEFINED
#endif

#define RECORD_HANDLER_SIGOK 	0x00000001
#define RECORD_HANDLER_SIGERR	0x00000002
#define RECORD_HANDLER_SIGMATCH 0x00000004
#define RECORD_HANDLER_SIGDEL	0x00000008
#define RECORD_HANDLER_SIGADD   0x00000010
#define RECORD_HANDLER_SIGEXIT  0x00000020

typedef struct parse_info {
	unsigned int lineno;
	char* orig_line;
	char* working_copy;
	char* ptr;
	const char* filename;

	FILE* file_stream;
	FILE* copy_stream;

	void* parse_arg;
} parse_info_t;

typedef struct record_table {
	record_t (*create) (void);
	void (*destroy) (record_t record);
	int (*parse) (parse_info_t* info, record_t record);
	int (*print) (record_t record, FILE* str);
} record_table_t;

/*
 * Iterate over all records in the given file,
 * and invoke the handler with its given argument on each record.
 * The handler is supplied a record_t structure containing
 * the parsed data.
 */

int record_iterate_file(
	const char* filename,
	record_table_t* rtable,
	void* parse_arg,
	int (*handler) (
		record_t process_record, 
		record_t* feedback_record,
		void* arg), void* arg,
	int perr_fatal, int merr_fatal);
/*
 * Copy filename to filename.tmp, updating a particular record.
 * Invoke the handler, which may update the record, or issue a
 * delete signal. On failure, the tmp file is erased.
 * On success, the tmp file replaces the old file.
 */
int record_modify_file(
        const char* filename,
        record_table_t* rtable,
	void* parse_arg, 
	int (*handler) (
		record_t process_record, 
		record_t* feedback_record,
		void* arg), void* arg,
	int perr_fatal, int merr_fatal);

/*
 * Add a record to the config file (local) and to policy.
 * Please note that those functions are not atomic like
 * modify, and do not provide control over validation 
 */
int record_addto_file(
	const char* filename,
	record_table_t* rtable,
	record_t record);

int records_addto_file(
	const char* filename,
	record_table_t* rtable,
	record_t* records);

char* record_search_and_replace(const char* str,
	const char* substr, const char* replace);

char* record_filter_space_until(parse_info_t* info,
	const char* substr);

void record_dispose_line(parse_info_t* info);
int record_skip_space(parse_info_t* info);
char* record_fetch_string_inplace(parse_info_t* info);
int record_assert_noeof(parse_info_t* info);
int record_assert_space(parse_info_t* info);
int record_assert_ch(parse_info_t* info, const char ch);
int record_assert_str(parse_info_t* info, const char* assert_str);

#endif

RE: file contexts and modularity

[Stephen Smalley]

On Thu, 2005-06-23 at 16:28 -0400, Ivan Gyurdiev wrote:
>Karl MacMillan wrote:
> > Not certain, therefore, that libsepol is the correct place for the
> > client api (e.g. the one used by useradd). Thoughts?
> 
> It's difficult to me to write forward portable code, when I don't
> know the future :)

True.  But we can at least seek to provide an interface to useradd from
libsepol that doesn't expose the fact that we are necessarily dealing
with a binary policy file/image, just an abstract policy object that may
be backed by a binary policy or may be backed by the policy daemon.

-- 
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: file contexts and modularity

[Stephen Smalley]

On Thu, 2005-06-23 at 16:28 -0400, Ivan Gyurdiev wrote:
> it still takes 4 seconds for useradd to load the policy.
> It's awfully slow.... that's 2x policydb_read, because of
> the verify-after-write. 

This is something that I think merits further discussion.  I think that
the real problem is that the avtab size has grown far beyond what we
originally anticipated and this is hurting us both in time (to
manipulate policies, to load policies, and even to search the avtab) and
in space (kernel memory consumption by the avtab is huge).  We certainly
didn't expect the avtab to reach 484,677 distinct entries (FC4 strict
policy) and even the targeted policy in FC4 is now up to 215886 entries.
While the loadable/binary policy module work may help somewhat by
allowing us to omit policy modules easily for packages that are not
installed and the userspace security server will allow us to omit
userspace policy from the kernel, I still expect this to be a problem
for default installs and general purpose systems, particularly as we
begin to extend SELinux into securing the desktop.  This suggests that
we may need to refactor the data representation for the avtab, replacing
it with a more compact representation that will require more complex and
likely slower computation in the kernel for security_compute_av (but
this should mostly be hidden by the AVC).  In effect, something more
like the avrules of the module work, i.e. more like policy.conf itself,
where we can store multiple classes and multiple types in a single
entry, and possibly even preserve the notion of type attributes to
reduce the need for storing the same (large) type set repeatedly.  Also,
a direct representation of the notion of unconfined might be useful in
eliminating policy bloat, although that is difficult to capture and
targeted policy has been denying even unconfined certain permissions if
certain booleans are disabled (e.g. execmem/execmod).

-- 
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: file contexts and modularity

[Karl MacMillan]

> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> Sent: Friday, June 24, 2005 8:22 AM
> To: ivg2@cornell.edu
> Cc: James Morris; Karl MacMillan; selinux@tycho.nsa.gov; 'Daniel J Walsh'
> Subject: RE: file contexts and modularity
> 
> On Thu, 2005-06-23 at 16:28 -0400, Ivan Gyurdiev wrote:
> > it still takes 4 seconds for useradd to load the policy.
> > It's awfully slow.... that's 2x policydb_read, because of
> > the verify-after-write.
> 
> This is something that I think merits further discussion.  I think that
> the real problem is that the avtab size has grown far beyond what we
> originally anticipated and this is hurting us both in time (to
> manipulate policies, to load policies, and even to search the avtab) and
> in space (kernel memory consumption by the avtab is huge).  We certainly
> didn't expect the avtab to reach 484,677 distinct entries (FC4 strict
> policy) and even the targeted policy in FC4 is now up to 215886 entries.

And this seems to be one of the most common complaints that people make.

> While the loadable/binary policy module work may help somewhat by
> allowing us to omit policy modules easily for packages that are not
> installed and the userspace security server will allow us to omit
> userspace policy from the kernel, I still expect this to be a problem
> for default installs and general purpose systems, particularly as we
> begin to extend SELinux into securing the desktop. 

I agree - the loadable modules will probably be a small help.

> This suggests that
> we may need to refactor the data representation for the avtab, replacing
> it with a more compact representation that will require more complex and
> likely slower computation in the kernel for security_compute_av (but
> this should mostly be hidden by the AVC).  In effect, something more
> like the avrules of the module work, i.e. more like policy.conf itself,
> where we can store multiple classes and multiple types in a single
> entry, and possibly even preserve the notion of type attributes to
> reduce the need for storing the same (large) type set repeatedly.

This seems like too large a step. What's really funny is that we added a
hashtable similar to the avtab to libapol for sediff because the rule storage
(which is similar to what was added for the module work) was too slow /
cumbersome for certain types of analysis. Additionally, I think that we want to
avoid data structures that force memory allocation in the security_compute_av
code path.

The most obvious compromise is simply putting attributes in the avtab. This
would require adding a reverse map from types to attributes probably. Lookup
complexity would be, I think, worst case O(N^2) where N is the number
attributes. Actually O(N^2 + N^2) because of the conditional avtab lookup.

Other ideas:
- reducing our namespaces to 16bits. Do we really need 32 bits for types,
attributes, and object classes?

- Automatic merging of similar/identical type/object class triplets. This would
be a big win for the 10,000 domain web hosting machine use case.

>  Also,
> a direct representation of the notion of unconfined might be useful in
> eliminating policy bloat, although that is difficult to capture and
> targeted policy has been denying even unconfined certain permissions if
> certain booleans are disabled (e.g. execmem/execmod).
> 

Interesting - maybe store unconfined as exceptions rather than what is allowed?

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134

> --
> 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: file contexts and modularity

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:ivg2@cornell.edu]
> Sent: Thursday, June 23, 2005 4:29 PM
> To: Karl MacMillan
> Cc: selinux@tycho.nsa.gov; 'Daniel J Walsh'
> Subject: RE: file contexts and modularity
> 
> 
> > Why have a file per user?
> 
> I thought that's what you were suggesting - store per user contexts
> in their own file, and then re-generate the end result from that.
> 
> Alternatively it could all be in one big file, but then I
> don't have any information what came from where. Regenerating
> the regexps from the template (1) requires delete
> to have the same information as add, which is otherwise
> not necessary. Currently that consists of the home dirs, but
> in the future it could consist of other stuff too, and
> (2) requires me to match every line in homedirs against
> every template expression, which just seems unnecessary.
> 

What's wrong with:

1) Read file contexts with ROLE, etc. still present.
2) Extract all context lines with ROLE.
3) Write all plain context lines to new file.
4) Iterate through users and append to the new file all of the extracted context
lines with ROLE, etc statements replaced.
5) Replace old file contexts file with new one.

Shouldn't be that expensive and is about as simple as possible.

> > > > Can you give an overview of these patches - what you are trying to
> > > accomplish in
> > > > more detail and the design?
> > >
> > > Well I was trying to accomplish the following:
> > >
> > > - add -R flag to useradd, and have it automatically validate
> > > and add user roles, and generate user contexts (and add user to running
> > > policy)
> > >
> > > - have userdel undo the above
> > >
> > > - have usermod modify user roles in file and policy, and on default
> > > role change, recreate the contexts.
> > >
> >
> > We were planning on deprecating seuser because of general bit rot. It does
> do
> > all of this (through wrappers, etc) so if any of that code is useful feel
> free
> > to grab it (it's GPL).
> 
> Is seuser a library or a command line tool? I want to write a library..
> 
> I'm not sure how much help I need, since I have already made sufficient
> progress on this - I can successfully complete add, and
> then delete and modify shouldn't be all that hard, once
> I decide what to do about finding the user contexts.
> 
> I still need to add more validation, and rollback...
> 

There is a library that is for manipulating the policy to add users. It's all
libapol based, though.

> > > - make policydb an opaque data structure to address the
> > > exposure created above
> > >
> >
> > Great - and then various helper functions can be added incrementally until
> there
> > is a full API.
> 
> Right....however I'm making an incompatible change here.
> policydb_destroy has been changed to free the policy, which
> requires all policydb structures to be created on the heap
> via policydb_create. I have to fix existing users.
> 

You could also provide an alloca interface if there is a compelling reason for
callers to have the db on the stack.

> >
> > Hmm . . . why have the records so directly tied to files? Seems like the API
> > needs to be a little higher level to actually make it work with something
> like
> > an LDAP backend.
> 
> They are not... the record structure itself is located in a separate
> file. The create/destroy/set/get methods are packaged with the record.
> The record thing isn't much more than a wrapper around a struct.
> I don't use internal selinux datums for this, because I want to stay
> close to the format used in the outside world (human readable strings).
> 
> The parse/print methods are packaged separately, because they are
> file dependent. The record_iterate and record_modify_file are obviously
> file dependent. Someone can implement the top level functions
> in a different way with a different backend.
> 
> > Thanks for the overview - it has clarified some things for me. I'm trying to
> get
> > a handle on how we want things to look in the future. One concern is that
> this
> > api uses libsepol - e.g. it makes it clear to the caller that it is
> manipulating
> > a policy file. We have been discussing / imagining an API that will be
> forward
> > portable to the policy server where the act of adding a user might involve
> and
> > IPC call to the server and be significantly more abstract than a policy
> > manipulation.
> 
> Take a look at attached headers, and see if you can make suggestions.
> Yes, I know I should probably prefix those records with something sane,
> but I haven't done that yet.
> 

After some thought - I have an alternative suggestion that I will put in another
email.

Karl

> I'm considering removing the user/type/role/mls fields from
> port and fscon, and making that part of the common context_record.h
> instead.
> 
> > Not certain, therefore, that libsepol is the correct place for the
> > client api (e.g. the one used by useradd). Thoughts?
> 
> It's difficult to me to write forward portable code, when I don't
> know the future :)

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134



--
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: file contexts and modularity

[Ivan Gyurdiev]

On Fri, 2005-06-24 at 08:08 -0400, Stephen Smalley wrote:
> On Thu, 2005-06-23 at 16:28 -0400, Ivan Gyurdiev wrote:
> >Karl MacMillan wrote:
> > > Not certain, therefore, that libsepol is the correct place for the
> > > client api (e.g. the one used by useradd). Thoughts?
> > 
> > It's difficult to me to write forward portable code, when I don't
> > know the future :)
> 
> True.  But we can at least seek to provide an interface to useradd from
> libsepol that doesn't expose the fact that we are necessarily dealing
> with a binary policy file/image, just an abstract policy object that may
> be backed by a binary policy or may be backed by the policy daemon.

The current interface keeps the policydb_t as an opaque data structure..
On the other hand it also passes in a sel_root parameter (for
selinux_policy_root(), which I'm not so sure about).




--
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: file contexts and modularity

[Casey Schaufler]

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:

> This is something that I think merits further
> discussion.  I think that
> the real problem is that the avtab size has grown
> far beyond what we
> originally anticipated and this is hurting us both
> in time (to
> manipulate policies, to load policies, and even to
> search the avtab) and
> in space (kernel memory consumption by the avtab is
> huge).  We certainly
> didn't expect the avtab to reach 484,677 distinct
> entries (FC4 strict
> policy) and even the targeted policy in FC4 is now
> up to 215886 entries.

With close to half a million (Ack!) rules you
end up with a memory burden that would be
excessive even if you could represent a rule in
a single byte. Oh sure, you could swap out rule
pages on a LRU scheme, or hash them to death,
but the basic problem is not the representation
of hundreds of thousands of rules, it's a matter
of having hundreds of thousands of rules. Good
heavens, the policy file is starting to look
like the IRS tax code.

The solution does not lie in the direction
of kernel hacking, as much fun as that is.

Why are there so many rules? You can correct
me if I'm wrong, but these (somewhat jaded)
eyes see a piecemeal approach to the
introduction of new rules. There is serious
effort going into defining policies that
match behavior and since there are so many
different behaviors there is an explosion of
rules required to match them.

I suggest that if you want to address this
issue properly you need to back away from the
current method of developing policy.

Design your policy, then implement it rather
than sniffing out what programs do and then
crafting a policy to accomodate their whims.
I suggest you begin with a policy that includes
exactly two domains, User and System. Create
the rule set that provides this two state level
of protection. If a policy with two domains is
too stiffling use more, but define them first.

I don't believe that this is an easy path,
nor would I expect it to be popular. On the
other hand I guarantee you'll reduce the size
of the policy by a factor of 10. I also opine
that the actual system vulnerability will
decline due to better understanding of the
policy. I will also help address some of the
issues floating about regarding 3rd party
policy creation, what with having a designed
policy that a developer can follow instead
of the notion of "run strace and audit and
do magic".

It's what we had to do to create Unix MLS
systems. The casualty rate wasn't too high,
although it's true that we didn't get invited
to lots of partys afterward. Oh well, y'all
knew the job was dangerous when you took it.



Casey Schaufler
casey@schaufler-ca.com


		
____________________________________________________ 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.yahoo.com

--
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: file contexts and modularity

[Ivan Gyurdiev]

> What's wrong with:
> 
> 1) Read file contexts with ROLE, etc. still present.
> 2) Extract all context lines with ROLE.

Okay..

> 3) Write all plain context lines to new file.

There should be none of those...

> 4) Iterate through users and append to the new file all of the extracted context
> lines with ROLE, etc statements replaced.

The replace is a pain to do... and if there's a whole lot
of users I have to do it a whole lot of times.

Furthermore I may or may not want to affect other users
with modifications to my single user that I'm interested in.
Right now I will validate all users when passing through the file,
but will not modify anything that does not concern me, 
whether there's an error or not.

Also, there's no reason why delete should have to gather data like
add for expansions - I don't want to require the same interface
for delete as for add... you're saying I should require information on
all home directories (and/or any future expansion that we may 
decide to add) just to delete some user...

> 5) Replace old file contexts file with new one.

Yes... I was appending to the old file previously, but
copy/modify and replace is the way to go.



--
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: file contexts and modularity

[Karl MacMillan]

> -----Original Message-----
> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov] On
> Behalf Of Karl MacMillan
> Sent: Friday, June 24, 2005 10:31 AM
> To: 'Stephen Smalley'; ivg2@cornell.edu
> Cc: 'James Morris'; selinux@tycho.nsa.gov; 'Daniel J Walsh'
> Subject: RE: file contexts and modularity
> 
> > -----Original Message-----
> > From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> > Sent: Friday, June 24, 2005 8:22 AM
> > To: ivg2@cornell.edu
> > Cc: James Morris; Karl MacMillan; selinux@tycho.nsa.gov; 'Daniel J Walsh'
> > Subject: RE: file contexts and modularity
> >
> > On Thu, 2005-06-23 at 16:28 -0400, Ivan Gyurdiev wrote:
> > > it still takes 4 seconds for useradd to load the policy.
> > > It's awfully slow.... that's 2x policydb_read, because of
> > > the verify-after-write.
> >
> > This is something that I think merits further discussion.  I think that
> > the real problem is that the avtab size has grown far beyond what we
> > originally anticipated and this is hurting us both in time (to
> > manipulate policies, to load policies, and even to search the avtab) and
> > in space (kernel memory consumption by the avtab is huge).  We certainly
> > didn't expect the avtab to reach 484,677 distinct entries (FC4 strict
> > policy) and even the targeted policy in FC4 is now up to 215886 entries.
> 
> And this seems to be one of the most common complaints that people make.
> 
> > While the loadable/binary policy module work may help somewhat by
> > allowing us to omit policy modules easily for packages that are not
> > installed and the userspace security server will allow us to omit
> > userspace policy from the kernel, I still expect this to be a problem
> > for default installs and general purpose systems, particularly as we
> > begin to extend SELinux into securing the desktop.
> 
> I agree - the loadable modules will probably be a small help.
> 
> > This suggests that
> > we may need to refactor the data representation for the avtab, replacing
> > it with a more compact representation that will require more complex and
> > likely slower computation in the kernel for security_compute_av (but
> > this should mostly be hidden by the AVC).  In effect, something more
> > like the avrules of the module work, i.e. more like policy.conf itself,
> > where we can store multiple classes and multiple types in a single
> > entry, and possibly even preserve the notion of type attributes to
> > reduce the need for storing the same (large) type set repeatedly.
> 
> This seems like too large a step. What's really funny is that we added a
> hashtable similar to the avtab to libapol for sediff because the rule storage
> (which is similar to what was added for the module work) was too slow /
> cumbersome for certain types of analysis. Additionally, I think that we want
> to
> avoid data structures that force memory allocation in the security_compute_av
> code path.
> 
> The most obvious compromise is simply putting attributes in the avtab. This
> would require adding a reverse map from types to attributes probably. Lookup
> complexity would be, I think, worst case O(N^2) where N is the number
> attributes. Actually O(N^2 + N^2) because of the conditional avtab lookup.
> 
> Other ideas:
> - reducing our namespaces to 16bits. Do we really need 32 bits for types,
> attributes, and object classes?
> 
> - Automatic merging of similar/identical type/object class triplets. This
> would
> be a big win for the 10,000 domain web hosting machine use case.
> 

One more idea - remove the multiple data fields in avtab_datum and have multiple
entries for each key representing different rule types. If a small enough
percentage of keys have only 1 type of rule (probably allow) then this should be
a win. Haven't done the analysis of a real policy yet to know if this is a win,
but seems like it would be (and anecdotal evidence from libapol suggests that it
will be - this is similar to how the libapol av hash works).

Karl 

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134

> >  Also,
> > a direct representation of the notion of unconfined might be useful in
> > eliminating policy bloat, although that is difficult to capture and
> > targeted policy has been denying even unconfined certain permissions if
> > certain booleans are disabled (e.g. execmem/execmod).
> >
> 
> Interesting - maybe store unconfined as exceptions rather than what is
> allowed?
> 
> Karl
> 
> ---
> Karl MacMillan
> Tresys Technology
> http://www.tresys.com
> (410) 290-1411 ext 134
> 
> > --
> > 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.



--
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: file contexts and modularity

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:ivg2@cornell.edu]
> Sent: Friday, June 24, 2005 12:03 PM
> To: Karl MacMillan
> Cc: selinux@tycho.nsa.gov; 'Daniel J Walsh'
> Subject: RE: file contexts and modularity
> 
> 
> > What's wrong with:
> >
> > 1) Read file contexts with ROLE, etc. still present.
> > 2) Extract all context lines with ROLE.
> 
> Okay..
> 
> > 3) Write all plain context lines to new file.
> 
> There should be none of those...
> 
> > 4) Iterate through users and append to the new file all of the extracted
> context
> > lines with ROLE, etc statements replaced.
> 
> The replace is a pain to do... and if there's a whole lot
> of users I have to do it a whole lot of times.
> 

This is a performance objection? I can't believe that it will be slow enough to
matter and the tradeoff for obvious correctness seems worth it to me.

> Furthermore I may or may not want to affect other users
> with modifications to my single user that I'm interested in.

? What effect could there be? This file should be reproducible at all times and
should accurately reflect a) the current file contexts as defined by the policy
and b) the current users and their data (home dir, etc).

> Right now I will validate all users when passing through the file,
> but will not modify anything that does not concern me,
> whether there's an error or not.
> 
> Also, there's no reason why delete should have to gather data like
> add for expansions - I don't want to require the same interface
> for delete as for add... you're saying I should require information on
> all home directories (and/or any future expansion that we may
> decide to add) just to delete some user...
> 

Yep. Also, to bring this in line with my other suggestion about how to handle
users in general, it seems like the way to go is to have a chunk of file
contexts for each SELinux user (what I am calling user roles) that is generated
at policy development time. This can be applied to each home directory at user
add/change time. That means that genhomedircon can basically stick around - it
is only a build requirement. This just means we have to have a special setfiles
mode for home directory labeling that uses the correct home directory file
contexts.

Karl

> > 5) Replace old file contexts file with new one.
> 
> Yes... I was appending to the old file previously, but
> copy/modify and replace is the way to go.

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134



--
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: file contexts and modularity

[Karl MacMillan]

> -----Original Message-----
> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov] On
> Behalf Of Casey Schaufler
> Sent: Friday, June 24, 2005 11:51 AM
> To: selinux@tycho.nsa.gov
> Subject: RE: file contexts and modularity
> 
> 
> 
> --- Stephen Smalley <sds@tycho.nsa.gov> wrote:
> 
> > This is something that I think merits further
> > discussion.  I think that
> > the real problem is that the avtab size has grown
> > far beyond what we
> > originally anticipated and this is hurting us both
> > in time (to
> > manipulate policies, to load policies, and even to
> > search the avtab) and
> > in space (kernel memory consumption by the avtab is
> > huge).  We certainly
> > didn't expect the avtab to reach 484,677 distinct
> > entries (FC4 strict
> > policy) and even the targeted policy in FC4 is now
> > up to 215886 entries.
> 
> With close to half a million (Ack!) rules you
> end up with a memory burden that would be
> excessive even if you could represent a rule in
> a single byte. Oh sure, you could swap out rule
> pages on a LRU scheme, or hash them to death,
> but the basic problem is not the representation
> of hundreds of thousands of rules, it's a matter
> of having hundreds of thousands of rules. Good
> heavens, the policy file is starting to look
> like the IRS tax code.
> 

Let's try to separate out the problems correctly. There are 2 issues:

1) The current kernel avtab makes an inappropriate space / time tradeoff.
2) The current policies are not sufficiently designed and may have too many
rules.

1 can be fixed even if 2 is true, which it might be. We are trying to address
that with refpolicy. I would encourage you to make concrete suggestions for the
reference policy - one of its aims is to add the design component to SELinux
policies that you are suggesting. Otherwise, your opinions on SELinux policies
are clear at this point - is it doing any good to restate them in threads that
are only tangentially related?

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134

> 
> Casey Schaufler
> casey@schaufler-ca.com
> 
> 
> 
> ____________________________________________________
> Yahoo! Sports
> Rekindle the Rivalries. Sign up for Fantasy Football
> http://football.fantasysports.yahoo.com
> 
> --
> 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: file contexts and modularity

[Casey Schaufler]

--- Karl MacMillan <kmacmillan@tresys.com> wrote:


> Let's try to separate out the problems correctly.
> There are 2 issues:
> 
> 1) The current kernel avtab makes an inappropriate
> space / time tradeoff.
> 2) The current policies are not sufficiently
> designed and may have too many
> rules.
> 
> 1 can be fixed even if 2 is true, which it might be.

Is it valuable to do 1 in the face of 2?
Sorry, my pointy hair side can't see doing
much about 1 in the light of 2.

> We are trying to address that with refpolicy.

Great.

> I would encourage you to make
> concrete suggestions for the
> reference policy - one of its aims is to add the
> design component to SELinux
> policies that you are suggesting.

Err, I did in the rest of the message.

> Otherwise, your
> opinions on SELinux policies
> are clear at this point - is it doing any good to
> restate them in threads that
> are only tangentially related?

I will pull the elephant off the table
and go back to work. Sorry to have bothered
you.




Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Yahoo! Mail 
Stay connected, organized, and protected. Take the tour: 
http://tour.mail.yahoo.com/mailtour.html 


--
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: file contexts and modularity

[Karl MacMillan]

> -----Original Message-----
> From: Casey Schaufler [mailto:casey@schaufler-ca.com]
> Sent: Friday, June 24, 2005 12:47 PM
> To: Karl MacMillan; selinux@tycho.nsa.gov
> Subject: RE: file contexts and modularity
> 
> 
> 
> --- Karl MacMillan <kmacmillan@tresys.com> wrote:
> 
> 
> > Let's try to separate out the problems correctly.
> > There are 2 issues:
> >
> > 1) The current kernel avtab makes an inappropriate
> > space / time tradeoff.
> > 2) The current policies are not sufficiently
> > designed and may have too many
> > rules.
> >
> > 1 can be fixed even if 2 is true, which it might be.
> 
> Is it valuable to do 1 in the face of 2?
> Sorry, my pointy hair side can't see doing
> much about 1 in the light of 2.
> 

Yes - I think that there are going to be valid policy usage patterns that will
generate a large number of rules for the foreseeable future. That, coupled with
the very high cache hit ratio, means that work on 1 is valuable.

Karl 

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134

> 
> 
> Casey Schaufler
> casey@schaufler-ca.com
> 
> 
> 
> __________________________________
> Yahoo! Mail
> Stay connected, organized, and protected. Take the tour:
> http://tour.mail.yahoo.com/mailtour.html



--
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: file contexts and modularity

[Casey Schaufler]

--- Karl MacMillan <kmacmillan@tresys.com> wrote:

> Yes - I think that there are going to be
> valid policy usage patterns that will
> generate a large number of rules for the
> foreseeable future.

I expect you speak the truth.

> That, coupled with
> the very high cache hit ratio, means that
> work on 1 is valuable.

I can't argue with that.



Casey Schaufler
casey@schaufler-ca.com

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
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: file contexts and modularity

[Ivan Gyurdiev]

> > Also, there's no reason why delete should have to gather data like
> > add for expansions - I don't want to require the same interface
> > for delete as for add... you're saying I should require information on
> > all home directories (and/or any future expansion that we may
> > decide to add) just to delete some user...
> > 
> 
> Yep.

...why? this seems like a bad idea...
gathering this information may or may not be trivial/cheap 
in the future... what if you have 100000 users, and their
/etc/passwd data is kept in LDAP. 

Delete should not require info that does not pertain to 
its designated operation (removing contexts for a single user,
not adding contexts for *all* users in the process)

>  Also, to bring this in line with my other suggestion about how to handle
> users in general, it seems like the way to go is to have a chunk of file
> contexts for each SELinux user (what I am calling user roles) that is generated
> at policy development time. 

You can't generate per user contexts at policy development time - the
users can and will change after that time.

> This can be applied to each home directory at user
> add/change time. 
> 
That sounds like the template system that we have currently - how 
is this proposal different? 

> That means that genhomedircon can basically stick around - it
> is only a build requirement. This just means we have to have a special setfiles
> mode for home directory labeling that uses the correct home directory file
> contexts.

So you're saying that the per user contexts shouldn't even be 
*generated* - you should interpret the expansions in matchpathcon?

This is making matchpathcon too smart...but I haven't looked
at that code, so I don't know if that's a good idea.

Please don't assume path expansions have anything to do with the home
dir. I've already added one that expands to the user name, and may
add others in the future. 


--
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: file contexts and modularity

[Frank Mayer]

Karl MacMillan wrote:
> One more idea - remove the multiple data fields in avtab_datum and
> have multiple entries for each key representing different rule types.
> If a small enough percentage of keys have only 1 type of rule
> (probably allow) then this should be a win. Haven't done the analysis
> of a real policy yet to know if this is a win, but seems like it
> would be (and anecdotal evidence from libapol suggests that it will
> be - this is similar to how the libapol av hash works).      

Just to expand on this, we have contemplated making this change in the past.
Here's a quick analysis: An avtab_datum_t is 4 x 32 bit words = 16 bytes .
An avtab node has a 3 x 32 bit (12 bytes) key, an avtab_datum (16 bytes) and
a next pointer (4 bytes) for 32 bytes total. 32 bytes times 100,000s rules
== mucho memory.

Taking am arbitrary sample policy and looking at the stats with apol, I have
298,894 allow rules, 2,076 type_trans rules, 25 type_change rules, 3
auditallow rules, and 53,719 dontaudit rules. Assume that all the
type_change rules share a common key with one of the type_trans rules, and
that all the audit rules share a common key with allow rules (a generally
safe assumption IMHO), we should have 300,970 avtab entries of which only
53,744 use more than one datum. 

So if we eliminated the 3 datum fields and just have one, and use the rule
type already encoded in the specified flag as part of the key (and we
partially do this now anyway), we would add 53,744 avtab entries but reduce
the size of each entry by 8 bytes for a (32-8 = 24) 24 byte avtab node size.


So the avtab that we have now would be 300,970 x 32 bytes = ~9.6MB versus
the alternative avtab of 354,714 * 24 = ~8.5MB or about a ~1.1MB savings
(about 10%) with very little code change and essentially zero performance
impact. If the audit-to-allow rule ration stays 1-10, then this change makes
sense.

I suspect we can look around and find other examples where small or no
performance tradeoffs can made for large size savings. For example if we
make the specified flag 16 bit instead of 32 (we're using less then 16 now),
we could save another ~.7MB of memory, or a total of ~1.8MB or about 19%.
Coupled with smaller policies in the future, we should be able to make
significant progress with less pain than a complete restructure of the
policydb.

If we go ahead and keep attributes around (as we have in the loadable module
work), then the savings can be much greater, but we'd have to study the
performance impacts better. The implementation changes would also be more
radical. For example the same sample policy above that had ~300K allow rules
in the binary policy had only ~27K allow rules in the source policy before
expansion. Some rules will expand anyway because of multiple classes, but I
believe most expansion is due to attribute expansion.

Frank



--
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: file contexts and modularity

[Stephen Smalley]

On Fri, 2005-06-24 at 11:43 -0400, Ivan Gyurdiev wrote:
> The current interface keeps the policydb_t as an opaque data structure..
> On the other hand it also passes in a sel_root parameter (for
> selinux_policy_root(), which I'm not so sure about).

Yes, I think we need to hide that from adduser.

-- 
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: file contexts and modularity

[Ivan Gyurdiev]

On Fri, 2005-06-24 at 14:32 -0400, Stephen Smalley wrote:
> On Fri, 2005-06-24 at 11:43 -0400, Ivan Gyurdiev wrote:
> > The current interface keeps the policydb_t as an opaque data structure..
> > On the other hand it also passes in a sel_root parameter (for
> > selinux_policy_root(), which I'm not so sure about).
> 
> Yes, I think we need to hide that from adduser.

I could put it in the policydb..

Then when security_create_policydb_default() makes the policydb
it could call policydb_set_root().

I could also remove security_create_policydb() 
(which is the same as security_create_policydb_default, 
except it allows caller to specify the sel_root - 
intended to provide back some of the functionality 
of policycoreutils/load_policy.c arguments).


--
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: file contexts and modularity

[Stephen Smalley]

On Fri, 2005-06-24 at 14:05 -0400, Frank Mayer wrote:
> So the avtab that we have now would be 300,970 x 32 bytes = ~9.6MB versus
> the alternative avtab of 354,714 * 24 = ~8.5MB or about a ~1.1MB savings
> (about 10%) with very little code change and essentially zero performance
> impact. If the audit-to-allow rule ration stays 1-10, then this change makes
> sense.
> 
> I suspect we can look around and find other examples where small or no
> performance tradeoffs can made for large size savings. For example if we
> make the specified flag 16 bit instead of 32 (we're using less then 16 now),
> we could save another ~.7MB of memory, or a total of ~1.8MB or about 19%.
> Coupled with smaller policies in the future, we should be able to make
> significant progress with less pain than a complete restructure of the
> policydb.

While I agree that saving space in the avtab nodes will help and is
desirable, I don't think it is going to be sufficient; I think we have
to reduce the sheer numbers of such nodes, and I'm not convinced that
the loadable module support and the reference policy will result in a
sufficiently small avtab.  So I think we need to take it another step...

> If we go ahead and keep attributes around (as we have in the loadable module
> work), then the savings can be much greater, but we'd have to study the
> performance impacts better. The implementation changes would also be more
> radical. For example the same sample policy above that had ~300K allow rules
> in the binary policy had only ~27K allow rules in the source policy before
> expansion. Some rules will expand anyway because of multiple classes, but I
> believe most expansion is due to attribute expansion.

Yes, I think we should investigate this idea, despite its impact on the
existing code, as it should significantly reduce the number of avtab
nodes.

-- 
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: file contexts and modularity

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:ivg2@cornell.edu]
> Sent: Friday, June 24, 2005 1:56 PM
> To: Karl MacMillan
> Cc: selinux@tycho.nsa.gov; 'Daniel J Walsh'
> Subject: RE: file contexts and modularity
> 
> 
> > > Also, there's no reason why delete should have to gather data like
> > > add for expansions - I don't want to require the same interface
> > > for delete as for add... you're saying I should require information on
> > > all home directories (and/or any future expansion that we may
> > > decide to add) just to delete some user...
> > >
> >
> > Yep.
> 
> ...why? this seems like a bad idea...
> gathering this information may or may not be trivial/cheap
> in the future... what if you have 100000 users, and their
> /etc/passwd data is kept in LDAP.
> 

You only have to do this for the users that are on a given system I guess.

> Delete should not require info that does not pertain to
> its designated operation (removing contexts for a single user,
> not adding contexts for *all* users in the process)
> 

That's true - this is what lead you down the path of separate files per user,
which I didn't understand until now.

> >  Also, to bring this in line with my other suggestion about how to handle
> > users in general, it seems like the way to go is to have a chunk of file
> > contexts for each SELinux user (what I am calling user roles) that is
> generated
> > at policy development time.
> 
> You can't generate per user contexts at policy development time - the
> users can and will change after that time.
> 
> > This can be applied to each home directory at user
> > add/change time.
> >
> That sounds like the template system that we have currently - how
> is this proposal different?
> 
> > That means that genhomedircon can basically stick around - it
> > is only a build requirement. This just means we have to have a special
> setfiles
> > mode for home directory labeling that uses the correct home directory file
> > contexts.
> 
> So you're saying that the per user contexts shouldn't even be
> *generated* - you should interpret the expansions in matchpathcon?
> 
> This is making matchpathcon too smart...but I haven't looked
> at that code, so I don't know if that's a good idea.
> 
> Please don't assume path expansions have anything to do with the home
> dir. I've already added one that expands to the user name, and may
> add others in the future.

How can the path expansions not include home dir? Otherwise, how do you resolve
conflicts between multiple users? I can't see how it is possible to do ROLE (or
USER or LINUX_USER) expansion for any path that is not in a home directory.

I think that we are hitting many of the same problems that existed with your
home directory labeling scripts. I don't have any good solutions, but let me try
to characterize the problem.

The current file_contexts contains labeling information for both application
policies and _every_ user's home directory that is authorized to log into the
system. There are many limitations:

1) We don't support non-local users - genhomedircon reads /etc/passwd.
2) Large numbers of users will make file_contexts very large with mostly
redundant data.

The current suggestion is two-fold:

1) Add APIs to libsepol to allow convenient addition of file_context information
for each user.
2) Modify applications (adduser) to use this API.

This retains the basic assumption that all user home directory labeling
information will be in the file_contexts. It has some drawbacks:

- A user must be added on that machine to have the labeling information present
(a problem for network mounted home dirs).
- Individual user information (which is now decoupled from the policy via the
suggested user management approach) still is present in file_contexts.
- It is not clear what would happen when a loadable policy module is added that
has home directory labeling information - will there be sufficient user
information around to regenerate the file_contexts?
- How can a policy switch be done - how does the per-user information migrate to
the new policy for the switch?

An alternative option is to leave the home directory keywords unexpanded and
have matchpatchcon expand them on demand. This requires knowledge of what is a
home directory, which is difficult to get. We can either store that information
somewhere or require the caller to provide, e.g., setfiles could get a flag that
to allow the admin to specify which directories are home directories.

Anyone else have some insight? It really files like we are over-engineering this
problem and there is some simple solution once we fully understand the problem.
I have the gut feeling that pre-expanded file_contexts is the wrong way to go,
but no clear argument as to why. 

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134



--
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: file contexts and modularity

[Ivan Gyurdiev]

> An alternative option is to leave the home directory keywords unexpanded and
> have matchpatchcon expand them on demand. This requires knowledge of what is a
> home directory, which is difficult to get. We can either store that information
> somewhere or require the caller to provide, e.g., setfiles could get a flag that
> to allow the admin to specify which directories are home directories.

I disagree that expansions necessarily have to relate to home
directories, and I think it's difficult to predict how expansions will
work in the future. It's hard to come up with a concrete example - this
really depends on what we choose to do with policy in the future.
The point is that we are moving complex logic into a low-level program
such as matchpathcon...and I'm not sure we should do that. It's
a layering issue - where should complexity be placed.

> Anyone else have some insight? It really files like we are over-engineering this
> problem and there is some simple solution once we fully understand the problem.
> I have the gut feeling that pre-expanded file_contexts is the wrong way to go,
> but no clear argument as to why. 

You have a point that we're storing mostly redundant information, but
that's often necessary to achieve speed and simplicity - isn't that
exactly the problem with the in-kernel 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: file contexts and modularity

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:ivg2@cornell.edu]
> Sent: Monday, June 27, 2005 11:37 AM
> To: Karl MacMillan
> Cc: selinux@tycho.nsa.gov; 'Daniel J Walsh'
> Subject: RE: file contexts and modularity
> 
> 
> > An alternative option is to leave the home directory keywords unexpanded and
> > have matchpatchcon expand them on demand. This requires knowledge of what is
> a
> > home directory, which is difficult to get. We can either store that
> information
> > somewhere or require the caller to provide, e.g., setfiles could get a flag
> that
> > to allow the admin to specify which directories are home directories.
> 
> I disagree that expansions necessarily have to relate to home
> directories, and I think it's difficult to predict how expansions will
> work in the future. It's hard to come up with a concrete example - this
> really depends on what we choose to do with policy in the future.
> The point is that we are moving complex logic into a low-level program
> such as matchpathcon...and I'm not sure we should do that. It's
> a layering issue - where should complexity be placed.
> 

How would a non-home directory expansion work?

/tmp/ROLE-foo	user:role:type

What role would this be? All roles? Currently the role is derived based on the
weak notion of primary role for each user - which has to be part of the home
directory. Without a compelling use case I think that this is a slippery slope
that could cause problems.

> > Anyone else have some insight? It really files like we are over-engineering
> this
> > problem and there is some simple solution once we fully understand the
> problem.
> > I have the gut feeling that pre-expanded file_contexts is the wrong way to
> go,
> > but no clear argument as to why.
> 
> You have a point that we're storing mostly redundant information, but
> that's often necessary to achieve speed and simplicity - isn't that
> exactly the problem with the in-kernel policy?

I more concerned about the other questions - how would a user switch policies
with this scheme? How would network home directories work? Tying the creation of
the labeling information to calling adduser seems fragile.

Karl 

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134



--
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: file contexts and modularity

[Ivan Gyurdiev]

> How would a non-home directory expansion work?

I can't answer this question, but I think claiming that such use
cases will not exist in the future is not warranted.

Why do expansions exist? Because we can't hardcode user information,
and this information has to be extracted as the users are created.

What makes you think this can't occur in other situations in the future.
Consider a scenario where you don't know the locations of things
in advance, and you have to query some sort of external source
to find that out... say GNOME implements a download folder, like 
I've been saying they should. I remember someone on the usability
list argued that it might be a smart idea to have its name be
configurable via GConf key. I don't know how good of an idea that is,
but now you have another thing which doesn't have a fixed name, and
you have to extract from an external source. I can easily see 
something like this being used in the future:

HOME_DIR/GNOME_MEDIA -- gnome_media_content_t
HOME_DIR/GNOME_...blah

and that's just one scenario.

Consider that one of the major problems of SELinux today is how
location-oriented labeling is - it's focused on where the data
is, not what the data is. Those two things don't always match - 
people use nonstandard locations all the time, and expansions
may be one way to deal with that in the future.

> Without a compelling use case I think that this is a slippery slope
> that could cause problems.

I realize this is not a compelling use case right now, but 
I'm just saying it should be a consideration before we go
and put expansion-handling code into matchpathcon.

> I more concerned about the other questions - how would a user switch policies
> with this scheme? 

Does switching policies require changing the file contexts?
I typically use strict policy, so I'm not sure... 
I suppose this file could be re-generated?

> How would network home directories work?

The same way they work right now?
I didn't realize network home dirs support xattr..

>  Tying the creation of
> the labeling information to calling adduser seems fragile.

Perhaps... 


--
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: file contexts and modularity

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:ivg2@cornell.edu]
> Sent: Monday, June 27, 2005 1:56 PM
> To: Karl MacMillan
> Cc: selinux@tycho.nsa.gov; 'Daniel J Walsh'
> Subject: RE: file contexts and modularity
> 
> 
> > I more concerned about the other questions - how would a user switch
> policies
> > with this scheme?
> 
> Does switching policies require changing the file contexts?
> I typically use strict policy, so I'm not sure...
> I suppose this file could be re-generated?
> 

Yes - the two policies could potentially have no types in common.

> > How would network home directories work?
> 
> The same way they work right now?
> I didn't realize network home dirs support xattr..
> 

They don't, but they will. And they don't really work right now.

Karl

> >  Tying the creation of
> > the labeling information to calling adduser seems fragile.
> 
> Perhaps...

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134



--
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: file contexts and modularity

[Karl MacMillan]

> -----Original Message-----
> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov] On
> Behalf Of Stephen Smalley
> Sent: Friday, June 24, 2005 2:41 PM
> To: Frank Mayer
> Cc: 'Karl MacMillan'; ivg2@cornell.edu; 'James Morris'; selinux@tycho.nsa.gov;
> 'Daniel J Walsh'
> Subject: RE: file contexts and modularity
> 
> > If we go ahead and keep attributes around (as we have in the loadable module
> > work), then the savings can be much greater, but we'd have to study the
> > performance impacts better. The implementation changes would also be more
> > radical. For example the same sample policy above that had ~300K allow rules
> > in the binary policy had only ~27K allow rules in the source policy before
> > expansion. Some rules will expand anyway because of multiple classes, but I
> > believe most expansion is due to attribute expansion.
> 
> Yes, I think we should investigate this idea, despite its impact on the
> existing code, as it should significantly reduce the number of avtab
> nodes.
> 

I went ahead and investigated this a little empirically. I horribly hacked
checkpolicy to not expand attributes on avtab insertion and then compared the
number of nodes generated with this and a non-hacked compiler using the latest
FC4 strict policy. Results:

attributes inserted: 33473
attributes expanded: 402196

Obviously this would be quite an improvement. Out of curiosity, I also looked at
datum usage - i.e., how many of the 3 datums were used on average. Single means
single datum (e.g., there was only an allow rule), double means two (e.g. there
was an allow and an auditallow), etc. Results:

attributes inserted: single: 33473 double: 2943 triple: 0
attributes expanded: single: 381570 double: 20626 triple: 0

The lack of triple made me wonder whether the packing was in fact working - it
is not that surprising, but it is suspicious. So I created a small test case and
verified that it is possible to use all three datums by inserting and allow,
dontaudit, and auditallow with the same keys (not that this makes sense).

Patch below (not really useful - just a hack).

Karl
 
---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134

diff -ruNp --exclude='*~' setest-2/checkpolicy/checkpolicy.c
sf-cvs/selinux-usr/checkpolicy/checkpolicy.c
--- setest-2/checkpolicy/checkpolicy.c	2005-06-28 11:25:11.000000000 -0400
+++ sf-cvs/selinux-usr/checkpolicy/checkpolicy.c	2005-06-24
13:15:38.000000000 -0400
@@ -63,7 +63,6 @@
 #include <stdio.h>
 #include <errno.h>
 #include <sys/mman.h>
-#include <assert.h>
 
 #include <sepol/policydb.h>
 #include <sepol/services.h>
@@ -450,73 +449,6 @@ int change_bool(char *name, int state)
 	return 0;
 }
 
-void compute_avtab_stats(avtab_t *a, uint32_t *du, uint32_t *ae)
-{
-	int i;
-	avtab_ptr_t cur;
-	uint32_t avtab_entries;
-	uint32_t datum_usage[3];
-	uint32_t tmp;
-	
-	avtab_entries = 0;
-	datum_usage[0] = datum_usage[1] = datum_usage[2] = 0;
-	
-	for (i = 0; i < AVTAB_SIZE; i++) {
-		cur = a->htable[i];
-		for (; cur != NULL; cur = cur->next) {
-			avtab_entries++;
-			tmp = cur->datum.specified & AVTAB_AV;
-			if (tmp) {
-				switch (tmp) {
-				case AVTAB_AV:
-					datum_usage[2]++;
-					break;
-				case AVTAB_ALLOWED:
-				case AVTAB_AUDITALLOW:
-				case AVTAB_AUDITDENY:
-					datum_usage[0]++;
-					break;
-				default:
-					datum_usage[1]++;
-				}
-			} else {
-				switch (tmp) {
-				case AVTAB_TYPE:
-					datum_usage[2]++;
-					break;
-				case AVTAB_TRANSITION:
-				case AVTAB_MEMBER:
-				case AVTAB_CHANGE:
-					datum_usage[0]++;
-					break;
-				default:
-					datum_usage[1]++;
-				}
-			}
-		}
-	}
-	
-	*ae += avtab_entries;
-	du[0] += datum_usage[0];
-	du[1] += datum_usage[1];
-	du[2] += datum_usage[2];
-}
-
-void compute_stats(policydb_t *p)
-{
-	uint32_t avtab_entries;
-	uint32_t datum_usage[3];
-	
-	avtab_entries = 0;
-	datum_usage[0] = datum_usage[1] = datum_usage[2] = 0;
-	
-	compute_avtab_stats(&p->te_avtab, datum_usage, &avtab_entries);
-	compute_avtab_stats(&p->te_cond_avtab, datum_usage, &avtab_entries);
-	
-	printf("number entries: %d using %f mb\n", avtab_entries,
((((float)avtab_entries) * sizeof(struct avtab_node)) / 1024) / 1024);
-	printf("single: %d double: %d triple: %d\n", datum_usage[0],
datum_usage[1], datum_usage[2]);
-}
-
 int main(int argc, char **argv)
 {
 	sepol_security_class_t tclass;
@@ -683,7 +615,7 @@ int main(int argc, char **argv)
 		cond_check_type_rules();
 		cond_optimize_lists(policydb.cond_list);
 
-		//check_assertions();
+		check_assertions();
 		if (policydb_errors) 
 			exit(1);
 
@@ -692,12 +624,11 @@ int main(int argc, char **argv)
 			fprintf(stderr, "%s:  policy lacks new netlink classes,
unable to generate policy version %d\n", argv[0], policyvers);
 			exit(1);
 		}
-#if 0
+
 		if (hierarchy_check_constraints(&policydb, error_msg,
sizeof(error_msg))) {
 			fprintf(stderr, "%s\n", error_msg);
 			exit(1);
 		}
-#endif
 
 		/* remove type attributes */
 		hashtab_map_remove_on_error(policydb.p_types.table, 
@@ -710,7 +641,6 @@ int main(int argc, char **argv)
 		exit(1);
 
 	printf("%s:  policy configuration loaded\n", argv[0]);
-	compute_stats(&policydb);
 
 	if (outfile) {
 		printf("%s:  writing binary representation (version %d) to
%s\n",
diff -ruNp --exclude='*~' setest-2/checkpolicy/policy_parse.y
sf-cvs/selinux-usr/checkpolicy/policy_parse.y
--- setest-2/checkpolicy/policy_parse.y	2005-06-28 11:38:33.000000000 -0400
+++ sf-cvs/selinux-usr/checkpolicy/policy_parse.y	2005-06-24
13:15:38.000000000 -0400
@@ -1493,7 +1493,6 @@ static int define_attrib(void)
 	}
 	memset(attr, 0, sizeof(type_datum_t));
 	attr->isattr = TRUE;
-	attr->value = ++policydbp->p_types.nprim;
 	ret = hashtab_insert(policydbp->p_types.table,
 			     id, (hashtab_datum_t) attr);
 	if (ret) {
@@ -1822,7 +1821,7 @@ static int set_types(ebitmap_t *set,
 		free(id);
 		return -1;
 	}
-#if 0
+
 	if (t->isattr) {
 		/* set or clear all types with this attribute,
 		   but do not set anything explicitly cleared previously */
@@ -1843,7 +1842,6 @@ static int set_types(ebitmap_t *set,
 			}
 		}
 	} else {
-#endif
 		/* set or clear one type, but do not set anything
 		   explicitly cleared previously */	
 		if (!(*add)) {
@@ -1857,9 +1855,7 @@ static int set_types(ebitmap_t *set,
 			yywarn(errormsg);
 #endif
 		}
-#if 0
 	}
-#endif
 
 	free(id);
 	*add = 1;

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



--
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: file contexts and modularity

[Stephen Smalley]

On Tue, 2005-06-28 at 11:41 -0400, Karl MacMillan wrote:
> I went ahead and investigated this a little empirically. I horribly hacked
> checkpolicy to not expand attributes on avtab insertion and then compared the
> number of nodes generated with this and a non-hacked compiler using the latest
> FC4 strict policy. Results:
> 
> attributes inserted: 33473
> attributes expanded: 402196
> 
> Obviously this would be quite an improvement. Out of curiosity, I also looked at
> datum usage - i.e., how many of the 3 datums were used on average. Single means
> single datum (e.g., there was only an allow rule), double means two (e.g. there
> was an allow and an auditallow), etc. Results:
> 
> attributes inserted: single: 33473 double: 2943 triple: 0
> attributes expanded: single: 381570 double: 20626 triple: 0
> 
> The lack of triple made me wonder whether the packing was in fact working - it
> is not that surprising, but it is suspicious. So I created a small test case and
> verified that it is possible to use all three datums by inserting and allow,
> dontaudit, and auditallow with the same keys (not that this makes sense).
> 
> Patch below (not really useful - just a hack).

Thanks.  Yes, I think that this optimization (preserving attributes in
the binary policy and avtab) is going to provide us with the largest
improvement in memory usage and in speeding up policydb reads/writes.  I
also think it will be the easiest to implement while preserving backward
compatibility; I don't think it requires changes to the existing avtab
structures, unlike the other optimizations that were suggested.

-- 
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: file contexts and modularity

[Ivan Gyurdiev]

> > Does switching policies require changing the file contexts?
> > I typically use strict policy, so I'm not sure...
> > I suppose this file could be re-generated?
> > 
> 
> Yes - the two policies could potentially have no types in common.

So the file would be regenerated when switching policies.
You have to relabel the filesystem anyway - I don't
see why you can't run genhomedircon or whatever 
in the process.

> > > How would network home directories work?
> > 
> > The same way they work right now?
> > I didn't realize network home dirs support xattr..
> > 
> 
> They don't, but they will. And they don't really work right now.

I still don't understand the problem with network home dirs.
How do they require expansion handling inside matchpathcon?

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

I've started to implement some of this new scheme for users - 
I've moved most of my code into libselinux,
and now I'm trying to get it to work again. However, I am not 
clear on how groups will work with this new map file (see other
message), and I'm also not clear on how to get the default
role from libselinux, since there is no such thing - 
what should ROLE expand to - do I have to assume the
first role of the users file is appropriate? 


--
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: file contexts and modularity

[Ivan Gyurdiev]

The more I think about this, the more it seems to me that:

1) Expansions are important, and not to be considered a hack - 
they're our only way to create configurable locations,
which we need, since users don't like to comply with our
standard locations. Expansions don't necessarily relate to home
directories, as I've pointed out.

2) We need a generic mechanism for installing
such expansions, and checking those...

3) Performing expansion of template in matchpathcon seems 
fundamentally wrong to me. The expansion would be performed 
on every invocation, and that would be slow, and unnecessary -
if it's already computed, why not use it? 

4) A context file for each user? Hmm...
500 users...500 files...concat those together?
A large context file with all the users in it doesn't
seem a whole lot better.

[root@celtics files]# cat file_contexts|wc
   2384    6045  102497

[root@celtics files]# cat file_contexts.homedirs|grep root|wc
     47     118    2755

So... say we have a machine with 500 users.
500 * 47 = 23500 lines, or 10 times the size of the current
file_contexts file, which takes forever to read (that's
why install is so slow, right?)

I don't think the current file_contexts approach scales too
well with lots of users...


--
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: file contexts and modularity

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:gyurdiev@redhat.com]
> Sent: Wednesday, June 29, 2005 1:28 PM
> To: Karl MacMillan
> Cc: selinux@tycho.nsa.gov; 'Daniel J Walsh'
> Subject: RE: file contexts and modularity
> 
> The more I think about this, the more it seems to me that:
> 
> 1) Expansions are important, and not to be considered a hack -
> they're our only way to create configurable locations,
> which we need, since users don't like to comply with our
> standard locations. Expansions don't necessarily relate to home
> directories, as I've pointed out.
> 

I still don't agree with this - how do you know how to expand these if it is not
tied to a specific user? Additionally, all of this is caused by using file
contexts for runtime labeling, which I have pointed out repeatedly is a
questionable security practice.

> 2) We need a generic mechanism for installing
> such expansions, and checking those...
> 
> 3) Performing expansion of template in matchpathcon seems
> fundamentally wrong to me. The expansion would be performed
> on every invocation, and that would be slow, and unnecessary -
> if it's already computed, why not use it?
> 

Fundamentally wrong seems a little strong - this is just a space / time tradeoff
not a major architectural decision.

> 4) A context file for each user? Hmm...
> 500 users...500 files...concat those together?
> A large context file with all the users in it doesn't
> seem a whole lot better.
> 
> [root@celtics files]# cat file_contexts|wc
>    2384    6045  102497
> 
> [root@celtics files]# cat file_contexts.homedirs|grep root|wc
>      47     118    2755
> 
> So... say we have a machine with 500 users.
> 500 * 47 = 23500 lines, or 10 times the size of the current
> file_contexts file, which takes forever to read (that's
> why install is so slow, right?)
> 
> I don't think the current file_contexts approach scales too
> well with lots of users...

More importantly, we have just decided to remove specific user information from
the policy and leaving it in the file contexts seems strange.

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134



--
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: file contexts and modularity

[Ivan Gyurdiev]

> I still don't agree with this - how do you know how to expand these if it is not
> tied to a specific user? 

That's my point exactly - matchpathcon doesn't have the necessary data,
and it will be difficult for it to perform this operation. Expansions
should be performed by programs that know how to do that.

useradd knows the user being added, and the home directory, for example.

We could have a program that walks the fstab, and collects data
on where certain mount points are, and then perform an expansion to
configure that..

We could detect a change in some gconf key that configures a path,
and have it perform an expansion.

I suppose only the sysadm could do this for now, maybe not so 
in the future.

> Additionally, all of this is caused by using file
> contexts for runtime labeling, which I have pointed out repeatedly is a
> questionable security practice.

You've done no such thing - you've pointed out that
automated relabeling without timing control by the sysadmin
is potentially dangerous. I don't see why that means that
automated relabeling (as in..performed internally, and not by
chcon) in general is a bad thing. I'm not sure what you mean by
"runtime labeling".

> Fundamentally wrong seems a little strong - this is just a space / time tradeoff
> not a major architectural decision.

But why? 
What's the gain of doing the same work over and over again?
I mentioned that I don't want to concat files together, but 
at least that way performing the expansion happens once, when
relevant - not on every matchpathcon invocation...

> More importantly, we have just decided to remove specific user information from
> the policy and leaving it in the file contexts seems strange.

The file contexts serves a different purpose.
I agree with you in that I don't like having hundreds of files there,
but at the same time I don't see an alternative.


--
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: file contexts and modularity

[Stephen Smalley]

On Wed, 2005-06-29 at 14:46 -0400, Ivan Gyurdiev wrote:
> > More importantly, we have just decided to remove specific user information from
> > the policy and leaving it in the file contexts seems strange.
> 
> The file contexts serves a different purpose.
> I agree with you in that I don't like having hundreds of files there,
> but at the same time I don't see an alternative.

Polyinstantiate every user home directory ;)
Anyone following up on Chad Seller's work there?
Then you have dynamically created per-role home directories
transparently mounted on the user's home directory for whatever role the
user happens to be logged in as.

-- 
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: file contexts and modularity

[Karl MacMillan]

> -----Original Message-----
> From: Ivan Gyurdiev [mailto:gyurdiev@redhat.com]
> Sent: Wednesday, June 29, 2005 2:47 PM
> To: Karl MacMillan
> Cc: selinux@tycho.nsa.gov; 'Daniel J Walsh'
> Subject: RE: file contexts and modularity
> 
> > Additionally, all of this is caused by using file
> > contexts for runtime labeling, which I have pointed out repeatedly is a
> > questionable security practice.
> 
> You've done no such thing - you've pointed out that
> automated relabeling without timing control by the sysadmin
> is potentially dangerous. I don't see why that means that
> automated relabeling (as in..performed internally, and not by
> chcon) in general is a bad thing. I'm not sure what you mean by
> "runtime labeling".
> 

If there was no expectation that the user home directories would not be
relabeled (e.g., via restorecon) as a normal part of running a system then there
would be no reason to generate the file contexts. The home directory would be
labeled upon creation.

As for the general concept of runtime labeling - I mean labeling other than at
initialization time (system installation, user addition, etc.). I have often
argued against runtime labeling - maybe not in this thread but other places. It
is often unsafe and leads towards discretionary access control.

I'm not certain this is possible in the real world, but I think it is the
correct goal.

> > More importantly, we have just decided to remove specific user information
> from
> > the policy and leaving it in the file contexts seems strange.
> 
> The file contexts serves a different purpose.
> I agree with you in that I don't like having hundreds of files there,
> but at the same time I don't see an alternative.

Different purpose, but the file contexts are closely tied to the policy.

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134



--
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: file contexts and modularity

[Karl MacMillan]

> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> Sent: Wednesday, June 29, 2005 2:54 PM
> To: gyurdiev@redhat.com
> Cc: Karl MacMillan; selinux@tycho.nsa.gov; 'Daniel J Walsh'
> Subject: RE: file contexts and modularity
> 
> On Wed, 2005-06-29 at 14:46 -0400, Ivan Gyurdiev wrote:
> > > More importantly, we have just decided to remove specific user information
> from
> > > the policy and leaving it in the file contexts seems strange.
> >
> > The file contexts serves a different purpose.
> > I agree with you in that I don't like having hundreds of files there,
> > but at the same time I don't see an alternative.
> 
> Polyinstantiate every user home directory ;)
> Anyone following up on Chad Seller's work there?
> Then you have dynamically created per-role home directories
> transparently mounted on the user's home directory for whatever role the
> user happens to be logged in as.
> 

Perfect! 

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134

> --
> 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: file contexts and modularity

[Ivan Gyurdiev]

> If there was no expectation that the user home directories would not be
> relabeled (e.g., via restorecon) as a normal part of running a system then there
> would be no reason to generate the file contexts.

Context inheritance combined with automated transitions are not 
sufficient... this becomes clear as you try to label directories
with mixed-type content....but this is another discussion.

>  The home directory would be labeled upon creation.

It still has to query policy for the type to use for labeling.
Currently that's accomplished by mathpatchcon..unless you
are suggesting that we write a special interface specifically
to get the home type for a user, bypassing the matching.

> As for the general concept of runtime labeling - I mean labeling other than at
> initialization time (system installation, user addition, etc.). I have often
> argued against runtime labeling - maybe not in this thread but other places. It
> is often unsafe and leads towards discretionary access control.

Unsafe? This is all audited by the policy (relabelto relabelfrom)
I don't see what's discretionary about it.

> I'm not certain this is possible in the real world, but I think it is the
> correct 

I think selinux's dependence on fixed organization scheme and static
labeling is one of its major weaknesses. I'm not sure whether
it's good from a security standpoint, but practically, users
just like to put things wherever they like...




--
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: file contexts and modularity

[Ivan Gyurdiev]

> > > The file contexts serves a different purpose.
> > > I agree with you in that I don't like having hundreds of files there,
> > > but at the same time I don't see an alternative.
> > 
> > Polyinstantiate every user home directory ;)
> > Anyone following up on Chad Seller's work there?
> > Then you have dynamically created per-role home directories
> > transparently mounted on the user's home directory for whatever role the
> > user happens to be logged in as.
> > 
> 
> Perfect! 

Can you explain how this would work a bit?
How would matchpathcon work on a polyinstantiated directory?





--
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: file contexts and modularity

[Stephen Smalley]

On Wed, 2005-06-29 at 15:24 -0400, Ivan Gyurdiev wrote:
> Can you explain how this would work a bit?
> How would matchpathcon work on a polyinstantiated directory?

I'm not sure what you are asking.  Basic concept is that the user
actually has a separate home directory (and /tmp and whatever else) per
role, and the right one is automatically bind mounted onto their
official home directory location at login time (and adjusted as needed
upon su, newrole, etc).  The code allows for dynamic creation of those
per-role home directories on demand, e.g. when the user logs in at a
given role, but of course, that will leave them with an empty directory
at present.  We would need to deal with setup, e.g. initial copying of
skeleton files when the per-role directory is first created, which could
be handled at login time.  Chad Sellers posted example patches earlier
for login, gdm, and su.  Implementation would be greatly simplified by
unshare(2) call, which would allow handling it in libpam rather than
patching each login-like program - Janak was working on such a patch.
Current implementation creates the per-role directories as
subdirectories of the official home directory location, but others have
suggested making that location configurable.

So at that point you no longer need to keep home directory contexts in
file_contexts at all, and you just exclude home directories from
relabeling.

-- 
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: file contexts and modularity

[Ivan Gyurdiev]

> So at that point you no longer need to keep home directory contexts in
> file_contexts at all, and you just exclude home directories from
> relabeling.

How is the context of the bind-mounted home dir configured?

and subdirectories? pre-created?
what determines their context?

I am trying to understand where the labeling 
information is stored, if you want to get rid of the 
file_contexts.homedirs file.




--
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: file contexts and modularity

[Stephen Smalley]

On Wed, 2005-06-29 at 16:03 -0400, Ivan Gyurdiev wrote:
> > So at that point you no longer need to keep home directory contexts in
> > file_contexts at all, and you just exclude home directories from
> > relabeling.
> 
> How is the context of the bind-mounted home dir configured?

The mount point directory's context can just be a single fixed context
for all users, as it is just a mount point.

> and subdirectories? pre-created?

Optionally, but typically just created by login-style programs (ideally
via libpam) when the user first logs in at a given role.

> what determines their context?

Obtained via security_compute_member, which in turn relies on
type_member rules in the policy.  See Chad's earlier postings.  The
security_setupns() function is in our libselinux tree, but you'd also
need the patches he posted to login and friends for experimentation.

> I am trying to understand where the labeling 
> information is stored, if you want to get rid of the 
> file_contexts.homedirs file.

It is computed based on the user process' security context and the base
context on the mount point directory.

-- 
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: file contexts and modularity

[Janak Desai]

Yes, I am continuing the work started by Chad Sellers. I am working with
the new unshare system call and using pam session management hooks to
setup and reset namespace from session creating programs. I am
currently unit testing/debugging the stuff and am hoping to post the
pam patches here in about a week or so.

-Janak

Stephen Smalley wrote:
> On Wed, 2005-06-29 at 15:24 -0400, Ivan Gyurdiev wrote:
> 
>>Can you explain how this would work a bit?
>>How would matchpathcon work on a polyinstantiated directory?
> 
> 
> I'm not sure what you are asking.  Basic concept is that the user
> actually has a separate home directory (and /tmp and whatever else) per
> role, and the right one is automatically bind mounted onto their
> official home directory location at login time (and adjusted as needed
> upon su, newrole, etc).  The code allows for dynamic creation of those
> per-role home directories on demand, e.g. when the user logs in at a
> given role, but of course, that will leave them with an empty directory
> at present.  We would need to deal with setup, e.g. initial copying of
> skeleton files when the per-role directory is first created, which could
> be handled at login time.  Chad Sellers posted example patches earlier
> for login, gdm, and su.  Implementation would be greatly simplified by
> unshare(2) call, which would allow handling it in libpam rather than
> patching each login-like program - Janak was working on such a patch.
> Current implementation creates the per-role directories as
> subdirectories of the official home directory location, but others have
> suggested making that location configurable.
> 
> So at that point you no longer need to keep home directory contexts in
> file_contexts at all, and you just exclude home directories from
> relabeling.
> 



--
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: file contexts and modularity

[Janak Desai]

Ivan Gyurdiev wrote:

>>So at that point you no longer need to keep home directory contexts in
>>file_contexts at all, and you just exclude home directories from
>>relabeling.
> 
> 
> How is the context of the bind-mounted home dir configured?
> 
> and subdirectories? pre-created?
> what determines their context?
> 
> I am trying to understand where the labeling 
> information is stored, if you want to get rid of the 
> file_contexts.homedirs file.
> 
> 
> 

Subdirectory context is obtained from the policy
using security_compute_member() call. So the pam module will
get the security context of the member, create the
directory and bind mount it to the polyinstantiated directory.
As Stephen mentioned, the member directory is no longer a
subdirectory of polyinstantiated directory. A configuration
file is checked to determine where to create member directories
for a perticular polyinstantiated directory.

-Janak

> 
> --
> 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: file contexts and modularity

[Ivan Gyurdiev]

On Wed, 2005-06-29 at 16:09 -0400, Stephen Smalley wrote:
> On Wed, 2005-06-29 at 16:03 -0400, Ivan Gyurdiev wrote:
> > > So at that point you no longer need to keep home directory contexts in
> > > file_contexts at all, and you just exclude home directories from
> > > relabeling.
> > 
> > How is the context of the bind-mounted home dir configured?
> 
> The mount point directory's context can just be a single fixed context
> for all users, as it is just a mount point.

ok ..

> > and subdirectories? pre-created?
> 
> Optionally, but typically just created by login-style programs (ideally
> via libpam) when the user first logs in at a given role.

> > what determines their context?
> 
> Obtained via security_compute_member, which in turn relies on
> type_member rules in the policy.  See Chad's earlier postings.  The
> security_setupns() function is in our libselinux tree, but you'd also
> need the patches he posted to login and friends for experimentation.

I don't have the list archived that far back,
but from reading about this online it looks like an analog
to file_type_auto_trans, which doesn't work, because
of ambiguity. Pre-creating things is required, which
currently works via matchpathcon....

..or am I misunderstanding how this works?

> > I am trying to understand where the labeling 
> > information is stored, if you want to get rid of the 
> > file_contexts.homedirs file.
> 
> It is computed based on the user process' security context and the base
> context on the mount point directory.

That makes sense for the mount point itself, but not
for sub-content.


--
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: file contexts and modularity

[Ivan Gyurdiev]

> Subdirectory context is obtained from the policy
> using security_compute_member() call. 

int security_compute_member(security_context_t scon,
                            security_context_t tcon,
                            security_class_t tclass,
                            security_context_t *newcon)

So, it seems to me that
this is insufficient basis to determine proper newcon - 
file_type_auto_trans doesn't work for the same reason.

(scon, tcon, tclass) -> newcon 

is a 1:many map, and not 1:1.

So...how will pre-creation work if the file_contexts.homedirs
file is erased (the only many:1 map available, 
which becomes 1:1 given evaluation order).


--
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: file contexts and modularity

[Luke Kenneth Casson Leighton]

On Wed, Jun 29, 2005 at 03:50:57PM -0400, Stephen Smalley wrote:

> So at that point you no longer need to keep home directory contexts in
> file_contexts at all, and you just exclude home directories from
> relabeling.

 yessss :)


--
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: file contexts and modularity

[Ivan Gyurdiev]

On Wed, 2005-06-29 at 16:44 -0400, Ivan Gyurdiev wrote:
> > Subdirectory context is obtained from the policy
> > using security_compute_member() call. 
> 
> int security_compute_member(security_context_t scon,
>                             security_context_t tcon,
>                             security_class_t tclass,
>                             security_context_t *newcon)
> 
> So, it seems to me that
> this is insufficient basis to determine proper newcon - 
> file_type_auto_trans doesn't work for the same reason.
> 
> (scon, tcon, tclass) -> newcon 
> 
> is a 1:many map, and not 1:1.
> 
> So...how will pre-creation work if the file_contexts.homedirs
> file is erased (the only many:1 map available, 
> which becomes 1:1 given evaluation order).

To clarify, what I mean is... the file_context allows us to uniquely 
identify files, and label them appropriately. The (scon, tcon, tclass)
pair is not sufficient to uniquely identify the resultant type. 
There are many occasions where we need multiple types with the same
triple, which is why we have this hack script that Karl doesn't like
at all, which does pre-creation of subfolders. However, that 
script requires the file_contexts file to work, so I don't 
see how it can be removed, with or without polyinstantiation.

I can see the problem being fixed if you label files under /home
_and_ /tmp with a ROLE independent-type. This will also remove the
need to relabel after a change in primary role, which is currently
a major issue. However, I wasn't sure if that was being suggested? 
Is this what we're discussing here - removing role-dependent labeling,
since other roles' content will be hidden by polyinstantiation?




--
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: file contexts and modularity

[Stephen Smalley]

On Wed, 2005-06-29 at 16:22 -0400, Ivan Gyurdiev wrote:
> I don't have the list archived that far back,
> but from reading about this online it looks like an analog
> to file_type_auto_trans, which doesn't work, because
> of ambiguity. Pre-creating things is required, which
> currently works via matchpathcon....

So far, the polyinstantiated directory support has only considered
automated creation of the per-user/role/level directories, not anything
within them (except for setup code for preserving X-related sockets
in /tmp and .Xauthority in $HOME to allow it to work with gdm).  Hence,
it would need to be extended to allow more general setup, e.g. copying
in skeleton files when a per-role directory is first created and setting
up their contexts as appropriate.  Which might require some kind of
configuration, not necessarily file_contexts/matchpathcon.

> That makes sense for the mount point itself, but not
> for sub-content.

Yes, it is only dealing with the per-role directory at present.

-- 
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: file contexts and modularity

[Stephen Smalley]

On Wed, 2005-06-29 at 16:43 -0400, Ivan Gyurdiev wrote:
> So...how will pre-creation work if the file_contexts.homedirs
> file is erased (the only many:1 map available, 
> which becomes 1:1 given evaluation order).

I think you'd have a separate config file, which contains templates not
pre-expanded entries per user, and have the polyinstantiated directory
support handle initial setup and labeling when a per-role directory is
first created.  

Of course, we are getting rather ahead of ourselves here, as we don't
even have the basic polyinstantiated directory support in FC/devel
yet...

-- 
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: file contexts and modularity

[Stephen Smalley]

On Thu, 2005-06-30 at 09:53 -0400, Ivan Gyurdiev wrote:
> I can see the problem being fixed if you label files under /home
> _and_ /tmp with a ROLE independent-type. This will also remove the
> need to relabel after a change in primary role, which is currently
> a major issue. However, I wasn't sure if that was being suggested? 
> Is this what we're discussing here - removing role-dependent labeling,
> since other roles' content will be hidden by polyinstantiation?

No, the derived types are still useful IMHO for isolation, and note that
the polyinstantiated directory support doesn't try to prevent access to
the other per-role directories (even when they are subdirectories of the
top-level directory, we re-bind it elsewhere to allow security-aware
applications to access it if allowed by policy and to allow programs
like su and newrole to re-bind upon role changes).  On the other hand, I
know Karl previously suggested eliminating them, but I think that would
be a real loss...

-- 
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: file contexts and modularity

[Karl MacMillan]

> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> Sent: Thursday, June 30, 2005 9:59 AM
> To: gyurdiev@redhat.com
> Cc: Janak Desai; Karl MacMillan; selinux@tycho.nsa.gov; 'Daniel J Walsh'
> Subject: Re: file contexts and modularity
> 
> On Thu, 2005-06-30 at 09:53 -0400, Ivan Gyurdiev wrote:
> > I can see the problem being fixed if you label files under /home
> > _and_ /tmp with a ROLE independent-type. This will also remove the
> > need to relabel after a change in primary role, which is currently
> > a major issue. However, I wasn't sure if that was being suggested?
> > Is this what we're discussing here - removing role-dependent labeling,
> > since other roles' content will be hidden by polyinstantiation?
> 
> No, the derived types are still useful IMHO for isolation, and note that
> the polyinstantiated directory support doesn't try to prevent access to
> the other per-role directories (even when they are subdirectories of the
> top-level directory, we re-bind it elsewhere to allow security-aware
> applications to access it if allowed by policy and to allow programs
> like su and newrole to re-bind upon role changes).  On the other hand, I
> know Karl previously suggested eliminating them, but I think that would
> be a real loss...
> 

I don't remember suggesting their removal - must have been poor wording on my
part since you both misunderstood.

Karl

---
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410) 290-1411 ext 134

> --
> 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: file contexts and modularity

[Stephen Smalley]

On Thu, 2005-06-30 at 10:48 -0400, Karl MacMillan wrote:
> I don't remember suggesting their removal - must have been poor wording on my
> part since you both misunderstood.

Actually, on second thought, I think that you were actually questioning
the derived program domains rather than derived file types, e.g.
user_ssh_t vs. staff_ssh_t.

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