* [PATCH 1/1] Files and dirs objects could retain user role.
2011-03-11 7:20 [v2] [SELinux] Discussions about rbacsep Harry Ciao
@ 2011-03-11 7:20 ` Harry Ciao
2011-03-14 12:23 ` Christopher J. PeBenito
2011-03-11 7:20 ` [v2 PATCH 1/2] Auto-generate security_is_filedir_class() Harry Ciao
` (2 subsequent siblings)
3 siblings, 1 reply; 8+ messages in thread
From: Harry Ciao @ 2011-03-11 7:20 UTC (permalink / raw)
To: sds, cpebenito; +Cc: selinux
Provide an interface to have the newly created files or dirs objects
have a chance to retain its creator's role.
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
---
policy/modules/kernel/files.if | 32 ++++++++++++++++++++++++++++++++
policy/modules/system/userdomain.if | 4 ++++
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/policy/modules/kernel/files.if b/policy/modules/kernel/files.if
index ed203b2..dbec8d3 100644
--- a/policy/modules/kernel/files.if
+++ b/policy/modules/kernel/files.if
@@ -5844,3 +5844,35 @@ interface(`files_unconfined',`
typeattribute $1 files_unconfined_type;
')
+
+#######################################
+## <summary>
+## Allow files and dirs with specified type
+## retain its creator role.
+## </summary>
+## <desc>
+## <p>
+## Allow files and dirs with specified type
+## retain its creator role.
+## </p>
+## </desc>
+## <param name="role">
+## <summary>
+## The creator role
+## </summary>
+## </param>
+## <param name="domain">
+## <summary>
+## The new object type
+## </summary>
+## </param>
+## <rolebase/>
+#
+interface(`files_retain_creator_role',`
+ gen_require(`
+ attribute file_type;
+ ')
+
+ role_transition $1 $2 $1;
+ role $1 types $2;
+')
diff --git a/policy/modules/system/userdomain.if b/policy/modules/system/userdomain.if
index 28b88de..dddc9e3 100644
--- a/policy/modules/system/userdomain.if
+++ b/policy/modules/system/userdomain.if
@@ -245,6 +245,10 @@ interface(`userdom_manage_home_role',`
# cjp: this should probably be removed:
allow $2 user_home_dir_t:dir { manage_dir_perms relabel_dir_perms };
+ # new files or dirs object created in user HOME directory
+ # retain the creator role.
+ files_retain_creator_role($1, user_home_t)
+
tunable_policy(`use_nfs_home_dirs',`
fs_manage_nfs_dirs($2)
fs_manage_nfs_files($2)
--
1.7.0.4
--
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 related [flat|nested] 8+ messages in thread* Re: [PATCH 1/1] Files and dirs objects could retain user role.
2011-03-11 7:20 ` [PATCH 1/1] Files and dirs objects could retain user role Harry Ciao
@ 2011-03-14 12:23 ` Christopher J. PeBenito
0 siblings, 0 replies; 8+ messages in thread
From: Christopher J. PeBenito @ 2011-03-14 12:23 UTC (permalink / raw)
To: Harry Ciao; +Cc: sds, selinux
On 3/11/2011 2:20 AM, Harry Ciao wrote:
> Provide an interface to have the newly created files or dirs objects
> have a chance to retain its creator's role.
>
> Signed-off-by: Harry Ciao<qingtao.cao@windriver.com>
> ---
> policy/modules/kernel/files.if | 32 ++++++++++++++++++++++++++++++++
> policy/modules/system/userdomain.if | 4 ++++
> 2 files changed, 36 insertions(+), 0 deletions(-)
>
> diff --git a/policy/modules/kernel/files.if b/policy/modules/kernel/files.if
> index ed203b2..dbec8d3 100644
> --- a/policy/modules/kernel/files.if
> +++ b/policy/modules/kernel/files.if
> @@ -5844,3 +5844,35 @@ interface(`files_unconfined',`
>
> typeattribute $1 files_unconfined_type;
> ')
> +
> +#######################################
> +##<summary>
> +## Allow files and dirs with specified type
> +## retain its creator role.
> +##</summary>
> +##<desc>
> +## <p>
> +## Allow files and dirs with specified type
> +## retain its creator role.
> +## </p>
> +##</desc>
> +##<param name="role">
> +## <summary>
> +## The creator role
> +## </summary>
> +##</param>
> +##<param name="domain">
> +## <summary>
> +## The new object type
> +## </summary>
> +##</param>
> +##<rolebase/>
> +#
> +interface(`files_retain_creator_role',`
> + gen_require(`
> + attribute file_type;
> + ')
> +
> + role_transition $1 $2 $1;
> + role $1 types $2;
> +')
I see no reason for this to be an interface.
> diff --git a/policy/modules/system/userdomain.if b/policy/modules/system/userdomain.if
> index 28b88de..dddc9e3 100644
> --- a/policy/modules/system/userdomain.if
> +++ b/policy/modules/system/userdomain.if
> @@ -245,6 +245,10 @@ interface(`userdom_manage_home_role',`
> # cjp: this should probably be removed:
> allow $2 user_home_dir_t:dir { manage_dir_perms relabel_dir_perms };
>
> + # new files or dirs object created in user HOME directory
> + # retain the creator role.
> + files_retain_creator_role($1, user_home_t)
> +
> tunable_policy(`use_nfs_home_dirs',`
> fs_manage_nfs_dirs($2)
> fs_manage_nfs_files($2)
--
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.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] 8+ messages in thread
* [v2 PATCH 1/2] Auto-generate security_is_filedir_class().
2011-03-11 7:20 [v2] [SELinux] Discussions about rbacsep Harry Ciao
2011-03-11 7:20 ` [PATCH 1/1] Files and dirs objects could retain user role Harry Ciao
@ 2011-03-11 7:20 ` Harry Ciao
2011-03-11 7:21 ` [v2 PATCH 2/2] role_transition for newly created files or dirs Harry Ciao
2011-03-11 14:11 ` [v2] [SELinux] Discussions about rbacsep Stephen Smalley
3 siblings, 0 replies; 8+ messages in thread
From: Harry Ciao @ 2011-03-11 7:20 UTC (permalink / raw)
To: sds, cpebenito; +Cc: selinux
The security_is_filedir_class() is auto-generated by genheaders based
on classmap.h to reduce maintenance effort when a new class is defined
in SELinux kernel. The name for any file class should be suffixed by
"file" and doesn't contain more than one substr of "file".
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
---
| 20 ++++++++++++++++++++
security/selinux/include/classmap.h | 3 +++
2 files changed, 23 insertions(+), 0 deletions(-)
--git a/scripts/selinux/genheaders/genheaders.c b/scripts/selinux/genheaders/genheaders.c
index 539855f..ba7a90a 100644
--- a/scripts/selinux/genheaders/genheaders.c
+++ b/scripts/selinux/genheaders/genheaders.c
@@ -108,6 +108,26 @@ int main(int argc, char *argv[])
fprintf(fout, "\treturn sock;\n");
fprintf(fout, "}\n");
+ needle = "FILE";
+ fprintf(fout, "\nstatic inline bool security_is_filedir_class(u16 kern_tclass)\n");
+ fprintf(fout, "{\n");
+ fprintf(fout, "\tbool filedir = false;\n\n");
+ fprintf(fout, "\tswitch (kern_tclass) {\n");
+ for (i = 0; secclass_map[i].name; i++) {
+ struct security_class_mapping *map = &secclass_map[i];
+ substr = strstr(map->name, needle);
+ if (substr && strcmp(substr, needle) == 0)
+ fprintf(fout, "\tcase SECCLASS_%s:\n", map->name);
+ }
+ fprintf(fout, "\tcase SECCLASS_DIR:\n");
+ fprintf(fout, "\t\tfiledir = true;\n");
+ fprintf(fout, "\t\tbreak;\n");
+ fprintf(fout, "\tdefault:\n");
+ fprintf(fout, "\t\tbreak;\n");
+ fprintf(fout, "\t}\n\n");
+ fprintf(fout, "\treturn filedir;\n");
+ fprintf(fout, "}\n");
+
fprintf(fout, "\n#endif\n");
fclose(fout);
diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
index e1e0092..a425bbe 100644
--- a/security/selinux/include/classmap.h
+++ b/security/selinux/include/classmap.h
@@ -15,6 +15,9 @@
/*
* Note: The name for any socket class should be suffixed by "socket",
* and doesn't contain more than one substr of "socket".
+ *
+ * The name for any file class should be suffixed by "file",
+ * and doesn't contain more than one substr of "file".
*/
struct security_class_mapping secclass_map[] = {
{ "security",
--
1.7.0.4
--
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 related [flat|nested] 8+ messages in thread* [v2 PATCH 2/2] role_transition for newly created files or dirs.
2011-03-11 7:20 [v2] [SELinux] Discussions about rbacsep Harry Ciao
2011-03-11 7:20 ` [PATCH 1/1] Files and dirs objects could retain user role Harry Ciao
2011-03-11 7:20 ` [v2 PATCH 1/2] Auto-generate security_is_filedir_class() Harry Ciao
@ 2011-03-11 7:21 ` Harry Ciao
2011-03-11 14:11 ` [v2] [SELinux] Discussions about rbacsep Stephen Smalley
3 siblings, 0 replies; 8+ messages in thread
From: Harry Ciao @ 2011-03-11 7:21 UTC (permalink / raw)
To: sds, cpebenito; +Cc: selinux
Support role_transition for newly created files or dirs object, so that
their role could be overriden by relevant role_transition rule than the
default "object_r".
In reference policy a role_transtion rule could be used for newly created
files or dirs object as in below format:
role_transition <subject role> <new object type> <new object role>;
for example,
role_transition sysadm_r user_home_t sysadm_r;
which means if the creator role == sysadm_r and the new object has a
type == user_home_t, then the new object role would be set to sysadm_r
as its creator.
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
---
security/selinux/ss/policydb.h | 2 +-
security/selinux/ss/services.c | 28 ++++++++++++++++++++--------
2 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/security/selinux/ss/policydb.h b/security/selinux/ss/policydb.h
index 4e3ab9d..ca223c7 100644
--- a/security/selinux/ss/policydb.h
+++ b/security/selinux/ss/policydb.h
@@ -72,7 +72,7 @@ struct role_datum {
struct role_trans {
u32 role; /* current role */
- u32 type; /* program executable type */
+ u32 type; /* program executable type, or new object type */
u32 new_role; /* new role */
struct role_trans *next;
};
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index bddcf30..e1707af 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -1370,9 +1370,9 @@ static int security_compute_sid(u32 ssid,
struct avtab_key avkey;
struct avtab_datum *avdatum;
struct avtab_node *node;
- u16 tclass;
+ u16 tclass, class_kern_val;
int rc = 0;
- bool sock;
+ bool sock, filedir;
if (!ss_initialized) {
switch (orig_tclass) {
@@ -1392,11 +1392,14 @@ static int security_compute_sid(u32 ssid,
if (kern) {
tclass = unmap_class(orig_tclass);
- sock = security_is_socket_class(orig_tclass);
+ class_kern_val = orig_tclass;
} else {
tclass = orig_tclass;
- sock = security_is_socket_class(map_class(tclass));
+ class_kern_val = map_class(tclass);
}
+
+ sock = security_is_socket_class(class_kern_val);
+ filedir = security_is_filedir_class(class_kern_val);
scontext = sidtab_search(&sidtab, ssid);
if (!scontext) {
@@ -1432,8 +1435,13 @@ static int security_compute_sid(u32 ssid,
newcontext.role = scontext->role;
newcontext.type = scontext->type;
} else {
- /* Use the well-defined object role. */
- newcontext.role = OBJECT_R_VAL;
+ if (filedir == true)
+ /* Inherit the role from the parent dir */
+ newcontext.role = tcontext->role;
+ else
+ /* Use the well-defined object role. */
+ newcontext.role = OBJECT_R_VAL;
+
/* Use the type of the related object. */
newcontext.type = tcontext->type;
}
@@ -1462,13 +1470,17 @@ static int security_compute_sid(u32 ssid,
}
/* Check for class-specific changes. */
- if (tclass == policydb.process_class) {
+ if ((tclass == policydb.process_class) || (filedir == true)) {
if (specified & AVTAB_TRANSITION) {
/* Look for a role transition rule. */
for (roletr = policydb.role_tr; roletr;
roletr = roletr->next) {
if (roletr->role == scontext->role &&
- roletr->type == tcontext->type) {
+ roletr->type == tcontext->type &&
+ tclass == policydb.process_class ||
+ roletr->role == scontext->role &&
+ roletr->type == newcontext.type &&
+ filedir == true) {
/* Use the role transition rule. */
newcontext.role = roletr->new_role;
break;
--
1.7.0.4
--
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 related [flat|nested] 8+ messages in thread* Re: [v2] [SELinux] Discussions about rbacsep
2011-03-11 7:20 [v2] [SELinux] Discussions about rbacsep Harry Ciao
` (2 preceding siblings ...)
2011-03-11 7:21 ` [v2 PATCH 2/2] role_transition for newly created files or dirs Harry Ciao
@ 2011-03-11 14:11 ` Stephen Smalley
2011-03-11 19:04 ` James Carter
3 siblings, 1 reply; 8+ messages in thread
From: Stephen Smalley @ 2011-03-11 14:11 UTC (permalink / raw)
To: Harry Ciao; +Cc: cpebenito, selinux
On Fri, 2011-03-11 at 15:20 +0800, Harry Ciao wrote:
> Hi Stephen and Chris,
>
> I have fixed the semantics of the role_transtion rule for the newly created files or dirs objects same as that for the process class. Since class-specific role_transition rules would be handled after TE rules, we could make use of checking if (newcontext.type == roletr->type) and (scontext->role == roletr->role) before setting newcontext.role = roletr->new_role;
>
> Then in the refpolicy we could adopt Stephen's suggestion for the role_transition rule such as:
> role_transition sysadm_r user_home_t sysadm_r;
>
> But I think we could omit class in above rule, since such role_transition semantics only takes place when filedir == true, that is, when the new object is of file or dir class.
If we omit the class, then the above statement has two possible
interpretations:
1) When a process in sysadm_r executes a program labeled user_home_t,
the process transitions to sysadm_r (no effect in this case, but it
would have an effect if the new role were something other than the old
one), or
2) When a process creates a file in a directory labeled user_home_t,
then the new file will be labeled with sysadm_r.
I'm concerned about that ambiguity in the meaning of the rule if we
don't explicitly specify the class. Also, by not specifying the class,
you keep us from re-using this mechanism for other object classes in a
general manner.
I don't think that it would be too hard to add an optional class field
to the role_transition statements; you can follow the model of what we
did for range_transitions when we added the class field to it. That
does require a policy version bump and an updated checkpolicy/libsepol.
What would also be desirable would be a new policy construct that would
allow us to specify the default labeling behavior for each component of
the security context on a per-class basis, e.g.
role_default file fromtarget;
role_default process fromsource;
user_default socket fromsource;
...
That would eliminate the need for the security_is_*_class functions and
the special handling in the kernel for particular classes, and migrate
all of this logic into the policy. That however may be more than you
are willing to take on at the present time.
--
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] 8+ messages in thread* Re: [v2] [SELinux] Discussions about rbacsep
2011-03-11 14:11 ` [v2] [SELinux] Discussions about rbacsep Stephen Smalley
@ 2011-03-11 19:04 ` James Carter
2011-03-12 12:26 ` HarryCiao
0 siblings, 1 reply; 8+ messages in thread
From: James Carter @ 2011-03-11 19:04 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Harry Ciao, cpebenito, selinux
On Fri, 2011-03-11 at 09:11 -0500, Stephen Smalley wrote:
> On Fri, 2011-03-11 at 15:20 +0800, Harry Ciao wrote:
> > Hi Stephen and Chris,
> >
> > I have fixed the semantics of the role_transtion rule for the newly created files or dirs objects same as that for the process class. Since class-specific role_transition rules would be handled after TE rules, we could make use of checking if (newcontext.type == roletr->type) and (scontext->role == roletr->role) before setting newcontext.role = roletr->new_role;
> >
> > Then in the refpolicy we could adopt Stephen's suggestion for the role_transition rule such as:
> > role_transition sysadm_r user_home_t sysadm_r;
> >
> > But I think we could omit class in above rule, since such role_transition semantics only takes place when filedir == true, that is, when the new object is of file or dir class.
>
> If we omit the class, then the above statement has two possible
> interpretations:
> 1) When a process in sysadm_r executes a program labeled user_home_t,
> the process transitions to sysadm_r (no effect in this case, but it
> would have an effect if the new role were something other than the old
> one), or
> 2) When a process creates a file in a directory labeled user_home_t,
> then the new file will be labeled with sysadm_r.
>
> I'm concerned about that ambiguity in the meaning of the rule if we
> don't explicitly specify the class. Also, by not specifying the class,
> you keep us from re-using this mechanism for other object classes in a
> general manner.
>
> I don't think that it would be too hard to add an optional class field
> to the role_transition statements; you can follow the model of what we
> did for range_transitions when we added the class field to it. That
> does require a policy version bump and an updated checkpolicy/libsepol.
>
Adding the class field and making the role_transition look like other
transition rules seem to me to be the right way to go.
> What would also be desirable would be a new policy construct that would
> allow us to specify the default labeling behavior for each component of
> the security context on a per-class basis, e.g.
> role_default file fromtarget;
> role_default process fromsource;
> user_default socket fromsource;
> ...
>
I like the idea, but something like "role_default_label_src" or
"role_label_src" would seem to be more descriptive to me.
> That would eliminate the need for the security_is_*_class functions and
> the special handling in the kernel for particular classes, and migrate
> all of this logic into the policy. That however may be more than you
> are willing to take on at the present time.
>
--
James Carter <jwcart2@tycho.nsa.gov>
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] 8+ messages in thread
* RE: [v2] [SELinux] Discussions about rbacsep
2011-03-11 19:04 ` James Carter
@ 2011-03-12 12:26 ` HarryCiao
0 siblings, 0 replies; 8+ messages in thread
From: HarryCiao @ 2011-03-12 12:26 UTC (permalink / raw)
To: jwcart2, Stephen Smalley
Cc: qingtao.cao, Christopher J. PeBenito, selinux-mailing-list
[-- Attachment #1: Type: text/plain, Size: 3892 bytes --]
Hi Stephen and James,
Thanks a lot for all your comments.
I've got your points, adding class support to the role_transition rule would eliminate the ambiguity and provide the required flexibility to make use of it in a general manner, I will start from the binary reprensantation of the range_transition rule and how libsepol/checkpolicy handles it.
Yes, all policy stuff should be migrated to userspace than in kernel. I will be very glad to try to add all these new "xxx_default <class> <fromsubject/object>" rules after the role_transition rule improvement.
Best regards,
Harry
> Subject: Re: [v2] [SELinux] Discussions about rbacsep
> From: jwcart2@tycho.nsa.gov
> To: sds@tycho.nsa.gov
> CC: qingtao.cao@windriver.com; cpebenito@tresys.com; selinux@tycho.nsa.gov
> Date: Fri, 11 Mar 2011 14:04:20 -0500
>
> On Fri, 2011-03-11 at 09:11 -0500, Stephen Smalley wrote:
> > On Fri, 2011-03-11 at 15:20 +0800, Harry Ciao wrote:
> > > Hi Stephen and Chris,
> > >
> > > I have fixed the semantics of the role_transtion rule for the newly created files or dirs objects same as that for the process class. Since class-specific role_transition rules would be handled after TE rules, we could make use of checking if (newcontext.type == roletr->type) and (scontext->role == roletr->role) before setting newcontext.role = roletr->new_role;
> > >
> > > Then in the refpolicy we could adopt Stephen's suggestion for the role_transition rule such as:
> > > role_transition sysadm_r user_home_t sysadm_r;
> > >
> > > But I think we could omit class in above rule, since such role_transition semantics only takes place when filedir == true, that is, when the new object is of file or dir class.
> >
> > If we omit the class, then the above statement has two possible
> > interpretations:
> > 1) When a process in sysadm_r executes a program labeled user_home_t,
> > the process transitions to sysadm_r (no effect in this case, but it
> > would have an effect if the new role were something other than the old
> > one), or
> > 2) When a process creates a file in a directory labeled user_home_t,
> > then the new file will be labeled with sysadm_r.
> >
> > I'm concerned about that ambiguity in the meaning of the rule if we
> > don't explicitly specify the class. Also, by not specifying the class,
> > you keep us from re-using this mechanism for other object classes in a
> > general manner.
> >
> > I don't think that it would be too hard to add an optional class field
> > to the role_transition statements; you can follow the model of what we
> > did for range_transitions when we added the class field to it. That
> > does require a policy version bump and an updated checkpolicy/libsepol.
> >
>
> Adding the class field and making the role_transition look like other
> transition rules seem to me to be the right way to go.
>
> > What would also be desirable would be a new policy construct that would
> > allow us to specify the default labeling behavior for each component of
> > the security context on a per-class basis, e.g.
> > role_default file fromtarget;
> > role_default process fromsource;
> > user_default socket fromsource;
> > ...
> >
>
> I like the idea, but something like "role_default_label_src" or
> "role_label_src" would seem to be more descriptive to me.
>
> > That would eliminate the need for the security_is_*_class functions and
> > the special handling in the kernel for particular classes, and migrate
> > all of this logic into the policy. That however may be more than you
> > are willing to take on at the present time.
> >
>
> --
> James Carter <jwcart2@tycho.nsa.gov>
> 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.
[-- Attachment #2: Type: text/html, Size: 4800 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread