* TTY question @ 2005-02-09 2:15 Ivan Gyurdiev 2005-02-09 3:10 ` Jim McCullough 2005-02-09 13:06 ` Stephen Smalley 0 siblings, 2 replies; 19+ messages in thread From: Ivan Gyurdiev @ 2005-02-09 2:15 UTC (permalink / raw) To: SELinux Hi, I don't quite understand the difference between all the TTY/PTY devices on Linux - could you explain how this works a bit, so that I will know for the future. Which of those rules would be required for stdin/stdout? allow $1_$2_t tty_device_t:chr_file rw_file_perms; allow $1_$2_t $1_tty_device_t:chr_file rw_file_perms; allow $1_$2_t devtty_t:chr_file rw_file_perms; allow $1_$2_t devpts_t:dir r_dir_perms; allow $1_$2_t $1_devpts_t:chr_file rw_file_perms; What about proc permissions required? Can some of those rules be put in a macro of some sort. I see tty rules all over the selinux policy, and perhaps they could be made more consistent with a macro. -- 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] 19+ messages in thread
* Re: TTY question 2005-02-09 2:15 TTY question Ivan Gyurdiev @ 2005-02-09 3:10 ` Jim McCullough 2005-02-09 13:06 ` Stephen Smalley 1 sibling, 0 replies; 19+ messages in thread From: Jim McCullough @ 2005-02-09 3:10 UTC (permalink / raw) To: ivg2; +Cc: SELinux tty refers to the system console or virtual consoles accessable via terminal and keyboard. pty is the designation for any remote connections assignments, ie. ssh user shell. The main purpose is to separate console user from the remote user for accountability. TTY's are not able to generate the high volume load that a PTY would for physical reasons; unless you build a killer keyboard for it. By setting up different rules for tty/pty on a user. Console access could allow extended privileges, where in remote access from another system would block that access. For the rest, I will have to check on that later; or someone else may provide assistance. I am currently stuck in patching windows ...... again. Jim McCullough On Tue, 08 Feb 2005 21:15:34 -0500, Ivan Gyurdiev <ivg2@cornell.edu> wrote: > Hi, > > I don't quite understand the difference between all the TTY/PTY devices > on Linux - could you explain how this works a bit, so that I will know > for the future. > > Which of those rules would be required for stdin/stdout? > > allow $1_$2_t tty_device_t:chr_file rw_file_perms; > allow $1_$2_t $1_tty_device_t:chr_file rw_file_perms; > > allow $1_$2_t devtty_t:chr_file rw_file_perms; > allow $1_$2_t devpts_t:dir r_dir_perms; > allow $1_$2_t $1_devpts_t:chr_file rw_file_perms; > > What about proc permissions required? > > Can some of those rules be put in a macro of some sort. > I see tty rules all over the selinux policy, and perhaps > they could be made more consistent with a macro. > > -- > 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. > -- Jim McCullough -- 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] 19+ messages in thread
* Re: TTY question 2005-02-09 2:15 TTY question Ivan Gyurdiev 2005-02-09 3:10 ` Jim McCullough @ 2005-02-09 13:06 ` Stephen Smalley 2005-02-10 2:02 ` Ivan Gyurdiev 1 sibling, 1 reply; 19+ messages in thread From: Stephen Smalley @ 2005-02-09 13:06 UTC (permalink / raw) To: ivg2; +Cc: SELinux On Tue, 2005-02-08 at 21:15, Ivan Gyurdiev wrote: > Which of those rules would be required for stdin/stdout? Depends on what your stdin/stdout references, naturally. > allow $1_$2_t tty_device_t:chr_file rw_file_perms; This rule shouldn't be necessary. A user domain or associated program domain should only be acting upon a tty that has already been relabeled to one of the $1_tty_device_t types. Only processes that need to act upon ttys that are not necessarily associated with any session should have permissions to tty_device_t itself, e.g. system initialization processes, login, etc. > allow $1_$2_t $1_tty_device_t:chr_file rw_file_perms; This rule allows access to a tty that has already been relabeled for your domain. I think it should only be needed for console sessions, although we typically haven't restricted it in the past for user domains and their associated program domains. > allow $1_$2_t devtty_t:chr_file rw_file_perms; This rule allows access to the /dev/tty device that is always mapped to the controlling terminal of the process if any. Should be allowed. > allow $1_$2_t devpts_t:dir r_dir_perms; > allow $1_$2_t $1_devpts_t:chr_file rw_file_perms; This rule allows access to a pty that has already been relabeled for your domain or that was initially created by your domain. Necessary for X terminals, ssh sessions, etc. Should be allowed. Note that you also need permissions to ptmx_t if your domain needs to actually create ptys. This is typically covered by the can_create_pty macro. > What about proc permissions required? Sorry, what do you mean? Do you mean being able to access /proc/self/fd/n? If so, then you need to be able to search proc_t:dir, proc_t:lnk_file, self:dir, and read self:lnk_file. > Can some of those rules be put in a macro of some sort. > I see tty rules all over the selinux policy, and perhaps > they could be made more consistent with a macro. Possibly. -- 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: TTY question 2005-02-09 13:06 ` Stephen Smalley @ 2005-02-10 2:02 ` Ivan Gyurdiev 2005-02-10 12:46 ` Stephen Smalley 0 siblings, 1 reply; 19+ messages in thread From: Ivan Gyurdiev @ 2005-02-10 2:02 UTC (permalink / raw) To: Stephen Smalley; +Cc: SELinux > in a macro of some sort. >> I see tty rules all over the selinux policy, and perhaps >> they could be made more consistent with a macro. > >Possibly. Maybe something like this: # access_terminal(prefix, domain) access_terminal(` allow $1_$2_t $1_tty_device_t:chr_file rw_file_perms; allow $1_$2_t devtty_t:chr_file rw_file_perms; allow $1_$2_t devpts_t:dir r_dir_perms; allow $1_$2_t $1_devpts_t:chr_file rw_file_perms; ') dnl access_terminal Then use this in: - mplayer_macros - mount_macros - x_client_macros - gpg_macros - gpg_agent macros - su_macros - xauth_macros - irc_macros - chkpwd_macros - cdrecord macros other places? -- 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] 19+ messages in thread
* Re: TTY question 2005-02-10 2:02 ` Ivan Gyurdiev @ 2005-02-10 12:46 ` Stephen Smalley 2005-02-10 13:48 ` Ivan Gyurdiev 0 siblings, 1 reply; 19+ messages in thread From: Stephen Smalley @ 2005-02-10 12:46 UTC (permalink / raw) To: ivg2; +Cc: SELinux On Wed, 2005-02-09 at 21:02, Ivan Gyurdiev wrote: > # access_terminal(prefix, domain) > access_terminal(` > allow $1_$2_t $1_tty_device_t:chr_file rw_file_perms; > allow $1_$2_t devtty_t:chr_file rw_file_perms; > allow $1_$2_t devpts_t:dir r_dir_perms; > allow $1_$2_t $1_devpts_t:chr_file rw_file_perms; > ') dnl access_terminal Why not just: # access_terminal(domain, typeprefix) define(`access_terminal', ` allow $1 $2_tty_device_t:chr_file rw_file_perms; allow $1 devtty_t:chr_file rw_file_perms; allow $1 devpts_t:dir r_dir_perms; allow $1 $2_devpts_t:chr_file rw_file_perms; ') dnl access_terminal Then the usage in e.g. x_client_domain becomes: access_terminal($1_$2_t, $1) whereas elsewhere it may just be: access_terminal($1_t, $1) -- 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: TTY question 2005-02-10 12:46 ` Stephen Smalley @ 2005-02-10 13:48 ` Ivan Gyurdiev 2005-02-10 18:04 ` Ivan Gyurdiev 0 siblings, 1 reply; 19+ messages in thread From: Ivan Gyurdiev @ 2005-02-10 13:48 UTC (permalink / raw) To: Stephen Smalley; +Cc: SELinux >Why not just: ># access_terminal(domain, typeprefix) >define(`access_terminal', ` >allow $1 $2_tty_device_t:chr_file rw_file_perms; >allow $1 devtty_t:chr_file rw_file_perms; >allow $1 devpts_t:dir r_dir_perms; >allow $1 $2_devpts_t:chr_file rw_file_perms; >') dnl access_terminal > >Then the usage in e.g. x_client_domain becomes: >access_terminal($1_$2_t, $1) > >whereas elsewhere it may just be: >access_terminal($1_t, $1) That's better :) I'll write some patches against dwalsh's repository. > -- 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] 19+ messages in thread
* Re: TTY question 2005-02-10 13:48 ` Ivan Gyurdiev @ 2005-02-10 18:04 ` Ivan Gyurdiev 2005-02-10 18:09 ` Stephen Smalley 2005-02-10 19:15 ` Ivan Gyurdiev 0 siblings, 2 replies; 19+ messages in thread From: Ivan Gyurdiev @ 2005-02-10 18:04 UTC (permalink / raw) To: Stephen Smalley; +Cc: SELinux On Thu, 2005-02-10 at 08:48 -0500, Ivan Gyurdiev wrote: >>Why not just: >># access_terminal(domain, typeprefix) >>define(`access_terminal', ` >>allow $1 $2_tty_device_t:chr_file rw_file_perms; >>allow $1 devtty_t:chr_file rw_file_perms; >>allow $1 devpts_t:dir r_dir_perms; >>allow $1 $2_devpts_t:chr_file rw_file_perms; >>') dnl access_terminal >> >>Then the usage in e.g. x_client_domain becomes: >>access_terminal($1_$2_t, $1) >> >>whereas elsewhere it may just be: >>access_terminal($1_t, $1) Should allow $1 privfd:fd use; be in that macro? What does that do? I see it next to the other rules. -- 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] 19+ messages in thread
* Re: TTY question 2005-02-10 18:04 ` Ivan Gyurdiev @ 2005-02-10 18:09 ` Stephen Smalley 2005-02-10 19:15 ` Ivan Gyurdiev 1 sibling, 0 replies; 19+ messages in thread From: Stephen Smalley @ 2005-02-10 18:09 UTC (permalink / raw) To: ivg2; +Cc: SELinux On Thu, 2005-02-10 at 13:04, Ivan Gyurdiev wrote: > Should > allow $1 privfd:fd use; > be in that macro? > > What does that do? > I see it next to the other rules. In order to inherit, receive or use an open descriptor, a domain must have both use permission to the fd (which is labeled based on the domain that performed the open) and appropriate read/write permissions (depending on the fd flags) to the file itself. The privfd attribute was originally to allow marking of certain domains like login and sshd that handled opening of the tty/pty for use in allow rules enabling many other domains to inherit and use the descriptors from these domains. newrole actually closes and re-opens descriptors 0-2 in order to get them into its domain so that subsequent programs only need to inherit from it rather than from the original user domain. However, this proved problematic for su and sudo, and the current policy associates privfd with the user domains as well so that programs run from su'd shells or via sudo are able to inherit the descriptors as well. It would be preferable to introduce a proxy pty into su and sudo similar to what has been done recently by Manoj for run_init in order to properly isolate and protect the different domains. -- 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: TTY question 2005-02-10 18:04 ` Ivan Gyurdiev 2005-02-10 18:09 ` Stephen Smalley @ 2005-02-10 19:15 ` Ivan Gyurdiev 2005-02-10 19:31 ` Stephen Smalley 1 sibling, 1 reply; 19+ messages in thread From: Ivan Gyurdiev @ 2005-02-10 19:15 UTC (permalink / raw) To: Stephen Smalley; +Cc: SELinux [-- Attachment #1: Type: text/plain, Size: 84 bytes --] Does this look reasonable? -- Ivan Gyurdiev <ivg2@cornell.edu> Cornell University [-- Attachment #2: global_macros_patch.diff --] [-- Type: text/x-patch, Size: 548 bytes --] --- global_macros.te 2005-02-10 13:01:08.000000000 -0500 +++ global_macros.new 2005-02-10 13:00:53.000000000 -0500 @@ -156,6 +156,19 @@ r_dir_file($1, locale_t) ') +################################### +# +# access_terminal(domain, typeprefix) +# +# Permissions for accessing the terminal +# +define(`access_terminal', ` +allow $1 $2_tty_device_t:chr_file rw_file_perms; +allow $1 devtty_t:chr_file rw_file_perms; +allow $1 devpts_t:dir r_dir_perms; +allow $1 $2_devpts_t:chr_file rw_file_perms; +') + # # general_proc_read_access(domain) # [-- Attachment #3: program_macros_patch1.diff --] [-- Type: text/x-patch, Size: 14226 bytes --] diff -rua program/cdrecord_macros.te program.new2/cdrecord_macros.te --- program/cdrecord_macros.te 2005-02-10 13:11:06.000000000 -0500 +++ program.new2/cdrecord_macros.te 2005-02-10 13:11:32.000000000 -0500 @@ -17,8 +17,7 @@ allow $1_t $1_cdrecord_t:process signal; # write to the user domain tty. -allow $1_cdrecord_t $1_tty_device_t:chr_file rw_file_perms; -allow $1_cdrecord_t $1_devpts_t:chr_file rw_file_perms; +access_terminal($1_cdrecord_t, $1) allow $1_cdrecord_t privfd:fd use; allow $1_cdrecord_t $1_t:unix_stream_socket { getattr read write ioctl }; diff -rua program/chkpwd_macros.te program.new2/chkpwd_macros.te --- program/chkpwd_macros.te 2005-02-10 13:17:47.000000000 -0500 +++ program.new2/chkpwd_macros.te 2005-02-10 13:18:26.000000000 -0500 @@ -44,8 +44,7 @@ role system_r types sysadm_chkpwd_t; # Write to the user domain tty. -allow $1_chkpwd_t $1_tty_device_t:chr_file rw_file_perms; -allow $1_chkpwd_t $1_devpts_t:chr_file rw_file_perms; +access_terminal($1_chkpwd_t, $1) allow $1_chkpwd_t privfd:fd use; diff -rua program/clamav_macros.te program.new2/clamav_macros.te --- program/clamav_macros.te 2005-02-10 13:42:50.000000000 -0500 +++ program.new2/clamav_macros.te 2005-02-10 13:43:15.000000000 -0500 @@ -48,8 +48,7 @@ clamscan_domain($1) role $1_r types $1_clamscan_t; domain_auto_trans($1_t, clamscan_exec_t, $1_clamscan_t) -allow $1_clamscan_t $1_tty_device_t:chr_file rw_file_perms; -allow $1_clamscan_t $1_devpts_t:chr_file rw_file_perms; +access_terminal($1_clamscan_t, $1) r_dir_file($1_clamscan_t,$1_home_t); r_dir_file($1_clamscan_t,$1_home_dir_t); allow $1_clamscan_t $1_home_t:file r_file_perms; diff -rua program/crontab_macros.te program.new2/crontab_macros.te --- program/crontab_macros.te 2005-02-10 13:41:57.000000000 -0500 +++ program.new2/crontab_macros.te 2005-02-10 13:42:23.000000000 -0500 @@ -87,8 +87,7 @@ # Access terminals. allow $1_crontab_t device_t:dir search; -allow $1_crontab_t $1_tty_device_t:chr_file rw_file_perms; -allow $1_crontab_t $1_devpts_t:chr_file rw_file_perms; +access_terminal($1_crontab_t, $1); allow $1_crontab_t fs_t:filesystem getattr; diff -rua program/gpg_agent_macros.te program.new2/gpg_agent_macros.te --- program/gpg_agent_macros.te 2005-02-10 13:23:26.000000000 -0500 +++ program.new2/gpg_agent_macros.te 2005-02-10 13:23:56.000000000 -0500 @@ -25,9 +25,7 @@ allow $1_gpg_agent_t xdm_t:fd use; # Write to the user domain tty. -allow $1_gpg_agent_t $1_tty_device_t:chr_file rw_file_perms; -allow $1_gpg_agent_t $1_devpts_t:chr_file rw_file_perms; -allow $1_gpg_agent_t devtty_t:chr_file { read write }; +access_terminal($1_gpg_agent_t, $1) # Allow the user shell to signal the gpg-agent program. allow $1_t $1_gpg_agent_t:process { signal sigkill }; diff -rua program/gpg_macros.te program.new2/gpg_macros.te --- program/gpg_macros.te 2005-02-10 13:08:36.000000000 -0500 +++ program.new2/gpg_macros.te 2005-02-10 13:09:32.000000000 -0500 @@ -43,8 +43,7 @@ allow $1_gpg_t self:unix_stream_socket create_stream_socket_perms; allow $1_gpg_t self:tcp_socket create_stream_socket_perms; -allow $1_gpg_t devpts_t:dir search; -allow $1_gpg_t { $1_devpts_t $1_tty_device_t }:chr_file rw_file_perms; +access_terminal($1_gpg_t, $1) ifdef(`gnome-pty-helper.te', `allow $1_gpg_t $1_gph_t:fd use;') # Inherit and use descriptors @@ -84,7 +83,6 @@ } allow $1_gpg_t self:capability { ipc_lock setuid }; -allow $1_gpg_t devtty_t:chr_file rw_file_perms; rw_dir_create_file($1_gpg_t, $1_file_type) allow $1_gpg_t { etc_t usr_t }:dir r_dir_perms; diff -rua program/irc_macros.te program.new2/irc_macros.te --- program/irc_macros.te 2005-02-10 13:09:44.000000000 -0500 +++ program.new2/irc_macros.te 2005-02-10 13:10:38.000000000 -0500 @@ -47,14 +47,13 @@ allow $1_irc_t usr_t:file { getattr read }; +access_terminal($1_irc_t, $1) uses_shlib($1_irc_t) allow $1_irc_t etc_t:file { read getattr }; read_locale($1_irc_t) allow $1_irc_t fs_t:filesystem getattr; allow $1_irc_t var_t:dir search; -allow $1_irc_t devpts_t:dir { getattr read search }; allow $1_irc_t device_t:dir search; -allow $1_irc_t devtty_t:chr_file rw_file_perms; allow $1_irc_t self:unix_stream_socket create_stream_socket_perms; allow $1_irc_t privfd:fd use; allow $1_irc_t proc_t:dir search; @@ -62,10 +61,6 @@ allow $1_irc_t self:dir search; dontaudit $1_irc_t var_run_t:dir search; -# Write to the user domain tty. -allow $1_irc_t $1_tty_device_t:chr_file rw_file_perms; -allow $1_irc_t $1_devpts_t:chr_file rw_file_perms; - # allow utmp access allow $1_irc_t initrc_var_run_t:file read; dontaudit $1_irc_t initrc_var_run_t:file lock; diff -rua program/java_macros.te program.new2/java_macros.te --- program/java_macros.te 2005-02-10 13:11:54.000000000 -0500 +++ program.new2/java_macros.te 2005-02-10 13:14:06.000000000 -0500 @@ -86,6 +86,7 @@ legacy_domain($1_java) +access_terminal($1_java_t, $2) uses_shlib($1_java_t) read_locale($1_java_t) rw_dir_file($1_java_t, $1_rw_t) @@ -108,9 +109,6 @@ dontaudit $1_java_t fonts_t:file execute; dontaudit $1_java_t sound_device_t:chr_file execute; -dontaudit $1_java_t $2_devpts_t:chr_file { read write }; -dontaudit $1_java_t sysadm_devpts_t:chr_file { read write }; -dontaudit $1_java_t devtty_t:chr_file { read write }; dontaudit $1_java_t tmpfs_t:file { execute read write }; dontaudit $1_java_t $1_rw_t:file { execute setattr }; diff -rua program/lockdev_macros.te program.new2/lockdev_macros.te --- program/lockdev_macros.te 2005-02-10 13:44:53.000000000 -0500 +++ program.new2/lockdev_macros.te 2005-02-10 13:45:26.000000000 -0500 @@ -36,7 +36,7 @@ allow $1_lockdev_t device_t:dir search; allow $1_lockdev_t null_device_t:chr_file rw_file_perms; -allow $1_lockdev_t { $1_tty_device_t $1_devpts_t }:chr_file rw_file_perms; +access_terminal($1_lockdev_t, $1) dontaudit $1_lockdev_t root_t:dir search; uses_shlib($1_lockdev_t) diff -rua program/lpr_macros.te program.new2/lpr_macros.te --- program/lpr_macros.te 2005-02-10 13:27:15.000000000 -0500 +++ program.new2/lpr_macros.te 2005-02-10 13:27:40.000000000 -0500 @@ -64,8 +64,7 @@ allow $1_lpr_t device_t:dir search; # Access the terminal. -allow $1_lpr_t $1_tty_device_t:chr_file rw_file_perms; -allow $1_lpr_t $1_devpts_t:chr_file rw_file_perms; +access_terminal($1_lpr_t, $1) # Inherit and use descriptors from gnome-pty-helper. ifdef(`gnome-pty-helper.te', `allow $1_lpr_t $1_gph_t:fd use;') diff -rua program/mount_macros.te program.new2/mount_macros.te --- program/mount_macros.te 2005-02-10 13:28:05.000000000 -0500 +++ program.new2/mount_macros.te 2005-02-10 13:28:35.000000000 -0500 @@ -63,8 +63,7 @@ allow $2_t sbin_t:lnk_file read; # Access the terminal. -allow $2_t $1_tty_device_t:chr_file { getattr read write ioctl }; -allow $2_t $1_devpts_t:chr_file { getattr read write }; +access_terminal($2_t, $1) ifdef(`gnome-pty-helper.te', `allow $2_t $1_gph_t:fd use;') allow $2_t var_t:dir search; allow $2_t var_run_t:dir search; diff -rua program/mplayer_macros.te program.new2/mplayer_macros.te --- program/mplayer_macros.te 2005-02-10 13:39:27.000000000 -0500 +++ program.new2/mplayer_macros.te 2005-02-10 13:41:28.000000000 -0500 @@ -40,19 +40,11 @@ allow $1_$2_t sysctl_kernel_t:dir search; allow $1_$2_t sysctl_kernel_t:file { getattr read }; -# allow ps +# Allow ps, shared libs, locale, terminal access can_ps($1_t, $1_$2_t) - -# uses shared libraries uses_shlib($1_$2_t) - -# localization read_locale($1_$2_t) - -# Access the terminal. -allow $1_$2_t devpts_t:dir { search }; -allow $1_$2_t $1_tty_device_t:chr_file rw_file_perms; -allow $1_$2_t $1_devpts_t:chr_file rw_file_perms; +access_terminal($1_$2_t, $1) # Required for win32 binary loader allow $1_$2_t zero_device_t:chr_file { read write execute }; @@ -64,8 +56,6 @@ allow $1_$2_t zero_device_t:chr_file execmod; } - - # Access to DVD/CD/V4L allow $1_$2_t device_t:dir r_dir_perms; allow $1_$2_t device_t:lnk_file { getattr read }; diff -rua program/mta_macros.te program.new2/mta_macros.te --- program/mta_macros.te 2005-02-10 13:24:30.000000000 -0500 +++ program.new2/mta_macros.te 2005-02-10 13:26:00.000000000 -0500 @@ -87,10 +87,9 @@ allow mta_user_agent $1_tmp_t:file { read getattr }; -allow mta_user_agent { $1_devpts_t $1_tty_device_t }:chr_file { getattr read write }; - # Write to the user domain tty. -allow $1_mail_t { $1_tty_device_t $1_devpts_t devtty_t }:chr_file rw_file_perms; +access_terminal(mta_user_agent, $1) +access_terminal($1_mail_t, $1) # Inherit and use descriptors from gnome-pty-helper. ifdef(`gnome-pty-helper.te', `allow $1_mail_t $1_gph_t:fd use;') diff -rua program/slocate_macros.te program.new2/slocate_macros.te --- program/slocate_macros.te 2005-02-10 13:49:06.000000000 -0500 +++ program.new2/slocate_macros.te 2005-02-10 13:49:34.000000000 -0500 @@ -47,10 +47,7 @@ allow $1_t $1_locate_t:process signal; uses_shlib($1_locate_t) - -# Write to the user domain tty. -allow $1_locate_t $1_tty_device_t:chr_file rw_file_perms; -allow $1_locate_t $1_devpts_t:chr_file rw_file_perms; +access_terminal($1_locate_t, $1) allow $1_locate_t { home_root_t $1_home_dir_t $1_file_type }:dir { getattr search }; allow $1_locate_t $1_file_type:{ file lnk_file } { getattr read }; diff -rua program/ssh_agent_macros.te program.new2/ssh_agent_macros.te --- program/ssh_agent_macros.te 2005-02-10 13:49:59.000000000 -0500 +++ program.new2/ssh_agent_macros.te 2005-02-10 13:50:36.000000000 -0500 @@ -27,9 +27,7 @@ allow $1_ssh_agent_t privfd:fd use; # Write to the user domain tty. -allow $1_ssh_agent_t $1_tty_device_t:chr_file rw_file_perms; -allow $1_ssh_agent_t $1_devpts_t:chr_file rw_file_perms; -allow $1_ssh_agent_t devtty_t:chr_file { read write }; +access_terminal($1_ssh_agent_t, $1) # Allow the user shell to signal the ssh program. allow $1_t $1_ssh_agent_t:process signal; diff -rua program/ssh_macros.te program.new2/ssh_macros.te --- program/ssh_macros.te 2005-02-10 13:43:48.000000000 -0500 +++ program.new2/ssh_macros.te 2005-02-10 13:44:30.000000000 -0500 @@ -52,9 +52,6 @@ base_file_read_access($1_ssh_t) -# Read the devpts root directory. -allow $1_ssh_t devpts_t:dir r_dir_perms; - # Read /var. allow $1_ssh_t var_t:dir r_dir_perms; allow $1_ssh_t var_t:notdevfile_class_set r_file_perms; @@ -77,8 +74,7 @@ # Read /dev/urandom. allow $1_ssh_t urandom_device_t:chr_file r_file_perms; -# Read and write /dev/tty and /dev/null. -allow $1_ssh_t devtty_t:chr_file rw_file_perms; +# Read and write /dev/null. allow $1_ssh_t { null_device_t zero_device_t }:chr_file rw_file_perms; # Grant permissions needed to create TCP and UDP sockets and @@ -127,8 +123,7 @@ ifdef(`gnome-pty-helper.te', `allow $1_ssh_t $1_gph_t:fd use;') # Write to the user domain tty. -allow $1_ssh_t $1_tty_device_t:chr_file rw_file_perms; -allow $1_ssh_t $1_devpts_t:chr_file rw_file_perms; +access_terminal($1_ssh_t, $1) # Allow the user shell to signal the ssh program. allow $1_t $1_ssh_t:process signal; diff -rua program/su_macros.te program.new2/su_macros.te --- program/su_macros.te 2005-02-09 19:57:11.000000000 -0500 +++ program.new2/su_macros.te 2005-02-10 13:47:32.000000000 -0500 @@ -99,7 +99,7 @@ } # Relabel ttys and ptys. -allow $1_su_t { device_t devpts_t }:dir { getattr read search }; +allow $1_su_t device_t:dir { getattr read search }; allow $1_su_t { ttyfile ptyfile }:chr_file { relabelfrom relabelto }; # Close and re-open ttys and ptys to get the fd into the correct domain. @@ -121,9 +121,7 @@ role $1_r types $1_su_t; # Write to the user domain tty. -allow $1_su_t $1_tty_device_t:chr_file rw_file_perms; -allow $1_su_t $1_devpts_t:chr_file rw_file_perms; -allow $1_su_t { sysadm_tty_device_t sysadm_devpts_t }:chr_file { getattr ioctl }; +access_terminal($1_su_t, $1) allow $1_su_t { home_root_t $1_home_dir_t }:dir search; allow $1_su_t $1_home_t:file create_file_perms; diff -rua program/uml_macros.te program.new2/uml_macros.te --- program/uml_macros.te 2005-02-10 13:21:39.000000000 -0500 +++ program.new2/uml_macros.te 2005-02-10 13:22:22.000000000 -0500 @@ -110,7 +110,6 @@ dontaudit $1_uml_t initrc_var_run_t:file { write lock }; allow $1_uml_t device_t:dir search; -allow $1_uml_t devtty_t:chr_file rw_file_perms; allow $1_uml_t self:unix_stream_socket create_stream_socket_perms; allow $1_uml_t self:unix_dgram_socket create_socket_perms; allow $1_uml_t privfd:fd use; @@ -121,8 +120,7 @@ allow $1_uml_t proc_t:file write; # Write to the user domain tty. -allow $1_uml_t $1_tty_device_t:chr_file rw_file_perms; -allow $1_uml_t $1_devpts_t:chr_file rw_file_perms; +access_terminal($1_uml_t, $1) # access config files allow $1_uml_t home_root_t:dir search; diff -rua program/xauth_macros.te program.new2/xauth_macros.te --- program/xauth_macros.te 2005-02-10 13:21:09.000000000 -0500 +++ program.new2/xauth_macros.te 2005-02-10 13:21:26.000000000 -0500 @@ -66,8 +66,7 @@ allow $1_xauth_t fs_t:filesystem getattr; # Write to the user domain tty. -allow $1_xauth_t $1_tty_device_t:chr_file rw_file_perms; -allow $1_xauth_t $1_devpts_t:chr_file rw_file_perms; +access_terminal($1_xauth_t, $1) # Scan /var/run. allow $1_xauth_t var_t:dir search; diff -rua program/x_client_macros.te program.new2/x_client_macros.te --- program/x_client_macros.te 2005-02-10 13:14:27.000000000 -0500 +++ program.new2/x_client_macros.te 2005-02-10 13:16:57.000000000 -0500 @@ -57,9 +57,9 @@ allow $1_$2_t etc_runtime_t:file { getattr read }; allow $1_$2_t etc_t:lnk_file read; allow $1_$2_t fs_t:filesystem getattr; +access_terminal($1_$2_t, $1) read_locale($1_$2_t) r_dir_file($1_$2_t, readable_t) -allow $1_$2_t devtty_t:chr_file { read write }; allow $1_$2_t proc_t:dir search; allow $1_$2_t proc_t:lnk_file read; allow $1_$2_t self:dir search; @@ -143,11 +143,6 @@ can_tcp_connect($1_$2_t, sshd_t) ') -# Access the terminal. -allow $1_$2_t devpts_t:dir search; -allow $1_$2_t $1_tty_device_t:chr_file rw_file_perms; -allow $1_$2_t $1_devpts_t:chr_file rw_file_perms; - # Read the home directory, e.g. for .Xauthority and to get to config files allow $1_$2_t home_root_t:dir { search getattr }; file_type_auto_trans($1_$2_t, $1_home_dir_t, $1_$2_rw_t) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: TTY question 2005-02-10 19:15 ` Ivan Gyurdiev @ 2005-02-10 19:31 ` Stephen Smalley 2005-02-10 20:29 ` Ivan Gyurdiev 0 siblings, 1 reply; 19+ messages in thread From: Stephen Smalley @ 2005-02-10 19:31 UTC (permalink / raw) To: ivg2; +Cc: SELinux On Thu, 2005-02-10 at 14:15, Ivan Gyurdiev wrote: > Does this look reasonable? - The patch removes a rule giving $1_su_t certain permissions to sysadm tty/pty types, likely requires testing to verify that this doesn't present a problem for proper handling and subsequent restoration of the label when the su'd shell exits. - It might be desirable to reduce the permissions allowed by the macro from rw_file_perms to just { read write getattr }, as I see that many domains were only being given those permissions previously. Likewise, might want to reduce r_dir_perms down to just { read search getattr }. Otherwise, looks sane to me (subject to testing, of course). -- 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: TTY question 2005-02-10 19:31 ` Stephen Smalley @ 2005-02-10 20:29 ` Ivan Gyurdiev 2005-02-10 20:31 ` Stephen Smalley 0 siblings, 1 reply; 19+ messages in thread From: Ivan Gyurdiev @ 2005-02-10 20:29 UTC (permalink / raw) To: Stephen Smalley; +Cc: SELinux On Thu, 2005-02-10 at 14:31 -0500, Stephen Smalley wrote: >On Thu, 2005-02-10 at 14:15, Ivan Gyurdiev wrote: >> Does this look reasonable? > >- The patch removes a rule giving $1_su_t certain permissions to sysadm >tty/pty types, There's su_domain($1) in admin_macros.te, so access_terminal(sysadm_su_t, sysadm_t) should be invoked. > likely requires testing to verify that this doesn't >present a problem for proper handling and subsequent restoration of the >label when the su'd shell exits. >- It might be desirable to reduce the permissions allowed by the macro >from rw_file_perms to just { read write getattr }, as I see that many >domains were only being given those permissions previously. Likewise, >might want to reduce r_dir_perms down to just { read search getattr }. Changed, but it creates problems: audit(1108067222.381:0): avc: denied { ioctl } for pid=5435 exe=/bin/su path=/dev/pts/1 dev=devpts ino=3 scontext=root:sysadm_r:sysadm_su_t tcontext=root:object_r:sysadm_devpts_t tclass=chr_file Rebooting to see if I get denials during boot sequence... -- 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] 19+ messages in thread
* Re: TTY question 2005-02-10 20:29 ` Ivan Gyurdiev @ 2005-02-10 20:31 ` Stephen Smalley 2005-02-10 21:12 ` Ivan Gyurdiev 0 siblings, 1 reply; 19+ messages in thread From: Stephen Smalley @ 2005-02-10 20:31 UTC (permalink / raw) To: ivg2; +Cc: SELinux On Thu, 2005-02-10 at 15:29, Ivan Gyurdiev wrote: > There's su_domain($1) in admin_macros.te, so > access_terminal(sysadm_su_t, sysadm_t) should be invoked. Yes, but that doesn't help if you are starting in user_t (if user_canbe_sysadm is enabled) or staff_t. There was a specific rule removed by the patch between $1_su_t and sysadm_*_t, not just $1_*_t. Not clear whether those permissions were truly necessary or not, but su does need to be able to restore the label on the tty/pty when the su'd shell exits. > Changed, but it creates problems: > > audit(1108067222.381:0): avc: denied { ioctl } for pid=5435 > exe=/bin/su path=/dev/pts/1 dev=devpts ino=3 > scontext=root:sysadm_r:sysadm_su_t > tcontext=root:object_r:sysadm_devpts_t tclass=chr_file Yes, but the question is whether this is always needed for all domains using this macro or whether we can selectively allow it for certain domains. A diff of the generated policy before and after showed that many domains only had getattr read write prior to the patch. -- 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: TTY question 2005-02-10 20:31 ` Stephen Smalley @ 2005-02-10 21:12 ` Ivan Gyurdiev 2005-02-10 21:16 ` Stephen Smalley 0 siblings, 1 reply; 19+ messages in thread From: Ivan Gyurdiev @ 2005-02-10 21:12 UTC (permalink / raw) To: Stephen Smalley; +Cc: SELinux On Thu, 2005-02-10 at 15:31 -0500, Stephen Smalley wrote: >On Thu, 2005-02-10 at 15:29, Ivan Gyurdiev wrote: >> There's su_domain($1) in admin_macros.te, so >> access_terminal(sysadm_su_t, sysadm_t) should be invoked. > >Yes, but that doesn't help if you are starting in user_t (if >user_canbe_sysadm is enabled) or staff_t. There was a specific rule >removed by the patch between $1_su_t and sysadm_*_t, not just $1_*_t. >Not clear whether those permissions were truly necessary or not, but su >does need to be able to restore the label on the tty/pty when the su'd >shell exits. It's restored fine. /dev/pts/x goes to sysadm_devpts_t after su and back to user_devpts_t after exit. There are no denials. >> Changed, but it creates problems: >> >> audit(1108067222.381:0): avc: denied { ioctl } for pid=5435 >> exe=/bin/su path=/dev/pts/1 dev=devpts ino=3 >> scontext=root:sysadm_r:sysadm_su_t >> tcontext=root:object_r:sysadm_devpts_t tclass=chr_file > >Yes, but the question is whether this is always needed for all domains >using this macro or whether we can selectively allow it for certain >domains. A diff of the generated policy before and after showed that >many domains only had getattr read write prior to the patch. Actually the vast majority of domains had rw_file_perms allowed. On the other hand I haven't gotten any denials so far other than an ioctl for su (which makes the system unusable). The permissions you want to remove are { append lock ioctl } on chr_file, and { lock ioctl } on dir. What should I do? ioctl could be allowed for su for now, and then if denials show up it could be reverted to rw_perms in the macro. P.S. The java policy had dontaudit tty rules and not allow. I changed them by accident. Should they be changed back, or do you think allow is correct? > -- 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] 19+ messages in thread
* Re: TTY question 2005-02-10 21:12 ` Ivan Gyurdiev @ 2005-02-10 21:16 ` Stephen Smalley 2005-02-10 21:33 ` Ivan Gyurdiev 2005-02-10 21:39 ` Ivan Gyurdiev 0 siblings, 2 replies; 19+ messages in thread From: Stephen Smalley @ 2005-02-10 21:16 UTC (permalink / raw) To: ivg2; +Cc: SELinux On Thu, 2005-02-10 at 16:12, Ivan Gyurdiev wrote: > It's restored fine. > /dev/pts/x goes to sysadm_devpts_t after su > and back to user_devpts_t after exit. > > There are no denials. Ok, good. > The permissions you want to remove are { append lock ioctl } on > chr_file, and { lock ioctl } on dir. > > What should I do? ioctl could be allowed for su for now, and then if > denials show up it could be reverted to rw_perms in the macro. I'd reduce the permissions in the macro for now, and just give ioctl to su via a separate allow rule. > P.S. The java policy had dontaudit tty rules and not allow. > I changed them by accident. Should they be changed back, or > do you think allow is correct? I don't have that policy in our tree. Is it for the java plugin run from mozilla or for java run by a user domain? If the former, likely want dontaudit. If the latter, likely want/need allow. -- 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: TTY question 2005-02-10 21:16 ` Stephen Smalley @ 2005-02-10 21:33 ` Ivan Gyurdiev 2005-02-10 22:27 ` Daniel J Walsh 2005-02-10 21:39 ` Ivan Gyurdiev 1 sibling, 1 reply; 19+ messages in thread From: Ivan Gyurdiev @ 2005-02-10 21:33 UTC (permalink / raw) To: Stephen Smalley; +Cc: SELinux >> P.S. The java policy had dontaudit tty rules and not allow. >> I changed them by accident. Should they be changed back, or >> do you think allow is correct? > >I don't have that policy in our tree. Is it for the java plugin run >from mozilla or for java run by a user domain? If the former, likely >want dontaudit. If the latter, likely want/need allow. Well, it's the one Daniel Walsh has been writing, and he said it's for a java plugin, so I guess I'll revert to dontaudit for now. Thank you for the input - will send patches against FC. > -- 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] 19+ messages in thread
* Re: TTY question 2005-02-10 21:33 ` Ivan Gyurdiev @ 2005-02-10 22:27 ` Daniel J Walsh 0 siblings, 0 replies; 19+ messages in thread From: Daniel J Walsh @ 2005-02-10 22:27 UTC (permalink / raw) To: ivg2; +Cc: Stephen Smalley, SELinux Ivan Gyurdiev wrote: >>>P.S. The java policy had dontaudit tty rules and not allow. >>>I changed them by accident. Should they be changed back, or >>>do you think allow is correct? >>> >>> >>I don't have that policy in our tree. Is it for the java plugin run >> >> >>from mozilla or for java run by a user domain? If the former, likely > > >>want dontaudit. If the latter, likely want/need allow. >> >> > >Well, it's the one Daniel Walsh has been writing, and he said it's for >a java plugin, so I guess I'll revert to dontaudit for now. > > >Thank you for the input - will send patches against FC. > > Java policy is just for running from mozilla. IE Plugin, A full java policy as I stated before does not make much sense. -- 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] 19+ messages in thread
* Re: TTY question 2005-02-10 21:16 ` Stephen Smalley 2005-02-10 21:33 ` Ivan Gyurdiev @ 2005-02-10 21:39 ` Ivan Gyurdiev 2005-02-10 21:41 ` Stephen Smalley 1 sibling, 1 reply; 19+ messages in thread From: Ivan Gyurdiev @ 2005-02-10 21:39 UTC (permalink / raw) To: Stephen Smalley; +Cc: SELinux On Thu, 2005-02-10 at 16:16 -0500, Stephen Smalley wrote: >On Thu, 2005-02-10 at 16:12, Ivan Gyurdiev wrote: >> It's restored fine. >> /dev/pts/x goes to sysadm_devpts_t after su >> and back to user_devpts_t after exit. >> >> There are no denials. > >Ok, good. Actually here's probably why: it's duplicated in su_mini_domain: # Close and re-open ttys and ptys to get the fd into the correct domain. allow $1_su_t { ttyfile ptyfile }:chr_file { read write }; So it's all good. -- 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] 19+ messages in thread
* Re: TTY question 2005-02-10 21:39 ` Ivan Gyurdiev @ 2005-02-10 21:41 ` Stephen Smalley 0 siblings, 0 replies; 19+ messages in thread From: Stephen Smalley @ 2005-02-10 21:41 UTC (permalink / raw) To: ivg2; +Cc: SELinux On Thu, 2005-02-10 at 16:39, Ivan Gyurdiev wrote: > Actually here's probably why: > it's duplicated in su_mini_domain: > > # Close and re-open ttys and ptys to get the fd into the correct domain. > allow $1_su_t { ttyfile ptyfile }:chr_file { read write }; > > So it's all good. That likely isn't necessary presently, as su/pam_selinux no longer does that (it caused breakage; we'd have to directly patch su to do it right, and at that point, we'd likely just introduce a proxy pty). -- 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* tty question @ 2004-05-03 18:51 Dvorkin 0 siblings, 0 replies; 19+ messages in thread From: Dvorkin @ 2004-05-03 18:51 UTC (permalink / raw) To: linux-kernel I'm trying to write LKM that acts like TTY. i'm using tty_register_driver(...) to register my virtual device and it's functions... there are open/close/write/ioctl functions, but what function acts as READ in struct tty_driver ? I'm sorry for the stupid question... -- WBR, Dvorkin ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2005-02-10 22:32 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-02-09 2:15 TTY question Ivan Gyurdiev 2005-02-09 3:10 ` Jim McCullough 2005-02-09 13:06 ` Stephen Smalley 2005-02-10 2:02 ` Ivan Gyurdiev 2005-02-10 12:46 ` Stephen Smalley 2005-02-10 13:48 ` Ivan Gyurdiev 2005-02-10 18:04 ` Ivan Gyurdiev 2005-02-10 18:09 ` Stephen Smalley 2005-02-10 19:15 ` Ivan Gyurdiev 2005-02-10 19:31 ` Stephen Smalley 2005-02-10 20:29 ` Ivan Gyurdiev 2005-02-10 20:31 ` Stephen Smalley 2005-02-10 21:12 ` Ivan Gyurdiev 2005-02-10 21:16 ` Stephen Smalley 2005-02-10 21:33 ` Ivan Gyurdiev 2005-02-10 22:27 ` Daniel J Walsh 2005-02-10 21:39 ` Ivan Gyurdiev 2005-02-10 21:41 ` Stephen Smalley -- strict thread matches above, loose matches on Subject: below -- 2004-05-03 18:51 tty question Dvorkin
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.