* file contexts and modularity @ 2005-06-23 3:00 Ivan Gyurdiev 2005-06-23 17:37 ` Karl MacMillan 0 siblings, 1 reply; 59+ messages in thread From: Ivan Gyurdiev @ 2005-06-23 3:00 UTC (permalink / raw) To: selinux; +Cc: Daniel J Walsh 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-23 3:00 file contexts and modularity Ivan Gyurdiev @ 2005-06-23 17:37 ` Karl MacMillan 2005-06-23 18:05 ` Ivan Gyurdiev 0 siblings, 1 reply; 59+ messages in thread From: Karl MacMillan @ 2005-06-23 17:37 UTC (permalink / raw) To: ivg2, selinux; +Cc: 'Daniel J Walsh' > -----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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-23 17:37 ` Karl MacMillan @ 2005-06-23 18:05 ` Ivan Gyurdiev 2005-06-23 18:21 ` Karl MacMillan 0 siblings, 1 reply; 59+ messages in thread From: Ivan Gyurdiev @ 2005-06-23 18:05 UTC (permalink / raw) To: Karl MacMillan; +Cc: selinux, 'Daniel J Walsh' > 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-23 18:05 ` Ivan Gyurdiev @ 2005-06-23 18:21 ` Karl MacMillan 2005-06-23 18:25 ` Ivan Gyurdiev 0 siblings, 1 reply; 59+ messages in thread From: Karl MacMillan @ 2005-06-23 18:21 UTC (permalink / raw) To: ivg2; +Cc: selinux, 'Daniel J Walsh' > -----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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-23 18:21 ` Karl MacMillan @ 2005-06-23 18:25 ` Ivan Gyurdiev 2005-06-23 18:40 ` Karl MacMillan 0 siblings, 1 reply; 59+ messages in thread From: Ivan Gyurdiev @ 2005-06-23 18:25 UTC (permalink / raw) To: Karl MacMillan; +Cc: selinux, 'Daniel J Walsh' > 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-23 18:25 ` Ivan Gyurdiev @ 2005-06-23 18:40 ` Karl MacMillan 2005-06-23 19:00 ` Ivan Gyurdiev 2005-06-24 5:03 ` Ivan Gyurdiev 0 siblings, 2 replies; 59+ messages in thread From: Karl MacMillan @ 2005-06-23 18:40 UTC (permalink / raw) To: ivg2; +Cc: selinux, 'Daniel J Walsh' > -----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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-23 18:40 ` Karl MacMillan @ 2005-06-23 19:00 ` Ivan Gyurdiev 2005-06-23 19:39 ` Karl MacMillan 2005-06-24 5:03 ` Ivan Gyurdiev 1 sibling, 1 reply; 59+ messages in thread From: Ivan Gyurdiev @ 2005-06-23 19:00 UTC (permalink / raw) To: Karl MacMillan; +Cc: selinux, 'Daniel J Walsh' > 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-23 19:00 ` Ivan Gyurdiev @ 2005-06-23 19:39 ` Karl MacMillan 2005-06-23 20:28 ` Ivan Gyurdiev 0 siblings, 1 reply; 59+ messages in thread From: Karl MacMillan @ 2005-06-23 19:39 UTC (permalink / raw) To: ivg2; +Cc: selinux, 'Daniel J Walsh' > -----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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-23 19:39 ` Karl MacMillan @ 2005-06-23 20:28 ` Ivan Gyurdiev 2005-06-23 20:36 ` Ivan Gyurdiev ` (3 more replies) 0 siblings, 4 replies; 59+ messages in thread From: Ivan Gyurdiev @ 2005-06-23 20:28 UTC (permalink / raw) To: Karl MacMillan; +Cc: selinux, 'Daniel J Walsh' [-- 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_ */ ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-23 20:28 ` Ivan Gyurdiev @ 2005-06-23 20:36 ` Ivan Gyurdiev 2005-06-24 12:08 ` Stephen Smalley ` (2 subsequent siblings) 3 siblings, 0 replies; 59+ messages in thread From: Ivan Gyurdiev @ 2005-06-23 20:36 UTC (permalink / raw) To: Karl MacMillan; +Cc: selinux, 'Daniel J Walsh' [-- 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-23 20:28 ` Ivan Gyurdiev 2005-06-23 20:36 ` Ivan Gyurdiev @ 2005-06-24 12:08 ` Stephen Smalley 2005-06-24 15:43 ` Ivan Gyurdiev 2005-06-24 12:21 ` Stephen Smalley 2005-06-24 15:39 ` Karl MacMillan 3 siblings, 1 reply; 59+ messages in thread From: Stephen Smalley @ 2005-06-24 12:08 UTC (permalink / raw) To: ivg2; +Cc: Karl MacMillan, selinux, 'Daniel J Walsh' 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-24 12:08 ` Stephen Smalley @ 2005-06-24 15:43 ` Ivan Gyurdiev 2005-06-24 18:32 ` Stephen Smalley 0 siblings, 1 reply; 59+ messages in thread From: Ivan Gyurdiev @ 2005-06-24 15:43 UTC (permalink / raw) To: Stephen Smalley; +Cc: Karl MacMillan, selinux, 'Daniel J Walsh' 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-24 15:43 ` Ivan Gyurdiev @ 2005-06-24 18:32 ` Stephen Smalley 2005-06-24 18:37 ` Ivan Gyurdiev 0 siblings, 1 reply; 59+ messages in thread From: Stephen Smalley @ 2005-06-24 18:32 UTC (permalink / raw) To: ivg2; +Cc: Karl MacMillan, selinux, 'Daniel J Walsh' 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-24 18:32 ` Stephen Smalley @ 2005-06-24 18:37 ` Ivan Gyurdiev 0 siblings, 0 replies; 59+ messages in thread From: Ivan Gyurdiev @ 2005-06-24 18:37 UTC (permalink / raw) To: Stephen Smalley; +Cc: Karl MacMillan, selinux, 'Daniel J Walsh' 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-23 20:28 ` Ivan Gyurdiev 2005-06-23 20:36 ` Ivan Gyurdiev 2005-06-24 12:08 ` Stephen Smalley @ 2005-06-24 12:21 ` Stephen Smalley 2005-06-24 14:30 ` Karl MacMillan 2005-06-24 15:51 ` Casey Schaufler 2005-06-24 15:39 ` Karl MacMillan 3 siblings, 2 replies; 59+ messages in thread From: Stephen Smalley @ 2005-06-24 12:21 UTC (permalink / raw) To: ivg2; +Cc: James Morris, Karl MacMillan, selinux, 'Daniel J Walsh' 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-24 12:21 ` Stephen Smalley @ 2005-06-24 14:30 ` Karl MacMillan 2005-06-24 16:05 ` Karl MacMillan 2005-06-24 15:51 ` Casey Schaufler 1 sibling, 1 reply; 59+ messages in thread From: Karl MacMillan @ 2005-06-24 14:30 UTC (permalink / raw) To: 'Stephen Smalley', ivg2 Cc: 'James Morris', selinux, 'Daniel J Walsh' > -----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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-24 14:30 ` Karl MacMillan @ 2005-06-24 16:05 ` Karl MacMillan 2005-06-24 18:05 ` Frank Mayer 0 siblings, 1 reply; 59+ messages in thread From: Karl MacMillan @ 2005-06-24 16:05 UTC (permalink / raw) To: 'Karl MacMillan', 'Stephen Smalley', ivg2 Cc: 'James Morris', selinux, 'Daniel J Walsh' > -----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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-24 16:05 ` Karl MacMillan @ 2005-06-24 18:05 ` Frank Mayer 2005-06-24 18:40 ` Stephen Smalley 0 siblings, 1 reply; 59+ messages in thread From: Frank Mayer @ 2005-06-24 18:05 UTC (permalink / raw) To: 'Karl MacMillan', 'Stephen Smalley', ivg2 Cc: 'James Morris', selinux, 'Daniel J Walsh' 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-24 18:05 ` Frank Mayer @ 2005-06-24 18:40 ` Stephen Smalley 2005-06-28 15:41 ` Karl MacMillan 0 siblings, 1 reply; 59+ messages in thread From: Stephen Smalley @ 2005-06-24 18:40 UTC (permalink / raw) To: Frank Mayer Cc: 'Karl MacMillan', ivg2, 'James Morris', selinux, 'Daniel J Walsh' 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-24 18:40 ` Stephen Smalley @ 2005-06-28 15:41 ` Karl MacMillan 2005-06-28 16:21 ` Stephen Smalley 0 siblings, 1 reply; 59+ messages in thread From: Karl MacMillan @ 2005-06-28 15:41 UTC (permalink / raw) To: 'Stephen Smalley', 'Frank Mayer' Cc: ivg2, 'James Morris', selinux, 'Daniel J Walsh' > -----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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-28 15:41 ` Karl MacMillan @ 2005-06-28 16:21 ` Stephen Smalley 0 siblings, 0 replies; 59+ messages in thread From: Stephen Smalley @ 2005-06-28 16:21 UTC (permalink / raw) To: Karl MacMillan Cc: 'Frank Mayer', ivg2, 'James Morris', selinux, 'Daniel J Walsh' 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-24 12:21 ` Stephen Smalley 2005-06-24 14:30 ` Karl MacMillan @ 2005-06-24 15:51 ` Casey Schaufler 2005-06-24 16:36 ` Karl MacMillan 1 sibling, 1 reply; 59+ messages in thread From: Casey Schaufler @ 2005-06-24 15:51 UTC (permalink / raw) To: selinux --- 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-24 15:51 ` Casey Schaufler @ 2005-06-24 16:36 ` Karl MacMillan 2005-06-24 16:47 ` Casey Schaufler 0 siblings, 1 reply; 59+ messages in thread From: Karl MacMillan @ 2005-06-24 16:36 UTC (permalink / raw) To: 'Casey Schaufler', selinux > -----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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-24 16:36 ` Karl MacMillan @ 2005-06-24 16:47 ` Casey Schaufler 2005-06-24 16:56 ` Karl MacMillan 0 siblings, 1 reply; 59+ messages in thread From: Casey Schaufler @ 2005-06-24 16:47 UTC (permalink / raw) To: Karl MacMillan, selinux --- 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-24 16:47 ` Casey Schaufler @ 2005-06-24 16:56 ` Karl MacMillan 2005-06-24 17:10 ` Casey Schaufler 0 siblings, 1 reply; 59+ messages in thread From: Karl MacMillan @ 2005-06-24 16:56 UTC (permalink / raw) To: 'Casey Schaufler', selinux > -----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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-24 16:56 ` Karl MacMillan @ 2005-06-24 17:10 ` Casey Schaufler 0 siblings, 0 replies; 59+ messages in thread From: Casey Schaufler @ 2005-06-24 17:10 UTC (permalink / raw) To: Karl MacMillan, selinux --- 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-23 20:28 ` Ivan Gyurdiev ` (2 preceding siblings ...) 2005-06-24 12:21 ` Stephen Smalley @ 2005-06-24 15:39 ` Karl MacMillan 2005-06-24 16:03 ` Ivan Gyurdiev 3 siblings, 1 reply; 59+ messages in thread From: Karl MacMillan @ 2005-06-24 15:39 UTC (permalink / raw) To: ivg2; +Cc: selinux, 'Daniel J Walsh' > -----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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-24 15:39 ` Karl MacMillan @ 2005-06-24 16:03 ` Ivan Gyurdiev 2005-06-24 16:28 ` Karl MacMillan 0 siblings, 1 reply; 59+ messages in thread From: Ivan Gyurdiev @ 2005-06-24 16:03 UTC (permalink / raw) To: Karl MacMillan; +Cc: selinux, 'Daniel J Walsh' > 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-24 16:03 ` Ivan Gyurdiev @ 2005-06-24 16:28 ` Karl MacMillan 2005-06-24 17:56 ` Ivan Gyurdiev 0 siblings, 1 reply; 59+ messages in thread From: Karl MacMillan @ 2005-06-24 16:28 UTC (permalink / raw) To: ivg2; +Cc: selinux, 'Daniel J Walsh' > -----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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-24 16:28 ` Karl MacMillan @ 2005-06-24 17:56 ` Ivan Gyurdiev 2005-06-27 15:07 ` Karl MacMillan 0 siblings, 1 reply; 59+ messages in thread From: Ivan Gyurdiev @ 2005-06-24 17:56 UTC (permalink / raw) To: Karl MacMillan; +Cc: selinux, 'Daniel J Walsh' > > 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-24 17:56 ` Ivan Gyurdiev @ 2005-06-27 15:07 ` Karl MacMillan 2005-06-27 15:36 ` Ivan Gyurdiev 0 siblings, 1 reply; 59+ messages in thread From: Karl MacMillan @ 2005-06-27 15:07 UTC (permalink / raw) To: ivg2; +Cc: selinux, 'Daniel J Walsh' > -----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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-27 15:07 ` Karl MacMillan @ 2005-06-27 15:36 ` Ivan Gyurdiev 2005-06-27 17:25 ` Karl MacMillan 0 siblings, 1 reply; 59+ messages in thread From: Ivan Gyurdiev @ 2005-06-27 15:36 UTC (permalink / raw) To: Karl MacMillan; +Cc: selinux, 'Daniel J Walsh' > 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-27 15:36 ` Ivan Gyurdiev @ 2005-06-27 17:25 ` Karl MacMillan 2005-06-27 17:56 ` Ivan Gyurdiev 0 siblings, 1 reply; 59+ messages in thread From: Karl MacMillan @ 2005-06-27 17:25 UTC (permalink / raw) To: ivg2; +Cc: selinux, 'Daniel J Walsh' > -----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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-27 17:25 ` Karl MacMillan @ 2005-06-27 17:56 ` Ivan Gyurdiev 2005-06-28 13:47 ` Karl MacMillan 0 siblings, 1 reply; 59+ messages in thread From: Ivan Gyurdiev @ 2005-06-27 17:56 UTC (permalink / raw) To: Karl MacMillan; +Cc: selinux, 'Daniel J Walsh' > 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-27 17:56 ` Ivan Gyurdiev @ 2005-06-28 13:47 ` Karl MacMillan 2005-06-28 19:31 ` Ivan Gyurdiev 0 siblings, 1 reply; 59+ messages in thread From: Karl MacMillan @ 2005-06-28 13:47 UTC (permalink / raw) To: ivg2; +Cc: selinux, 'Daniel J Walsh' > -----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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-28 13:47 ` Karl MacMillan @ 2005-06-28 19:31 ` Ivan Gyurdiev 2005-06-29 17:28 ` Ivan Gyurdiev 0 siblings, 1 reply; 59+ messages in thread From: Ivan Gyurdiev @ 2005-06-28 19:31 UTC (permalink / raw) To: Karl MacMillan; +Cc: selinux, 'Daniel J Walsh' > > 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-28 19:31 ` Ivan Gyurdiev @ 2005-06-29 17:28 ` Ivan Gyurdiev 2005-06-29 18:17 ` Karl MacMillan 0 siblings, 1 reply; 59+ messages in thread From: Ivan Gyurdiev @ 2005-06-29 17:28 UTC (permalink / raw) To: Karl MacMillan; +Cc: selinux, 'Daniel J Walsh' 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-29 17:28 ` Ivan Gyurdiev @ 2005-06-29 18:17 ` Karl MacMillan 2005-06-29 18:46 ` Ivan Gyurdiev 0 siblings, 1 reply; 59+ messages in thread From: Karl MacMillan @ 2005-06-29 18:17 UTC (permalink / raw) To: gyurdiev; +Cc: selinux, 'Daniel J Walsh' > -----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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-29 18:17 ` Karl MacMillan @ 2005-06-29 18:46 ` Ivan Gyurdiev 2005-06-29 18:53 ` Stephen Smalley 2005-06-29 19:04 ` Karl MacMillan 0 siblings, 2 replies; 59+ messages in thread From: Ivan Gyurdiev @ 2005-06-29 18:46 UTC (permalink / raw) To: Karl MacMillan; +Cc: selinux, 'Daniel J Walsh' > 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-29 18:46 ` Ivan Gyurdiev @ 2005-06-29 18:53 ` Stephen Smalley 2005-06-29 19:04 ` Karl MacMillan 2005-06-29 19:04 ` Karl MacMillan 1 sibling, 1 reply; 59+ messages in thread From: Stephen Smalley @ 2005-06-29 18:53 UTC (permalink / raw) To: gyurdiev; +Cc: Karl MacMillan, selinux, 'Daniel J Walsh' 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-29 18:53 ` Stephen Smalley @ 2005-06-29 19:04 ` Karl MacMillan 2005-06-29 19:24 ` Ivan Gyurdiev 0 siblings, 1 reply; 59+ messages in thread From: Karl MacMillan @ 2005-06-29 19:04 UTC (permalink / raw) To: 'Stephen Smalley', gyurdiev; +Cc: selinux, 'Daniel J Walsh' > -----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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-29 19:04 ` Karl MacMillan @ 2005-06-29 19:24 ` Ivan Gyurdiev 2005-06-29 19:50 ` Stephen Smalley 0 siblings, 1 reply; 59+ messages in thread From: Ivan Gyurdiev @ 2005-06-29 19:24 UTC (permalink / raw) To: Karl MacMillan Cc: 'Stephen Smalley', selinux, 'Daniel J Walsh' > > > 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-29 19:24 ` Ivan Gyurdiev @ 2005-06-29 19:50 ` Stephen Smalley 2005-06-29 20:03 ` Ivan Gyurdiev ` (2 more replies) 0 siblings, 3 replies; 59+ messages in thread From: Stephen Smalley @ 2005-06-29 19:50 UTC (permalink / raw) To: gyurdiev; +Cc: Janak Desai, Karl MacMillan, selinux, 'Daniel J Walsh' 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-29 19:50 ` Stephen Smalley @ 2005-06-29 20:03 ` Ivan Gyurdiev 2005-06-29 20:09 ` Stephen Smalley 2005-06-29 20:22 ` Janak Desai 2005-06-29 20:13 ` Janak Desai 2005-06-30 0:40 ` Luke Kenneth Casson Leighton 2 siblings, 2 replies; 59+ messages in thread From: Ivan Gyurdiev @ 2005-06-29 20:03 UTC (permalink / raw) To: Stephen Smalley Cc: Janak Desai, Karl MacMillan, selinux, 'Daniel J Walsh' > 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-29 20:03 ` Ivan Gyurdiev @ 2005-06-29 20:09 ` Stephen Smalley 2005-06-29 20:22 ` Ivan Gyurdiev 2005-06-29 20:22 ` Janak Desai 1 sibling, 1 reply; 59+ messages in thread From: Stephen Smalley @ 2005-06-29 20:09 UTC (permalink / raw) To: gyurdiev; +Cc: Janak Desai, Karl MacMillan, selinux, 'Daniel J Walsh' 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-29 20:09 ` Stephen Smalley @ 2005-06-29 20:22 ` Ivan Gyurdiev 2005-06-30 13:54 ` Stephen Smalley 0 siblings, 1 reply; 59+ messages in thread From: Ivan Gyurdiev @ 2005-06-29 20:22 UTC (permalink / raw) To: Stephen Smalley Cc: Janak Desai, Karl MacMillan, selinux, 'Daniel J Walsh' 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-29 20:22 ` Ivan Gyurdiev @ 2005-06-30 13:54 ` Stephen Smalley 0 siblings, 0 replies; 59+ messages in thread From: Stephen Smalley @ 2005-06-30 13:54 UTC (permalink / raw) To: gyurdiev; +Cc: Janak Desai, Karl MacMillan, selinux, 'Daniel J Walsh' 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: file contexts and modularity 2005-06-29 20:03 ` Ivan Gyurdiev 2005-06-29 20:09 ` Stephen Smalley @ 2005-06-29 20:22 ` Janak Desai 2005-06-29 20:43 ` Ivan Gyurdiev 1 sibling, 1 reply; 59+ messages in thread From: Janak Desai @ 2005-06-29 20:22 UTC (permalink / raw) To: gyurdiev Cc: Stephen Smalley, janak, Karl MacMillan, selinux, 'Daniel J Walsh' 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: file contexts and modularity 2005-06-29 20:22 ` Janak Desai @ 2005-06-29 20:43 ` Ivan Gyurdiev 2005-06-30 13:53 ` Ivan Gyurdiev 2005-06-30 13:56 ` Stephen Smalley 0 siblings, 2 replies; 59+ messages in thread From: Ivan Gyurdiev @ 2005-06-29 20:43 UTC (permalink / raw) To: Janak Desai Cc: Stephen Smalley, Karl MacMillan, selinux, 'Daniel J Walsh' > 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: file contexts and modularity 2005-06-29 20:43 ` Ivan Gyurdiev @ 2005-06-30 13:53 ` Ivan Gyurdiev 2005-06-30 13:58 ` Stephen Smalley 2005-06-30 13:56 ` Stephen Smalley 1 sibling, 1 reply; 59+ messages in thread From: Ivan Gyurdiev @ 2005-06-30 13:53 UTC (permalink / raw) To: Janak Desai Cc: Stephen Smalley, Karl MacMillan, selinux, 'Daniel J Walsh' 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: file contexts and modularity 2005-06-30 13:53 ` Ivan Gyurdiev @ 2005-06-30 13:58 ` Stephen Smalley 2005-06-30 14:48 ` Karl MacMillan 0 siblings, 1 reply; 59+ messages in thread From: Stephen Smalley @ 2005-06-30 13:58 UTC (permalink / raw) To: gyurdiev; +Cc: Janak Desai, Karl MacMillan, selinux, 'Daniel J Walsh' 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-30 13:58 ` Stephen Smalley @ 2005-06-30 14:48 ` Karl MacMillan 2005-06-30 14:52 ` Stephen Smalley 0 siblings, 1 reply; 59+ messages in thread From: Karl MacMillan @ 2005-06-30 14:48 UTC (permalink / raw) To: 'Stephen Smalley', gyurdiev Cc: 'Janak Desai', selinux, 'Daniel J Walsh' > -----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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-30 14:48 ` Karl MacMillan @ 2005-06-30 14:52 ` Stephen Smalley 0 siblings, 0 replies; 59+ messages in thread From: Stephen Smalley @ 2005-06-30 14:52 UTC (permalink / raw) To: Karl MacMillan Cc: gyurdiev, 'Janak Desai', selinux, 'Daniel J Walsh' 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: file contexts and modularity 2005-06-29 20:43 ` Ivan Gyurdiev 2005-06-30 13:53 ` Ivan Gyurdiev @ 2005-06-30 13:56 ` Stephen Smalley 1 sibling, 0 replies; 59+ messages in thread From: Stephen Smalley @ 2005-06-30 13:56 UTC (permalink / raw) To: gyurdiev; +Cc: Janak Desai, Karl MacMillan, selinux, 'Daniel J Walsh' 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: file contexts and modularity 2005-06-29 19:50 ` Stephen Smalley 2005-06-29 20:03 ` Ivan Gyurdiev @ 2005-06-29 20:13 ` Janak Desai 2005-06-30 0:40 ` Luke Kenneth Casson Leighton 2 siblings, 0 replies; 59+ messages in thread From: Janak Desai @ 2005-06-29 20:13 UTC (permalink / raw) To: Stephen Smalley Cc: gyurdiev, janak, Karl MacMillan, selinux, 'Daniel J Walsh' 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: file contexts and modularity 2005-06-29 19:50 ` Stephen Smalley 2005-06-29 20:03 ` Ivan Gyurdiev 2005-06-29 20:13 ` Janak Desai @ 2005-06-30 0:40 ` Luke Kenneth Casson Leighton 2 siblings, 0 replies; 59+ messages in thread From: Luke Kenneth Casson Leighton @ 2005-06-30 0:40 UTC (permalink / raw) To: Stephen Smalley Cc: gyurdiev, Janak Desai, Karl MacMillan, selinux, 'Daniel J Walsh' 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-29 18:46 ` Ivan Gyurdiev 2005-06-29 18:53 ` Stephen Smalley @ 2005-06-29 19:04 ` Karl MacMillan 2005-06-29 19:20 ` Ivan Gyurdiev 1 sibling, 1 reply; 59+ messages in thread From: Karl MacMillan @ 2005-06-29 19:04 UTC (permalink / raw) To: gyurdiev; +Cc: selinux, 'Daniel J Walsh' > -----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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-29 19:04 ` Karl MacMillan @ 2005-06-29 19:20 ` Ivan Gyurdiev 0 siblings, 0 replies; 59+ messages in thread From: Ivan Gyurdiev @ 2005-06-29 19:20 UTC (permalink / raw) To: Karl MacMillan; +Cc: selinux, 'Daniel J Walsh' > 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* RE: file contexts and modularity 2005-06-23 18:40 ` Karl MacMillan 2005-06-23 19:00 ` Ivan Gyurdiev @ 2005-06-24 5:03 ` Ivan Gyurdiev 1 sibling, 0 replies; 59+ messages in thread From: Ivan Gyurdiev @ 2005-06-24 5:03 UTC (permalink / raw) To: Karl MacMillan; +Cc: selinux, 'Daniel J Walsh' [-- 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
end of thread, other threads:[~2005-06-30 14:52 UTC | newest] Thread overview: 59+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-06-23 3:00 file contexts and modularity Ivan Gyurdiev 2005-06-23 17:37 ` Karl MacMillan 2005-06-23 18:05 ` Ivan Gyurdiev 2005-06-23 18:21 ` Karl MacMillan 2005-06-23 18:25 ` Ivan Gyurdiev 2005-06-23 18:40 ` Karl MacMillan 2005-06-23 19:00 ` Ivan Gyurdiev 2005-06-23 19:39 ` Karl MacMillan 2005-06-23 20:28 ` Ivan Gyurdiev 2005-06-23 20:36 ` Ivan Gyurdiev 2005-06-24 12:08 ` Stephen Smalley 2005-06-24 15:43 ` Ivan Gyurdiev 2005-06-24 18:32 ` Stephen Smalley 2005-06-24 18:37 ` Ivan Gyurdiev 2005-06-24 12:21 ` Stephen Smalley 2005-06-24 14:30 ` Karl MacMillan 2005-06-24 16:05 ` Karl MacMillan 2005-06-24 18:05 ` Frank Mayer 2005-06-24 18:40 ` Stephen Smalley 2005-06-28 15:41 ` Karl MacMillan 2005-06-28 16:21 ` Stephen Smalley 2005-06-24 15:51 ` Casey Schaufler 2005-06-24 16:36 ` Karl MacMillan 2005-06-24 16:47 ` Casey Schaufler 2005-06-24 16:56 ` Karl MacMillan 2005-06-24 17:10 ` Casey Schaufler 2005-06-24 15:39 ` Karl MacMillan 2005-06-24 16:03 ` Ivan Gyurdiev 2005-06-24 16:28 ` Karl MacMillan 2005-06-24 17:56 ` Ivan Gyurdiev 2005-06-27 15:07 ` Karl MacMillan 2005-06-27 15:36 ` Ivan Gyurdiev 2005-06-27 17:25 ` Karl MacMillan 2005-06-27 17:56 ` Ivan Gyurdiev 2005-06-28 13:47 ` Karl MacMillan 2005-06-28 19:31 ` Ivan Gyurdiev 2005-06-29 17:28 ` Ivan Gyurdiev 2005-06-29 18:17 ` Karl MacMillan 2005-06-29 18:46 ` Ivan Gyurdiev 2005-06-29 18:53 ` Stephen Smalley 2005-06-29 19:04 ` Karl MacMillan 2005-06-29 19:24 ` Ivan Gyurdiev 2005-06-29 19:50 ` Stephen Smalley 2005-06-29 20:03 ` Ivan Gyurdiev 2005-06-29 20:09 ` Stephen Smalley 2005-06-29 20:22 ` Ivan Gyurdiev 2005-06-30 13:54 ` Stephen Smalley 2005-06-29 20:22 ` Janak Desai 2005-06-29 20:43 ` Ivan Gyurdiev 2005-06-30 13:53 ` Ivan Gyurdiev 2005-06-30 13:58 ` Stephen Smalley 2005-06-30 14:48 ` Karl MacMillan 2005-06-30 14:52 ` Stephen Smalley 2005-06-30 13:56 ` Stephen Smalley 2005-06-29 20:13 ` Janak Desai 2005-06-30 0:40 ` Luke Kenneth Casson Leighton 2005-06-29 19:04 ` Karl MacMillan 2005-06-29 19:20 ` Ivan Gyurdiev 2005-06-24 5:03 ` Ivan Gyurdiev
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.