update question

update question

[ccallen]

If there is an older version of selinux installed, does the old one need to
be uninstalled before running the new version? If so is there a file with
the steps to do this? I thought I had read something on that before, but
cant find it now.

Conan


--
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: update question

[Stephen Smalley]

On Wed, 2003-04-16 at 04:24, ccallen wrote:
> If there is an older version of selinux installed, does the old one need to
> be uninstalled before running the new version? If so is there a file with
> the steps to do this? I thought I had read something on that before, but
> cant find it now.

No, you don't need to "uninstall" the old version of SELinux.  The only
case where you had to do some cleanup was if you were running the
original SELinux kernel patch (pre-LSM) and were transitioning to the
LSM-based SELinux.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: update question

[Russell Coker]

On Wed, 16 Apr 2003 18:24, ccallen wrote:
> If there is an older version of selinux installed, does the old one need to
> be uninstalled before running the new version? If so is there a file with
> the steps to do this? I thought I had read something on that before, but
> cant find it now.

You don't need to uninstall it.  However upgrades sometimes have changes to 
the file contexts files (*.fc) which mean that you need to relabel part of 
your file system after an upgrade.

The most recent such change was the addition of locale_t which requires that 
all time zone information files and directories be relabelled.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



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

SUDO package

[Daniel J Walsh]

I have placed the latest sudo code in

ftp://people.redhat.com/dwalsh/SELinux/sudo

This code seems to work with the provided policy.  I have provided a src 
rpm,
and binary i386.rpm (for 8.0) and the two policy files.  

The binary i386 will install the policy files and reload the updated 
policy.  It
also does a chsid on the /usr/bin/sudo.  

This is my first try at writing Policy so please send me comments.


Thanks,
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: SUDO package

[Stephen Smalley]

On Fri, 2003-04-18 at 12:02, Daniel J Walsh wrote:
> I have placed the latest sudo code in
> 
> ftp://people.redhat.com/dwalsh/SELinux/sudo
> 
> This code seems to work with the provided policy.  I have provided a src 
> rpm,
> and binary i386.rpm (for 8.0) and the two policy files.  
> 
> The binary i386 will install the policy files and reload the updated 
> policy.  It
> also does a chsid on the /usr/bin/sudo.  
> 
> This is my first try at writing Policy so please send me comments.

Thanks for working on this task.  A few comments on your policy below:

># Read the /dir/*
>allow sudo_t var_t:dir search;

The comment doesn't seem to match the rule.  There is a rule later in
your sudo.te file that does grant read access to all types for the
directory class, but that isn't desirable.  You should explicitly
enumerate the types to which sudo needs access.

># Read the /etc/*
>allow sudo_t etc_t:file r_file_perms;

You should also grant search access to etc_t directories here.

># Read /dev directories and any symbolic links.
>allow sudo_t device_t:dir r_dir_perms;

The comment suggests that you also wanted 'allow sudo_t
device_t:lnk_file r_file_perms;'.

>type sudo_exec_t, file_type, exec_type, sysadmfile;
>domain_auto_trans(userdomain, sudo_exec_t, sudo_t)

The comment from the top of sudo.te about sudo_exec_t would seem to
belong with these rules.

>allow sudo_t user_home_dir_type:dir search;

Does sudo need to search the user's home directory in order to function,
or is this just an unnecessary probe during initialization?  It might be
sufficient to use dontaudit to suppress the audit message without
granting the permission.

># Allow sudo_t to transition to user domains.
># domain_trans(sudo_t, shell_exec_t, userdomain)
>domain_trans(sudo_t,{ bin_t sbin_t exec_type }, userdomain)
>domain_trans(sudo_t, ls_exec_t, userdomain)

The exec_type attribute includes shell_exec_t and ls_exec_t, so you
don't need separate rules for them.  Ultimately, we should define a
separate attribute specifically for programs that should be executable
via sudo, and only apply it to those programs, rather than using the
more pervasive exec_type.

>allow sudo_t self:udp_socket { create ioctl };
>allow sudo_t self:file { read write };
>allow sudo_t self:lnk_file { read };

The first rule above appears to be to support the load_interfaces() call
by sudo, so you might annotate it with a comment to that effect.
general_domain_access grants read access to the /proc/pid entries for
the domain, so I don't think you need the latter two rules (and I'm not
clear as to why you would need to grant write permission to self:file). 
># Use capabilities.
>allow sudo_t self:capability { setuid setgid net_bind_service
>dac_override sys_resource};

