user_trans/user_trans_boolean macro

user_trans/user_trans_boolean macro

[Ivan Gyurdiev]

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

Is there anything wrong with this patch?

It continues to remove stuff from x_client_domain.
This time the type declaration is removed, along with 
the transboolean stuff. The transition stuff is placed
in new macros called user_trans and user_trans_boolean.

Points of interest:

- can_exec($1_$2_t, $2_exec_t)
I don't quite understand what this does, but I remember
domains needed it. It was also in the x_client rules.

- nscd_client_domain was removed for mplayer and mozilla.
I didn't see any problems. 

- tmp_domain for tvtime now allows for fifo_file. This
addresses a denial I noticed.

If there is nothing wrong with this patch, can I convert
other domains in macros/program to use this macro? 
Is it a problem if they don't have the above can_exec rule?

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

[-- Attachment #2: user_trans_v0.diff --]
[-- Type: text/x-patch, Size: 6900 bytes --]

diff -aur policy.old/macros/global_macros.te policy/macros/global_macros.te
--- policy.old/macros/global_macros.te	2005-03-11 21:55:06.000000000 -0500
+++ policy/macros/global_macros.te	2005-03-13 00:06:05.000000000 -0500
@@ -170,6 +170,37 @@
 allow $1 $2_devpts_t:chr_file { read write getattr ioctl };
 ') 
 
+##################################
+#
+# user_trans(user, target)
+#
+# Transition the user to the target domain
+#
+define(`user_trans', `
+domain_auto_trans($1_t, $2_exec_t, $1_$2_t)
+can_exec($1_$2_t, $2_exec_t)
+role $1_r types $1_$2_t;
+')
+
+##################################
+#
+# user_trans_boolean(user, target)
+#
+# Transition the user to the target domain
+# For the user domain, do this conditional
+# on a boolean
+#
+define(`user_trans_boolean', `
+ifelse($1, user, `
+bool disable_user_$2 false;
+')
+role $1_r types $1_$2_t;
+if (! disable_user_$2) {
+domain_auto_trans($1_t, $2_exec_t, $1_$2_t)
+can_exec($1_$2_t, $2_exec_t)
+}
+')
+
 #
 # general_proc_read_access(domain)
 #
diff -aur policy.old/macros/program/games_domain.te policy/macros/program/games_domain.te
--- policy.old/macros/program/games_domain.te	2005-03-10 14:32:25.000000000 -0500
+++ policy/macros/program/games_domain.te	2005-03-12 19:18:23.000000000 -0500
@@ -10,7 +10,14 @@
 #
 #
 define(`games_domain', `
-x_client_domain($1, `games', `, transitionbool')
+
+# Type transiton
+type $1_games_t, domain, nscd_client_domain;
+user_trans_boolean($1, games)
+
+# X access, Private tmp
+x_client_domain($1, games)
+tmp_domain($1_games)
 
 allow $1_games_t var_t:dir { search getattr };
 rw_dir_create_file($1_games_t, games_data_t)
@@ -29,7 +36,6 @@
 
 dontaudit $1_games_t sysctl_t:dir search;
 
-tmp_domain($1_games)
 allow $1_games_t urandom_device_t:chr_file { getattr ioctl read };
 ifdef(`xdm.te', `
 allow $1_games_t xdm_tmp_t:dir rw_dir_perms;
diff -aur policy.old/macros/program/gift_macros.te policy/macros/program/gift_macros.te
--- policy.old/macros/program/gift_macros.te	2005-03-11 21:34:13.000000000 -0500
+++ policy/macros/program/gift_macros.te	2005-03-13 00:21:22.000000000 -0500
@@ -12,20 +12,17 @@
 
 define(`gift_domain', `
 
-# Connect to X
-x_client_domain($1, gift, `')	
+# Type transition
+type $1_gift_t, domain, nscd_client_domain;
+user_trans($1, gift)
 
-# Transition
-domain_auto_trans($1_t, gift_exec_t, $1_gift_t)
-can_exec($1_gift_t, gift_exec_t)
-role $1_r types $1_gift_t;
+# X access, Home access
+x_client_domain($1, gift)
+home_domain($1, gift)
 
 # Self permissions
 allow $1_gift_t self:process getsched;
 
-# Home files
-home_domain($1, gift)
-
 # Fonts, icons
 r_dir_file($1_gift_t, usr_t)
 r_dir_file($1_gift_t, fonts_t)
diff -aur policy.old/macros/program/mozilla_macros.te policy/macros/program/mozilla_macros.te
--- policy.old/macros/program/mozilla_macros.te	2005-03-10 14:32:25.000000000 -0500
+++ policy/macros/program/mozilla_macros.te	2005-03-12 18:52:11.000000000 -0500
@@ -16,12 +16,11 @@
 # provided separately in domains/program/mozilla.te. 
 #
 define(`mozilla_domain',`
-x_client_domain($1, mozilla, `, web_client_domain, privlog, transitionbool')
+type $1_mozilla_t, domain, web_client_domain, privlog;
 
-# Configuration
+user_trans_boolean($1, mozilla)
 home_domain($1, mozilla)
-
-# Allow mozilla to browse files
+x_client_domain($1, mozilla)
 file_browse_domain($1_mozilla_t)
 
 allow $1_mozilla_t sound_device_t:chr_file rw_file_perms;
diff -aur policy.old/macros/program/mplayer_macros.te policy/macros/program/mplayer_macros.te
--- policy.old/macros/program/mplayer_macros.te	2005-03-10 14:32:25.000000000 -0500
+++ policy/macros/program/mplayer_macros.te	2005-03-12 18:57:22.000000000 -0500
@@ -64,13 +64,13 @@
 
 define(`mplayer_domain',`
 
-# Derive from X client domain
-x_client_domain($1, `mplayer', `')
+# Type transition
+type $1_mplayer_t, domain;
+user_trans($1, mplayer)
 
-# Mplayer configuration here
+# Home access, X access, Browse files
 home_domain($1, mplayer)
-
-# Allow mplayer to browse files
+x_client_domain($1, mplayer)
 file_browse_domain($1_mplayer_t)
 
 # Mplayer common stuff
@@ -101,12 +101,8 @@
 # FIXME: privhome temporarily removed...
 type $1_mencoder_t, domain;
 
-# Transition
-domain_auto_trans($1_t, mencoder_exec_t, $1_mencoder_t)
-can_exec($1_mencoder_t, mencoder_exec_t)
-role $1_r types $1_mencoder_t;
-
-# Read home config
+# Transition, access mplayer home domain
+user_trans($1, mencoder)
 home_domain_access($1_mencoder_t, $1, mplayer)
 
 # Mplayer common stuff
diff -aur policy.old/macros/program/tvtime_macros.te policy/macros/program/tvtime_macros.te
--- policy.old/macros/program/tvtime_macros.te	2005-03-11 21:34:13.000000000 -0500
+++ policy/macros/program/tvtime_macros.te	2005-03-12 21:24:15.000000000 -0500
@@ -19,7 +19,13 @@
 ifdef(`tvtime.te', `
 define(`tvtime_domain',`
 
+# Type transition
+type $1_tvtime_t, domain, nscd_client_domain;
+user_trans($1, tvtime)
+
+# Home access, X access
 home_domain($1, tvtime)
+tmp_domain($1_tvtime, `', `{ file dir fifo_file }')
 x_client_domain($1, tvtime)
 
 allow $1_tvtime_t urandom_device_t:chr_file read;
@@ -28,7 +34,6 @@
 allow $1_tvtime_t sound_device_t:chr_file read;
 allow $1_tvtime_t $1_home_t:dir { getattr read search };
 allow $1_tvtime_t $1_home_t:file { getattr read };
-tmp_domain($1_tvtime)
 allow $1_tvtime_t self:capability { setuid sys_nice sys_resource };
 allow $1_tvtime_t self:process setsched;
 allow $1_tvtime_t usr_t:file { getattr read };
diff -aur policy.old/macros/program/x_client_macros.te policy/macros/program/x_client_macros.te
--- policy.old/macros/program/x_client_macros.te	2005-03-10 14:32:25.000000000 -0500
+++ policy/macros/program/x_client_macros.te	2005-03-12 18:45:53.000000000 -0500
@@ -37,39 +37,11 @@
 ')
 
 #
-# x_client_domain(domain_prefix)
+# x_client_domain(user, app)
 #
-# Define a derived domain for an X program when executed by
-# a user domain.  
-#
-# The type declaration for the executable type for this program ($2_exec_t)
-# must be provided separately!
-#
-# The first parameter is the base name for the domain/role (EG user or sysadm)
-# The second parameter is the program name (EG $2)
-# The third parameter is the attributes for the domain (if any)
+# Defines common X access rules for the user_app_t domain
 #
 define(`x_client_domain',`
-# Derived domain based on the calling user domain and the program.
-type $1_$2_t, domain, nscd_client_domain $3;
-
-ifelse(index(`$3', `transitionbool'), -1, `
-domain_auto_trans($1_t, $2_exec_t, $1_$2_t)
-can_exec($1_$2_t, $2_exec_t)
-', `
-ifelse($1, user, `
-bool disable_$2 false;
-')
-# Transition from the user domain to the derived domain.
-if (! disable_$2) {
-domain_auto_trans($1_t, $2_exec_t, $1_$2_t)
-can_exec($1_$2_t, $2_exec_t)
-}
-')
-
-# The user role is authorized for this domain.
-role $1_r types $1_$2_t;
 
 # This domain is granted permissions common to most domains (including can_net)
 can_network($1_$2_t)

Re: user_trans/user_trans_boolean macro

[Stephen Smalley]

On Sun, 2005-03-13 at 00:33 -0500, Ivan Gyurdiev wrote:
> Is there anything wrong with this patch?
> 
> It continues to remove stuff from x_client_domain.
> This time the type declaration is removed, along with 
> the transboolean stuff. The transition stuff is placed
> in new macros called user_trans and user_trans_boolean.

Why user_trans?  Nothing is specific to users or even user domains.

> Points of interest:
> 
> - can_exec($1_$2_t, $2_exec_t)
> I don't quite understand what this does, but I remember
> domains needed it. It was also in the x_client rules.

This seems wrong to me; domain_trans already allows rx_file_perms
between the new domain and the executable, so the only further
permission being added by this macro is execute_no_trans, and that is
wrong unless the program re-executes itself at times and wants to stay
in the same domain upon such re-execution.

in_user_role() is typically what is used for the role statement
> 
> - nscd_client_domain was removed for mplayer and mozilla.
> I didn't see any problems.

Are you running nscd?  If you are using it, it will be used for any
passwd, group, and host lookups, so many programs use it.

-- 
Stephen Smalley <sds@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.

Re: user_trans/user_trans_boolean macro

[Stephen Smalley]

On Mon, 2005-03-14 at 07:45 -0500, Stephen Smalley wrote:
> in_user_role() is typically what is used for the role statement

Never mind on that one - that is only if you want all user roles to have
access to the domain.

-- 
Stephen Smalley <sds@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.

Re: user_trans/user_trans_boolean macro

[Ivan Gyurdiev]

On Mon, 2005-03-14 at 07:45 -0500, Stephen Smalley wrote:
> On Sun, 2005-03-13 at 00:33 -0500, Ivan Gyurdiev wrote:
> > Is there anything wrong with this patch?
> > 
> > It continues to remove stuff from x_client_domain.
> > This time the type declaration is removed, along with 
> > the transboolean stuff. The transition stuff is placed
> > in new macros called user_trans and user_trans_boolean.
> 
> Why user_trans?  Nothing is specific to users or even user domains.

Well, the role (arg $1) is the user... but I guess I could make that
into a separate argument, and rename the macro for general usage if you
prefer. 

By the way, for the second statement I tried to put the role inside the
boolean, but that wouldn't work for some reason - syntax error?

> > Points of interest:
> > 
> > - can_exec($1_$2_t, $2_exec_t)
> > I don't quite understand what this does, but I remember
> > domains needed it. It was also in the x_client rules.
> 
> This seems wrong to me; domain_trans already allows rx_file_perms
> between the new domain and the executable, so the only further
> permission being added by this macro is execute_no_trans, and that is
> wrong unless the program re-executes itself at times and wants to stay
> in the same domain upon such re-execution.

That's what I figured it probably does - should I get rid of it?
I do remember denials without it, but I could test and see.

> > - nscd_client_domain was removed for mplayer and mozilla.
> > I didn't see any problems.
> 
> Are you running nscd?  If you are using it, it will be used for any
> passwd, group, and host lookups, so many programs use it.

Well, no, but I usually get denials anyway - there were denials for
tvtime, gift, and games, but none for mplayer and mozilla, so I thought
that perhaps they don't need it. It does seem rather strange that
mozilla wouldn't need it for host lookups.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: user_trans/user_trans_boolean macro

[Stephen Smalley]

On Mon, 2005-03-14 at 12:12 -0500, Ivan Gyurdiev wrote:
> Well, the role (arg $1) is the user... but I guess I could make that
> into a separate argument, and rename the macro for general usage if you
> prefer.

Seems confusing, as it has nothing to do with a user identity; the
argument is the prefix of a role (and its initial domain).

> By the way, for the second statement I tried to put the role inside the
> boolean, but that wouldn't work for some reason - syntax error?

The conditional policy extensions are only supported for TE rules (not
only in the policy compiler, but all the way down to the kernel logic).
It would be possible to extend to cover RBAC statements as well, but
would obviously require further work.

> That's what I figured it probably does - should I get rid of it?
> I do remember denials without it, but I could test and see.

I'd omit it unless the program truly needs to re-exec itself.

> Well, no, but I usually get denials anyway - there were denials for
> tvtime, gift, and games, but none for mplayer and mozilla, so I thought
> that perhaps they don't need it. It does seem rather strange that
> mozilla wouldn't need it for host lookups.

Yes, since it is all handled internally by the library routines.  I'd be
hesitant to remove without testing with nscd enabled.

-- 
Stephen Smalley <sds@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.

Re: user_trans/user_trans_boolean macro

[Ivan Gyurdiev]

Ok, how about this instead - seems more useful

1) Renamed: user_trans -> allow_trans
2) Added role as a separate argument for flexibility
3) Remove boolean macro - declare boolean in the app .te file

#####################################################
#
# allow_trans(prefix, role_prefix, app_prefix)
#
# Transition user:$2_r:$1_t to user:$2_r:$1_$3_t
#
define(`allow_trans', `
role $2_r types $1_$3_t;
if (! disable_$1_$3_transition) {
domain_auto_trans($1_t, $3_exec_t, $1_$3_t)
}
')

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: user_trans/user_trans_boolean macro

[Ivan Gyurdiev]

3) Remove boolean macro - declare boolean in the app .te file

Well, declaring the boolean in the .te file doesn't work because of duplicates..
So, I'll make a macro called user_boolean that just declares that boolean
conditional on the if statement.

Anyway, what is the purpose of those booleans? Why do we not want to transition
to the target domain?

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: user_trans/user_trans_boolean macro

[Stephen Smalley]

On Mon, 2005-03-14 at 13:19 -0500, Ivan Gyurdiev wrote:
> 3) Remove boolean macro - declare boolean in the app .te file
> 
> Well, declaring the boolean in the .te file doesn't work because of duplicates..
> So, I'll make a macro called user_boolean that just declares that boolean
> conditional on the if statement.

Sorry, why can't you declare the boolean in the allow_trans macro?  And
what do you mean declares it conditional?

> Anyway, what is the purpose of those booleans? Why do we not want to transition
> to the target domain?

I think that Dan set them up to allow the option of running programs
directly in the user's domain, similar to how daemon transitions can be
disabled to leave them unconfined in the targeted policy.

-- 
Stephen Smalley <sds@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.

Re: user_trans/user_trans_boolean macro

[Ivan Gyurdiev]

On Mon, 2005-03-14 at 13:19 -0500, Ivan Gyurdiev wrote:
> 3) Remove boolean macro - declare boolean in the app .te file
> 
> Well, declaring the boolean in the .te file doesn't work because of duplicates..
> So, I'll make a macro called user_boolean that just declares that boolean
> conditional on the if statement.
> 
> Anyway, what is the purpose of those booleans? Why do we not want to transition
> to the target domain?

... and doesn't this work?

if (! disable_user_app_transition) {
bool disable_user_app_transition false;
}

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: user_trans/user_trans_boolean macro

[Stephen Smalley]

On Mon, 2005-03-14 at 13:31 -0500, Ivan Gyurdiev wrote:
> ... and doesn't this work?
> 
> if (! disable_user_app_transition) {
> bool disable_user_app_transition false;
> }

The compiler might allow it, but it doesn't make any sense to me.
Compiler likely just unconditionally defines it anyway.

-- 
Stephen Smalley <sds@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.

Re: user_trans/user_trans_boolean macro

[Ivan Gyurdiev]

On Mon, 2005-03-14 at 13:31 -0500, Stephen Smalley wrote:
> On Mon, 2005-03-14 at 13:19 -0500, Ivan Gyurdiev wrote:
> > 3) Remove boolean macro - declare boolean in the app .te file
> > 
> > Well, declaring the boolean in the .te file doesn't work because of duplicates..
> > So, I'll make a macro called user_boolean that just declares that boolean
> > conditional on the if statement.
> 
> Sorry, why can't you declare the boolean in the allow_trans macro?  And
> what do you mean declares it conditional?

Too many booleans... 
Ignore the conditional part, and the other stupid email I sent.
There must be an if statement to only declare the boolean once,
and not for every macro call. This is what I meant to write.

ifdef($1, user,`
bool disable_user_games_transition false;
')


> > Anyway, what is the purpose of those booleans? Why do we not want to transition
> > to the target domain?
> 
> I think that Dan set them up to allow the option of running programs
> directly in the user's domain, similar to how daemon transitions can be
> disabled to leave them unconfined in the targeted policy.

Well, I think the allow_trans macro, with if statements like the above
will work well - seems simple to me. 

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: user_trans/user_trans_boolean macro

[Stephen Smalley]

On Mon, 2005-03-14 at 14:43 -0500, Ivan Gyurdiev wrote:
> I'm improving this macro with the purpose of using it in a lot of
> places (couples role/trans role, provides controlling boolean - seems
> beneficial)
> 
> I have a question, however - why is it that role declarations do not
> tolerate duplicates. I've noticed allow/dontaudit rules are tolerant
> to duplicates. 

Role declarations do "tolerate" duplicates, i.e. multiple role
declarations may exist for the same role, in which case the union is
taken, and redundant declarations cause no harm.  What is your question?

-- 
Stephen Smalley <sds@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.

Re: user_trans/user_trans_boolean macro

[Ivan Gyurdiev]

I'm improving this macro with the purpose of using it in a lot of
places (couples role/trans role, provides controlling boolean - seems
beneficial)

I have a question, however - why is it that role declarations do not
tolerate duplicates. I've noticed allow/dontaudit rules are tolerant
to duplicates. 

New version: 

#####################################################
#
# allow_trans(prefix, role_prefix, app_prefix, exec_types)
#
# Transition user:$2_r:$1_t to user:$2_r:$1_$3_t on exec_types
#
define(`allow_trans', `
role $2_r types $1_$3_t;
if (! disable_$1_$3_trans) {
ifelse($4, `', `
domain_auto_trans($1_t, $3_exec_t, $1_$3_t)
',
domain_auto_trans($1_t, $4, $1_$3_t)
')
}
')



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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: user_trans/user_trans_boolean macro

[Ivan Gyurdiev]

On Mon, 2005-03-14 at 14:41 -0500, Stephen Smalley wrote:
> On Mon, 2005-03-14 at 14:43 -0500, Ivan Gyurdiev wrote:
> > I'm improving this macro with the purpose of using it in a lot of
> > places (couples role/trans role, provides controlling boolean - seems
> > beneficial)
> > 
> > I have a question, however - why is it that role declarations do not
> > tolerate duplicates. I've noticed allow/dontaudit rules are tolerant
> > to duplicates. 
> 
> Role declarations do "tolerate" duplicates, i.e. multiple role
> declarations may exist for the same role, in which case the union is
> taken, and redundant declarations cause no harm.  What is your question?

You're right, my mistake ...
Not sure why I was running into errors earlier.

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: user_trans/user_trans_boolean macro

[Stephen Smalley]

On Mon, 2005-03-14 at 15:18 -0500, Ivan Gyurdiev wrote:
> I guess what I'm trying to figure out is why 
> domain_auto_trans doesn't add the role access rule
> by default. Isn't this always necessary if you want
> a transition to occur?

domain_auto_trans() can be (and is ) used from any domain, not just a
user domain.  One could certainly add an optional argument for a role.

-- 
Stephen Smalley <sds@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.

Re: user_trans/user_trans_boolean macro

[Ivan Gyurdiev]

I guess what I'm trying to figure out is why 
domain_auto_trans doesn't add the role access rule
by default. Isn't this always necessary if you want
a transition to occur?

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


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: user_trans/user_trans_boolean macro

[Daniel J Walsh]

Ivan Gyurdiev wrote:

>Ok, how about this instead - seems more useful
>
>1) Renamed: user_trans -> allow_trans
>2) Added role as a separate argument for flexibility
>3) Remove boolean macro - declare boolean in the app .te file
>
>#####################################################
>#
># allow_trans(prefix, role_prefix, app_prefix)
>#
># Transition user:$2_r:$1_t to user:$2_r:$1_$3_t
>#
>define(`allow_trans', `
>role $2_r types $1_$3_t;
>if (! disable_$1_$3_transition) {
>domain_auto_trans($1_t, $3_exec_t, $1_$3_t)
>}
>')
>
>  
>
disable_$1_transition is so the admin can decide if they want certain 
users to transition. 
For example, I think we should have a locked down mozilla policy where 
it only shows
web pages and only allows you do download to /tmp or My Downloads.    It 
should not be
allowed to touch the users home directory.  This should be the only 
mozilla policy, and the
admin gets the ability to turn on/off the policy.  So if you want to be 
protected by Mozilla
policy you give up alot of its functionality otherwise you run it as 
user_t.  The way Mozilla
was policy is going is we end up with user_t privs anyways.  I don't 
think we need a boolean
for each role though.  IE I think the exposion of booleans is worse the 
the loss of customizability.

So one disable_mozilla_trans is better than disable_user_mozilla_trans.

Dan

-- 



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: user_trans/user_trans_boolean macro

[Ivan Gyurdiev]

On Mon, 2005-03-14 at 15:13 -0500, Stephen Smalley wrote:
> On Mon, 2005-03-14 at 15:18 -0500, Ivan Gyurdiev wrote:
> > I guess what I'm trying to figure out is why 
> > domain_auto_trans doesn't add the role access rule
> > by default. Isn't this always necessary if you want
> > a transition to occur?
> 
> domain_auto_trans() can be (and is ) used from any domain, not just a
> user domain.  One could certainly add an optional argument for a role

Well, I think I will conclude that I'll leave things exactly as they
are :) It seems a bad idea to me to add yet another argument. The macro
I was trying to write also seems like a bad idea now. 

The only thing I will do is add controlling booleans to the domain.te
file, and use them in the macros.te file around the auto_trans call 
(and remove all of this from x_client_macros).

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