tty question

tty question

[Dvorkin]

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

TTY question

[Ivan Gyurdiev]

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.

Re: TTY question

[Jim McCullough]

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.

Re: TTY question

[Stephen Smalley]

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.

Re: TTY question

[Ivan Gyurdiev]

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

Re: TTY question

[Stephen Smalley]

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.

Re: TTY question

[Ivan Gyurdiev]

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

Re: TTY question

[Ivan Gyurdiev]

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.

Re: TTY question

[Stephen Smalley]

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.

Re: TTY question

[Ivan Gyurdiev]

[-- 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)

Re: TTY question

[Stephen Smalley]

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.

Re: TTY question

[Ivan Gyurdiev]

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.

Re: TTY question

[Stephen Smalley]

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.

Re: TTY question

[Ivan Gyurdiev]

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.

Re: TTY question

[Stephen Smalley]

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.

Re: TTY question

[Ivan Gyurdiev]

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

Re: TTY question

[Ivan Gyurdiev]

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.

Re: TTY question

[Stephen Smalley]

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.

Re: TTY question

[Daniel J Walsh]

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.