Does sudo truly require all of these capabilities?  Also, this rule is
duplicated a second time further down in the sudo.te file.

>allow sudo_t *:dir r_dir_perms;
>#allow sudo_t *:file read;

Using '*' considered harmful, except for permission sets.  In addition
to being excessively permissive (does sudo truly need to be able to read
every directory in the system), it yields a large number of meaningless
rules, because '*' expands to the full set of types, many of which can
never be associated with a directory anyway.  If you truly needed to
grant access to all files, you would use something like 'allow sudo_t
file_type:dir r_dir_perms;', but I don't think that this is justified.
I should probably drop '*' support out of the language except for
permission sets.

># Relabel terminals.
>#allow sudo_t ttyfile:chr_file { getattr relabelfrom relabelto };
>#allow sudo_t ptyfile:chr_file { getattr relabelfrom relabelto };

It doesn't appear that this functionality is implemented in your sudo
patch yet; newrole relabels the tty or pty to a type derived from the
new domain so that the terminal is protected properly.

># Access terminals.
>allow sudo_t tty_device_t:chr_file { getattr relabelfrom relabelto
rw_file_perms ioctl};
>allow sudo_t devtty_t:chr_file { getattr relabelfrom relabelto
rw_file_perms ioctl};

I don't believe that these two rules are necessary.  sudo should only
need to relabel and access the derived tty and pty types covered by the
ttyfile and ptyfile type attributes.

>allow sudo_t ttyfile:chr_file { getattr relabelfrom relabelto
rw_file_perms};
>allow sudo_t ptyfile:chr_file { getattr relabelfrom relabelto
rw_file_perms};
>ifdef(`gnome-pty-helper.te', `allow sudo_t gphdomain:fd use;')

Here you have mixed rules for relabeling with rules for access, which is
ok, but the comment doesn't reflect it, and you still have the earlier
rules for relabeling in sudo.te (but commented out).

>#
># Allow sysadm_t to reap a user_t process 
># created via sudo.
>#
>allow userdomain userdomain:process { sigchld };

This doesn't truly belong in sudo.te (or in newrole.te), and should be
reduced down to only grant this permission for pairs of domains that can
be legitimately transitioned via sudo or newrole.

># Additional type_change rules to deal with ttys that
># were left in an old type due to an expected termination of sudo.
>type_change sysadm_t user_tty_device_t:chr_file sysadm_tty_device_t;
>type_change user_t sysadm_tty_device_t:chr_file user_tty_device_t;
>type_change sysadm_t user_devpts_t:chr_file sysadm_devpts_t;
>type_change user_t sysadm_devpts_t:chr_file user_devpts_t;

These rules (and the corresponding ones in newrole.te) should be moved
somewhere common to avoid duplication.

># create run file 
>allow sudo_t var_run_t:file create_file_perms;
>allow sudo_t var_run_t:dir create_dir_perms;

I would recommend defining a separate type for sudo's /var/run files,
e.g.:
type sudo_var_run_t, file_type, sysadmfile;
file_type_auto_trans(sudo_t, var_run_t, sudo_var_run_t)

And you will need to define an entry in sudo.fc to initially assign
sudo_var_run_t to /var/run/sudo.

># Everything else is in the sudo_domain macro in
># macros/program/sudo_macros.te.

I think that this comment is obsolete (unless there is a macro that you
haven't shown to us).

># Failed reads to /proc cause no harm, so don't audit them
>dontaudit sudo_t proc_t:dir search;
>dontaudit sudo_t proc_t:lnk_file read;

You could grant these permissions so that sudo can access its /proc/self
entries if you wanted to do so.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: SUDO package

[Russell Coker]

On Wed, 23 Apr 2003 00:19, Stephen Smalley wrote:
> >allow sudo_t user_home_dir_type:dir search;
>
> Does sudo need to search the user's home directory in order to function,
> or is this just an unnecessary probe during initialization?  It might be
> sufficient to use dontaudit to suppress the audit message without
> granting the permission.

/bin/login, /bin/su, and sshd all require search access to the user home 
directory.  I recall that last time I tried removing such access it would 
result in $HOME environment variable being set incorrectly and other things 
not working as expected.

> ># Allow sudo_t to transition to user domains.
> ># domain_trans(sudo_t, shell_exec_t, userdomain)
> >domain_trans(sudo_t,{ bin_t sbin_t exec_type }, userdomain)
> >domain_trans(sudo_t, ls_exec_t, userdomain)
>
> The exec_type attribute includes shell_exec_t and ls_exec_t, so you
> don't need separate rules for them.  Ultimately, we should define a
> separate attribute specifically for programs that should be executable
> via sudo, and only apply it to those programs, rather than using the
> more pervasive exec_type.

This is difficult as we often want to allow existing programs that have their 
own type (such as ls) to be run (requiring lots of policy for su) and also we 
require relabelling bin_t and sbin_t programs for this (which requires a new 
attribute for these types so that all the other domains can continue 
executing them).

> I should probably drop '*' support out of the language except for
> permission sets.

Good idea.  If I knew about it when I first started writing policy I'm sure I 
would have misused it horribly.  ;)

> ># Allow sysadm_t to reap a user_t process
> ># created via sudo.
> >#
> >allow userdomain userdomain:process { sigchld };
>
> This doesn't truly belong in sudo.te (or in newrole.te), and should be
> reduced down to only grant this permission for pairs of domains that can
> be legitimately transitioned via sudo or newrole.

However if sudo is to relabel the tty device back to it's original type then 
it has to keep running for the duration of the child process it spawns.  
Therefire the child domain should only be sending sigchld to sudo not to the 
shell which launched sudo.

> ># Additional type_change rules to deal with ttys that
> ># were left in an old type due to an expected termination of sudo.
> >type_change sysadm_t user_tty_device_t:chr_file sysadm_tty_device_t;
> >type_change user_t sysadm_tty_device_t:chr_file user_tty_device_t;
> >type_change sysadm_t user_devpts_t:chr_file sysadm_devpts_t;
> >type_change user_t sysadm_devpts_t:chr_file user_devpts_t;
>
> These rules (and the corresponding ones in newrole.te) should be moved
> somewhere common to avoid duplication.

The role_tty_type_change() macro that is defined and used in domains/user.te 
already does this.  The above is a result of copying from the old newrole.te 
policy.

> ># create run file
> >allow sudo_t var_run_t:file create_file_perms;
> >allow sudo_t var_run_t:dir create_dir_perms;
>
> I would recommend defining a separate type for sudo's /var/run files,
> e.g.:
> type sudo_var_run_t, file_type, sysadmfile;
> file_type_auto_trans(sudo_t, var_run_t, sudo_var_run_t)

In the daemon_domain() macro defined in macros/global_macros.te the naming 
scheme var_run_$1_t is used.  It might make things easier in future to use 
that.

We probably should have a macro var_run_domain() which is used by 
daemon_domain() and by other policy such as the sudo policy.

How about something like the following:
define(`var_run_domain', `
type var_run_$1_t, file_type, sysadmfile, lockfile;
file_type_auto_trans($1_t, var_run_t, var_run_$1_t)
')

Or we could change the naming scheme to something else.  Log files etc have 
the _log_t part appended to the base name of the program domain.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
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: SUDO package

[Stephen Smalley]

On Wed, 2003-04-23 at 03:10, Russell Coker wrote:
> In the daemon_domain() macro defined in macros/global_macros.te the naming 
> scheme var_run_$1_t is used.  It might make things easier in future to use 
> that.
> 
> We probably should have a macro var_run_domain() which is used by 
> daemon_domain() and by other policy such as the sudo policy.
> 
> How about something like the following:
> define(`var_run_domain', `
> type var_run_$1_t, file_type, sysadmfile, lockfile;
> file_type_auto_trans($1_t, var_run_t, var_run_$1_t)
> ')
> 
> Or we could change the naming scheme to something else.  Log files etc have 
> the _log_t part appended to the base name of the program domain.

I prefer extending the domain name with the type suffix, but this is
obviously not a big deal as long as we are consistent.  It is likely
easier to quickly see what types are associated with a given domain if
they use the domain name as the prefix.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: SUDO package

[Russell Coker]

On Fri, 25 Apr 2003 03:31, Stephen Smalley wrote:
> I prefer extending the domain name with the type suffix, but this is
> obviously not a big deal as long as we are consistent.  It is likely
> easier to quickly see what types are associated with a given domain if
> they use the domain name as the prefix.

OK.  I had been tending towards the same conclusion, but hadn't been looking 
forward to the hassle of changing it.

I have now re-written most of the policy for such things, I'll test it out 
over the next few days and I'll have something ready for you to look at 
within a week.

BTW  What shall we do about all the other changes I've made recently?  The 
unified diff between my tree and yours is probably in excess of 5,000 lines, 
it would probably be most conveniant for everyone if we try getting things 
merged now.

Is there someone else who can look into this?  I know you're really busy with 
2.5 stuff right now.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
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: SUDO package

[Howard Holm]

I'm going to take on some of the example policy coordination work to try
relieve Stephen a little.  Try not to bury me too deep in policy patches
the first week. :-)

On Thu, 2003-04-24 at 14:07, Russell Coker wrote:
> On Fri, 25 Apr 2003 03:31, Stephen Smalley wrote:
> > I prefer extending the domain name with the type suffix, but this is
> > obviously not a big deal as long as we are consistent.  It is likely
> > easier to quickly see what types are associated with a given domain if
> > they use the domain name as the prefix.
> 
> OK.  I had been tending towards the same conclusion, but hadn't been looking 
> forward to the hassle of changing it.
> 
> I have now re-written most of the policy for such things, I'll test it out 
> over the next few days and I'll have something ready for you to look at 
> within a week.
> 
> BTW  What shall we do about all the other changes I've made recently?  The 
> unified diff between my tree and yours is probably in excess of 5,000 lines, 
> it would probably be most conveniant for everyone if we try getting things 
> merged now.
> 
> Is there someone else who can look into this?  I know you're really busy with 
> 2.5 stuff right now.

-- 
Howard Holm <hdholm@epoch.ncsc.mil>
Secure Systems Research Office
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: SUDO package

[Daniel J Walsh]

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

Stephen Smalley wrote:

>On Tue, 2003-04-22 at 16:04, Daniel J Walsh wrote:
>  
>
>>I don't think you define a separate attribute for every program that
>>can be executed, since by 
>>definition sudo can run every program on the system.
>>    
>>
>
>Not a separate attribute for every program, but a single new attribute
>that is associated with every program type that should be executable via
>sudo.  By using exec_type, you limit the freedom of other policy writers
>to create program types that they do not want to be executed via sudo. 
>It would be better to define a new attribute, add it to the attribute
>list for every type that should be executable by sudo, and use that
>attribute in your sudo.te file.
>  
>
>  
>
>>I have changed this to 
>>allow sudo_t file_type:dir search
>>It looks like sudo checks to see if the program exists before it
>>exec's it.
>>    
>>
>
>I would prefer that this rule be refined down to a specific list of
>directory types, or that a new attribute be defined and added to all
>desired directory types for this purpose.  Again, you want to allow
>other policy writers to be able to define directory types that cannot be
>searched by sudo in order to meet their policy goals.
>  
>
I have a hard time with the previous two.  Just seems to me SELinux 
needs some sort
of dontallow functionality to handle these situation.  Otherwise every 
time I add a policy
that has a somewhat global effect on files/dir, I need to change the all 
the file/directory attributes
in the policy.  Has this been discussed previously?

>  
>
>>I am not sure what to do here.  sudo is different then newrole in that
>>it does a fork/exec and the
>>parent exits.  So waiting around for the child to exit in order to set
>>the terminal ownership back is
>>changing the fundamental behavior of sudo.  What is the ramifications
>>of not changing the sid of the
>>controlling terminal?
>>    
>>
>
>If you don't relabel the terminal, then another process operating in the
>old domain (say user_t) can still access the terminal while the program
>in the new domain (say sysadm_t) is running.  Hence, a malicious user or
>program can interfere with a more privileged process being run via sudo.
>  
>
This is a problem since with Sudo you are sharing the same terminal 
between the process that rand sudo
and the sudo process.  So if you change the privs of the terminal one 
process or the other could have
more privs.  I would prefer to leave the terminal with the current privs 
(Usually lower) and make the
application run by sudo change the terminal privs if it has to. 
 (probably seldom).  Any other ideas?

>  
>
>># create run file 
>>type sudo_var_run_t, file_type, sysadmfile;
>>file_type_auto_trans(sudo_t,var_run_t,sudo_var_run_t);
>>allow sudo_t sudo_var_run_t:file create_file_perms;
>>allow sudo_t sudo_var_run_t:dir create_dir_perms;
>>    
>>
>
>The file_type_auto_trans macro includes the necessary allow rules for
>creating files and directories in the type, so you can drop the two
>allow rules above.
>  
>
Done

>  
>
>># sudo
>>/usr/bin/sudo			system_u:object_r:sudo_exec_t
>>/var/run/sudo			system_u:object_r:sudo_var_run_t
>>    
>>
>
>I think you want '/var/run/sudo(/.*)?' as your regular expression, so
>that this type will be applied to the directory and all files beneath
>it.
>
>  
>
Done.

[-- Attachment #2: Type: text/html, Size: 4511 bytes --]

Re: SUDO package

[Stephen Smalley]

On Wed, 2003-04-30 at 11:42, Daniel J Walsh wrote:
> I have a hard time with the previous two.  Just seems to me SELinux
> needs some sort
> of dontallow functionality to handle these situation.  Otherwise every
> time I add a policy 
> that has a somewhat global effect on files/dir, I need to change the
> all the file/directory attributes 
> in the policy.  Has this been discussed previously?

True.  The problem is more severe for exec_type than for the directory
access; IMHO, it isn't too much to ask you to enumerate the major
directory types in which binaries to be executed by sudo might live, and
most (all?) of those types should be part of the basic policy
definition, not package-specific, e.g. bin_t, sbin_t, etc.  You don't
even need to define an attribute for that purpose; you can just list
them in your allow rule, or pull them from a macro definition added to
the global macros.

> This is a problem since with Sudo you are sharing the same terminal
> between the process that rand sudo
> and the sudo process.  So if you change the privs of the terminal one
> process or the other could have 
> more privs.  I would prefer to leave the terminal with the current
> privs (Usually lower) and make the 
> application run by sudo change the terminal privs if it has to. 
> (probably seldom).  Any other ideas?

I'm not clear as to why you can't implement something akin to what
newrole does.  Otherwise, what prevents another process of lower
privilege from arbitrarily accessing the privileged process' terminal?
You can't rely on the DAC protections.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: SUDO package

[Francois Leclerc]

Hello,
what would be the value added of sudo when you have the SELinux ability 
	to set roles
	allocate roles to people
	to set information domains
	to avoid the "root" overpowerful model
	to extend the policies?

Regards,
--FL

-- 
"When entrusted to process, you are obligated to safeguard" 
  from Bob Johnston, CISSP

--
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: SUDO package

[Daniel J Walsh]

Francois Leclerc wrote:

>Hello,
>what would be the value added of sudo when you have the SELinux ability 
>	to set roles
>	allocate roles to people
>	to set information domains
>	to avoid the "root" overpowerful model
>	to extend the policies?
>
>Regards,
>--FL
>
>  
>
SELinux does not remove root, it complements it.  So now you have two 
security models at the same time.
So anything that required root privaledge on your non SELinux system 
still requires root privs on the SELinux
system.  It also requires you to assume a role within SELinux that 
allows you to complete the task.  So a
sudo that allows you to execute commands as root and run under the 
required role would be benificial.

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: SUDO package

[Daniel J Walsh]

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

Stephen Smalley wrote:

>On Wed, 2003-04-30 at 11:42, Daniel J Walsh wrote:
>  
>
>>I have a hard time with the previous two.  Just seems to me SELinux
>>needs some sort
>>of dontallow functionality to handle these situation.  Otherwise every
>>time I add a policy 
>>that has a somewhat global effect on files/dir, I need to change the
>>all the file/directory attributes 
>>in the policy.  Has this been discussed previously?
>>    
>>
>
>True.  The problem is more severe for exec_type than for the directory
>access; IMHO, it isn't too much to ask you to enumerate the major
>directory types in which binaries to be executed by sudo might live, and
>most (all?) of those types should be part of the basic policy
>definition, not package-specific, e.g. bin_t, sbin_t, etc.  You don't
>even need to define an attribute for that purpose; you can just list
>them in your allow rule, or pull them from a macro definition added to
>the global macros.
>  
>
I am still not sure I can do this.  Are you are stating that I would 
have to have an allow rule for
each *exec_t?  Just searching domains/programs I found  > 100 of these 
in the default policy.  
Maybe we are at odds with what sudo can do.  I consider sudo to be a 
shortcut from doing
su,newrole,COMMAND.  So sudo needs all the rights that su/newrole has 
for a particular role.  
Now you might be against this because of the security ramifications, 
which is ok.  But if users
are going to use a SELinux system they are going to expect this behaviour.

>  
>
>>This is a problem since with Sudo you are sharing the same terminal
>>between the process that rand sudo
>>and the sudo process.  So if you change the privs of the terminal one
>>process or the other could have 
>>more privs.  I would prefer to leave the terminal with the current
>>privs (Usually lower) and make the 
>>application run by sudo change the terminal privs if it has to. 
>>(probably seldom).  Any other ideas?
>>    
>>
>
>I'm not clear as to why you can't implement something akin to what
>newrole does.  Otherwise, what prevents another process of lower
>privilege from arbitrarily accessing the privileged process' terminal?
>You can't rely on the DAC protections.
>
>  
>
Ok I just went back and read the code again and it looks like I can 
implement the terminal stuff.
There is a -b option on the sudo command that allows sudo to run in 
background.  Or using job
control you could run the command in background.

sudo -r sysadm_r /usr/bin/PROGRAM &

So what happens to control over the terminal in this situation?

Dan


[-- Attachment #2: Type: text/html, Size: 3171 bytes --]

Re: SUDO package

[Stephen Smalley]

On Wed, 2003-04-30 at 15:06, Daniel J Walsh wrote:
> I am still not sure I can do this.  Are you are stating that I would
> have to have an allow rule for
> each *exec_t?

No, I'm talking about your allow rule for directory access.  An *exec_t
type should never be applied to a directory; it is supposed to be the
type of an entrypoint executable for a domain.  For allowing sudo to
search directories containing binaries, you should just be able to
enumerate the set of directory types, e.g. bin_t, sbin_t, lib_t, etc_t,
etc.  There is no valid reason to use file_type.  Just define a macro in
global macros that enumerates the list of system directories with
authorized programs, and use that macro in your rule.

> So sudo needs all the rights that su/newrole has for a particular
role.  

Right, but we would ultimately like to see the roles pruned down to
least privilege, e.g. you don't really want sysadm_t running arbitrary
executables directly, as that can easily lead to a compromise.

> Ok I just went back and read the code again and it looks like I can
> implement the terminal stuff.
> There is a -b option on the sudo command that allows sudo to run in
> background.  Or using job
> control you could run the command in background.
> 
> sudo -r sysadm_r /usr/bin/PROGRAM &
> 
> So what happens to control over the terminal in this situation?

In that case, the program shouldn't be accessing the terminal, and you
should redirect input and/or output to a file if the program wants to
read any input or write any output.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: SUDO package

[Daniel J Walsh]

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

Stephen Smalley wrote:

>On Wed, 2003-04-30 at 15:06, Daniel J Walsh wrote:
>  
>
>>I am still not sure I can do this.  Are you are stating that I would
>>have to have an allow rule for
>>each *exec_t?
>>    
>>
>
>No, I'm talking about your allow rule for directory access.  An *exec_t
>type should never be applied to a directory; it is supposed to be the
>type of an entrypoint executable for a domain.  For allowing sudo to
>search directories containing binaries, you should just be able to
>enumerate the set of directory types, e.g. bin_t, sbin_t, lib_t, etc_t,
>etc.  There is no valid reason to use file_type.  Just define a macro in
>global macros that enumerates the list of system directories with
>authorized programs, and use that macro in your rule.
>  
>
Ok now I understand.  I can just go with the directory commands from  
can_exec_any rule.
    allow $1 { bin_t sbin_t lib_t etc_t }:dir r_dir_perms;
    allow $1 { bin_t sbin_t }:lnk_file read;

in sudo.te which would satisfy my needs.  Probably do not need lib_t or 
etc_t.
Is that what you had in mind?

>  
>
>>So sudo needs all the rights that su/newrole has for a particular
>>    
>>
>role.  
>
>Right, but we would ultimately like to see the roles pruned down to
>least privilege, e.g. you don't really want sysadm_t running arbitrary
>executables directly, as that can easily lead to a compromise.
>
>  
>
>>Ok I just went back and read the code again and it looks like I can
>>implement the terminal stuff.
>>There is a -b option on the sudo command that allows sudo to run in
>>background.  Or using job
>>control you could run the command in background.
>>
>>sudo -r sysadm_r /usr/bin/PROGRAM &
>>
>>So what happens to control over the terminal in this situation?
>>    
>>
>
>In that case, the program shouldn't be accessing the terminal, and you
>should redirect input and/or output to a file if the program wants to
>read any input or write any output.
>
>  
>
Not exactly an ideal behaviour.  

Consider
sudo -r sysadm_r /bin/sh
would be broken by this.

This is an interesting problem in that two processes want to use the 
terminal at the same time, each with a different security context.  So 
if one is running and is suspended, do we change the security context of 
the terminal to the now running terminal?  Could we do that?

Dan

[-- Attachment #2: Type: text/html, Size: 3032 bytes --]

Re: SUDO package

[Stephen Smalley]

On Wed, 2003-04-30 at 16:13, Daniel J Walsh wrote:
> Ok now I understand.  I can just go with the directory commands from 
> can_exec_any rule.
>     allow $1 { bin_t sbin_t lib_t etc_t }:dir r_dir_perms;
>     allow $1 { bin_t sbin_t }:lnk_file read;
> 
> in sudo.te which would satisfy my needs.  Probably do not need lib_t
> or etc_t.
> Is that what you had in mind?

Yes.  It might be a good idea to hide this set of types in a macro in
the global macros, so that people can install sudo.te on systems that
have different sets of types and sudo.te can just pick up the right set
using the macro.

> Not exactly an ideal behaviour.  
> 
> Consider 
> sudo -r sysadm_r /bin/sh 
> would be broken by this.

If you really mean 'sudo -r sysadm_r /bin/sh' (run in foreground), then
this is no different than newrole.  If you mean 'sudo -b -r sysadm_r
/bin/sh' (backgrounded), then that wouldn't work even aside from SELinux
issues.  It would be suspended immediately when it tried to access tty
input, and any output would be interleaved with the output from the
primary shell, which would make a mess.  Hence, it is already necessary
for either the user or the sudo program to redirect input and output if
backgrounding.  The man page for sudo notes that -b prevents the use of
job control for manipulating the process.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: SUDO package

[Russell Coker]

On Thu, 1 May 2003 05:06, Daniel J Walsh wrote:
> Ok I just went back and read the code again and it looks like I can
> implement the terminal stuff.
> There is a -b option on the sudo command that allows sudo to run in
> background.  Or using job
> control you could run the command in background.
>
> sudo -r sysadm_r /usr/bin/PROGRAM &
>
> So what happens to control over the terminal in this situation?

There was recently a long discussion about this topic on another list (a 
closed list).

The consensus of opinion was that when doing su/sudo type operations to an 
untrusted context on a vanilla Linux kernel then you have to open a new 
pseudo-tty.  On SE Linux changing the type of the pty device is enough.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
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: SUDO package

[Russell Coker]

On Thu, 1 May 2003 01:42, Daniel J Walsh wrote:
> >>I have changed this to
> >>allow sudo_t file_type:dir search
> >>It looks like sudo checks to see if the program exists before it
> >>exec's it.
> >
> >I would prefer that this rule be refined down to a specific list of
> >directory types, or that a new attribute be defined and added to all
> >desired directory types for this purpose.  Again, you want to allow
> >other policy writers to be able to define directory types that cannot be
> >searched by sudo in order to meet their policy goals.
>
> I have a hard time with the previous two.  Just seems to me SELinux
> needs some sort
> of dontallow functionality to handle these situation.  Otherwise every
> time I add a policy
> that has a somewhat global effect on files/dir, I need to change the all
> the file/directory attributes
> in the policy.  Has this been discussed previously?

In this particular case you can always use "sh -c" to run the program in 
question and therefore sudo only needs to be able to execute the shell.

The continual growth of domains and types does require some work to manage.  
But it's been working out OK so far.

> >If you don't relabel the terminal, then another process operating in the
> >old domain (say user_t) can still access the terminal while the program
> >in the new domain (say sysadm_t) is running.  Hence, a malicious user or
> >program can interfere with a more privileged process being run via sudo.
>
> This is a problem since with Sudo you are sharing the same terminal
> between the process that rand sudo
> and the sudo process.  So if you change the privs of the terminal one
> process or the other could have
> more privs.  I would prefer to leave the terminal with the current privs
> (Usually lower) and make the
> application run by sudo change the terminal privs if it has to.
>  (probably seldom).  Any other ideas?

If you have two processes in different security contexts sharing a terminal 
then you are going to have problems.

If you do what newrole does and have exactly one security context with 
permission to write to the terminal then most of the problems disappear.

Incidentally it just occurred to me that we should probably have newrole 
display a message when it exits of the form "ending session of sysadm_r, 
controlling process is now rjc:user_r:user_t" so that the user can recognise 
that it has changed back.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


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