Some minor thoughts on syntax/semantics

Some minor thoughts on syntax/semantics

[Dale Amon]

There seems to be a bit of mental gymnastics involved
in reading allow statements. They are written like this:

allow  this_t   that_t:class  {this that and the other};

but semantically we want to think of it as:

"Allow a domain this_t to do {this that and the other} 
from something like that_t:class"

So I wonder if there was a reason you didn't go for
a similar syntax, eg

allow  this_t {this that and the other}  that_t:class;

Just curious.

-- 
------------------------------------------------------
       IN MY NAME:            Dale Amon, CEO/MD
  No Mushroom clouds over     Islandone Society
    London and New York.      www.islandone.org
------------------------------------------------------

--
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: Some minor thoughts on syntax/semantics

[Brian May]

On Tue, Sep 23, 2003 at 04:09:27PM +0100, Dale Amon wrote:
> There seems to be a bit of mental gymnastics involved
> in reading allow statements. They are written like this:
> 
> allow  this_t   that_t:class  {this that and the other};
> 
> but semantically we want to think of it as:
> 
> "Allow a domain this_t to do {this that and the other} 
> from something like that_t:class"
> 
> So I wonder if there was a reason you didn't go for
> a similar syntax, eg
> 
> allow  this_t {this that and the other}  that_t:class;

Personally I read it as "Allow <src_type> to access <dest_type> using
these <operations>."

I consider this similar to object orientated style with C++, Java,
Perl, or PHP languages where you say:

object->method

Not that I am justifying the decisions behind the current syntax (I
wasn't involved), but I don't have any problem with current order of the
parameters.
-- 
Brian May <bam@snoopy.apana.org.au>

--
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: Some minor thoughts on syntax/semantics

[Russell Coker]

On Wed, 24 Sep 2003 01:09, Dale Amon wrote:
> There seems to be a bit of mental gymnastics involved
> in reading allow statements. They are written like this:
>
> allow  this_t   that_t:class  {this that and the other};
>
> but semantically we want to think of it as:
>
> "Allow a domain this_t to do {this that and the other}
> from something like that_t:class"
>
> So I wonder if there was a reason you didn't go for
> a similar syntax, eg
>
> allow  this_t {this that and the other}  that_t:class;

The current syntax seems intuitive enough to me.  I learnt how to write SE 
policy by reading the existing policy and playing with it and it never seemed 
difficult.

Brian's point about C++ etc seems valid.

I'm in the same situation as Brian in that I wasn't involved when it was 
designed, and therefore I guess I'm slightly biased towards the current 
method having worked with it for years and not used any alternative.

Now when I think about what Unix programs do I think in SE policy.

-- 
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: Some minor thoughts on syntax/semantics

[Dale Amon]

On Wed, Sep 24, 2003 at 11:34:55PM +1000, Russell Coker wrote:
> The current syntax seems intuitive enough to me.  I learnt how to write SE 
> policy by reading the existing policy and playing with it and it never seemed 
> difficult.

The reason I brought it up was that Steve's paper states things
in English exactly the way I did, which means you have to reverse
the second two elements in your mind when reading the descriptions.

I can't say that I really see anything about the language that is
object oriented per-se, it looks like a very simple declarative
configuration language to me. C++ it ain't. (thank god) :-)

Just some thoughts after coming back to it after over a year
and a half...


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

ssh policy hassles

[Dale Amon]

avc:  denied  { search } for  pid=654 exe=/usr/sbin/sshd dev=sda2 ino=903169 scontext=system_u:system_r:sshd_t tcontext=system_u:object_r:var_lib_t tclass=dir

Can anyone think of a reason why an sshd would try to search
/var/lib upon an incoming ssh connection? /var/lib is
not in the source code, it's not in the config files...
The only thing I see that looks even vaguely like a possible 
target there is /var/lib/urandom.




--
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: ssh policy hassles

[Kerry Thompson]

Dale Amon said:
> avc:  denied  { search } for  pid=654 exe=/usr/sbin/sshd dev=sda2
> ino=903169 scontext=system_u:system_r:sshd_t
> tcontext=system_u:object_r:var_lib_t tclass=dir
>
> Can anyone think of a reason why an sshd would try to search
> /var/lib upon an incoming ssh connection? /var/lib is
> not in the source code, it's not in the config files...
> The only thing I see that looks even vaguely like a possible
> target there is /var/lib/urandom.
>

It might be in /etc/passwd for privsep, and new connections try to look
for something there. From my RedHat 9 box:

$ grep ssh /etc/passwd
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
$ ls -l /var/empty
total 0
$


-- 
Kerry Thompson, CCNA CISSP
Information Systems Security Consultant
http://www.crypt.gen.nz  kerry@crypt.gen.nz


--
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: ssh policy hassles

[Russell Coker]

On Thu, 25 Sep 2003 06:31, Dale Amon wrote:
> avc:  denied  { search } for  pid=654 exe=/usr/sbin/sshd dev=sda2
> ino=903169 scontext=system_u:system_r:sshd_t
> tcontext=system_u:object_r:var_lib_t tclass=dir

What is in /etc/passwd for the sshd account?

> The only thing I see that looks even vaguely like a possible
> target there is /var/lib/urandom.

That's not something that sshd should be accessing.

Does sshd work well without the access?  If so then a dontaudit rule is in 
order.

> Okay, now I've still one more, and this one is really
> confusing because ino=48726022 seems not to exist:
>
> 	48726022        <inode not found>
>
> I half wonder if I've got a bad link somewhere. It would
> be easy enough to add an allow for this, but I'd like
> to figure out why rather than blindly add things.
>
> avc:  denied  { read } for  pid=743 exe=/usr/sbin/sshd dev= ino=48726022
> scontext=system_u:system_r:sshd_t tcontext=system_u:system_r:sshd_t
> tclass=lnk_file

When you see that a domain is listed as the target (sshd_t is the tcontext) 
for a file/dir/link_file access then it's an access to /proc/pid .  In this 
case it's probably access to /proc/self/cwd or something.  In my latest 
policy I have the following:
dontaudit sshd_t proc_t:dir search;

Nothing else is permitted under /proc.

-- 
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: ssh policy hassles

[Dale Amon]

On Thu, Sep 25, 2003 at 01:32:53PM +1000, Russell Coker wrote:
> On Thu, 25 Sep 2003 06:31, Dale Amon wrote:
> > avc:  denied  { search } for  pid=654 exe=/usr/sbin/sshd dev=sda2
> > ino=903169 scontext=system_u:system_r:sshd_t
> > tcontext=system_u:object_r:var_lib_t tclass=dir
> 
> What is in /etc/passwd for the sshd account?
> 
> > The only thing I see that looks even vaguely like a possible
> > target there is /var/lib/urandom.
> 
> That's not something that sshd should be accessing.
> 
> Does sshd work well without the access?  If so then a dontaudit rule is in 
> order.
> 
> > Okay, now I've still one more, and this one is really
> > confusing because ino=48726022 seems not to exist:
> >
> > 	48726022        <inode not found>
> >
> > I half wonder if I've got a bad link somewhere. It would
> > be easy enough to add an allow for this, but I'd like
> > to figure out why rather than blindly add things.
> >
> > avc:  denied  { read } for  pid=743 exe=/usr/sbin/sshd dev= ino=48726022
> > scontext=system_u:system_r:sshd_t tcontext=system_u:system_r:sshd_t
> > tclass=lnk_file
> 
> When you see that a domain is listed as the target (sshd_t is the tcontext) 
> for a file/dir/link_file access then it's an access to /proc/pid .  In this 
> case it's probably access to /proc/self/cwd or something.  In my latest 
> policy I have the following:
> dontaudit sshd_t proc_t:dir search;

I'll try adding that. However something is still very wrong here. From
log/auth on the selinux host when in enforcing mode (yes it works when not):

 Sep 25 11:40:26 cvs ssh(pam_unix)[394]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=10.0.0.25  user=root
 Sep 25 11:40:32 cvs sshd[394]: Accepted password for root from 10.0.0.25 port 1160 ssh2
 Sep 25 11:40:32 cvs sshd[394]: default security context is root:staff_r:staff_t
 Sep 25 11:40:32 cvs sshd[394]: setting tty /dev/pts/2 context to root:object_r:staff_devpts_t
 Sep 25 11:40:32 cvs sshd[394]: fatal: chown(/dev/pts/2, 0, 5) failed: Permission denied
 Sep 25 11:40:32 cvs sshd[394]: error: chown /dev/pts/2 0 0 failed: Permission denied
 Sep 25 11:40:32 cvs sshd[394]: error: chmod /dev/pts/2 0666 failed: Permission denied

and these are the corresponding avcs:

 avc:  denied  { read } for  pid=394 exe=/usr/sbin/sshd dev= ino=25853959 scontext=system_u:system_r:sshd_t tcontext=system_u:system_r:sshd_t tclass=lnk_file

I'm starting to wonder if this has anything to do with the
2.6.0 devpts filesystem?

	rootfs / rootfs rw 0 0
	/dev2/root2 / ext3 rw 0 0
	none /selinux selinuxfs rw 0 0
	proc /proc proc rw 0 0
	devpts /dev/pts devpts rw 0 0
	/dev/sdb1 /home/cvs reiserfs rw 0 0
	/dev/sdc1 /disk2 reiserfs rw 0 0


--
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: ssh policy hassles

[Dale Amon]

On Thu, Sep 25, 2003 at 11:44:57AM +0100, Dale Amon wrote:
>  Sep 25 11:40:26 cvs ssh(pam_unix)[394]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=10.0.0.25  user=root
>  Sep 25 11:40:32 cvs sshd[394]: Accepted password for root from 10.0.0.25 port 1160 ssh2
>  Sep 25 11:40:32 cvs sshd[394]: default security context is root:staff_r:staff_t
>  Sep 25 11:40:32 cvs sshd[394]: setting tty /dev/pts/2 context to root:object_r:staff_devpts_t
>  Sep 25 11:40:32 cvs sshd[394]: fatal: chown(/dev/pts/2, 0, 5) failed: Permission denied
>  Sep 25 11:40:32 cvs sshd[394]: error: chown /dev/pts/2 0 0 failed: Permission denied
>  Sep 25 11:40:32 cvs sshd[394]: error: chmod /dev/pts/2 0666 failed: Permission denied

Okay, I tried it with a policy that allowed the only
remaining avc and I still get the same as the above.
So I'm really starting to look at the devpts angle.
Has anyone else had problems with it? 

--
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: ssh policy hassles

[Dale Amon]

On Thu, Sep 25, 2003 at 11:44:57AM +0100, Dale Amon wrote:
> I'm starting to wonder if this has anything to do with the
> 2.6.0 devpts filesystem?

Okay, I find this, which doesn't seem right:

drwxr-xr-x  root     root     (null)                           /dev/pts

Should I perhaps add a a line to genfs_contexts?

  genfscon devpts /                     system_u:object_r:devpts_t


--
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: ssh policy hassles

[Russell Coker]

On Thu, 25 Sep 2003 22:17, Dale Amon wrote:
> On Thu, Sep 25, 2003 at 11:44:57AM +0100, Dale Amon wrote:
> > I'm starting to wonder if this has anything to do with the
> > 2.6.0 devpts filesystem?
>
> Okay, I find this, which doesn't seem right:
>
> drwxr-xr-x  root     root     (null)                           /dev/pts

It doesn't seem right, but it apparently is.  On my 2.4.21 SE2 system it has 
no label on /dev/pts and sshd works perfectly.

-- 
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: ssh policy hassles

[Stephen Smalley]

On Thu, 2003-09-25 at 08:21, Russell Coker wrote:
> > Okay, I find this, which doesn't seem right:
> >
> > drwxr-xr-x  root     root     (null)                           /dev/pts
> 
> It doesn't seem right, but it apparently is.  On my 2.4.21 SE2 system it has 
> no label on /dev/pts and sshd works perfectly.

There is a security label that is internally maintained by the kernel
and used for access controls, but it isn't exported to userspace via an
xattr handler.  We created an xattr handler for the devpts file inodes
to support relabeling by sshd and similar programs, but there is no such
requirement for the devpts root inode.  They have different inode
operation vectors, and we only patched the one used for the files.  The
root inode uses the simple_dir_inode_operations provided by libfs, which
only implements a lookup method, and we chose not to fork a separate
operations vector for it.

-- 
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: ssh policy hassles

[Dale Amon]

On Thu, Sep 25, 2003 at 08:55:38AM -0400, Stephen Smalley wrote:
> There is a security label that is internally maintained by the kernel
> and used for access controls, but it isn't exported to userspace via an
> xattr handler.  We created an xattr handler for the devpts file inodes
> to support relabeling by sshd and similar programs, but there is no such
> requirement for the devpts root inode.  They have different inode
> operation vectors, and we only patched the one used for the files.  The
> root inode uses the simple_dir_inode_operations provided by libfs, which
> only implements a lookup method, and we chose not to fork a separate
> operations vector for it.

Then I guess I'm at a brick wall for the moment. No idea what else
to look at. Perhaps its time for a late lunch break :-)


--
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: ssh policy hassles

[Dale Amon]

I'm still at work on the sshd problem. Just as a summary:

	kernel: 2.6.0-test5
	using devpts
	Russell Coker policy
	Colin's selinux experimental branch debian packages

Via the artifice of 
	/root/newrules.pl > /etc/selinux/domain/tmp.te
	make load

I've been able to get a copy of Colin's ssh source running with
my own added debugging printout. I've (thus far) not been able
to get sshd running under gdb with enforcing on so I can't get
much of a look at the ephemeral /dev/pts.

I've captured the point of failure though, and am not sure why
it should be so since it happens only with enforcing turned on:

#				TEST 1 ENFORCE=1
#
# ssh refuses rhost authentication
Sep 27 11:10:30 cvs ssh(pam_unix)[515]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=scout.islandone.org  
user=root

# ssh accepts password as valid
Sep 27 11:10:37 cvs sshd[515]: Accepted password for root from 10.0.0.25 port 2968 ssh2

# ssh sets security context
Sep 27 11:10:37 cvs sshd[515]: default security context is root:staff_r:staff_t

# ssh has a pty now
Sep 27 11:10:37 cvs sshd[515]: setting tty /dev/pts/0 context to root:object_r:staff_devpts_t

# But it fails a test in sshpty.c where it does a stat on the file and compares the
# results of the stat. The failure is caused by st.gid = 0 instead of the expected 5.
# (DMA is a token on my debug statements)
Sep 27 11:10:37 cvs sshd[515]: fatal: DMA pty=/dev/pts/0 pwuid=0 stuid=0 gid=5 stgid=0 

# We see further failures as it tries to release the pty
Sep 27 11:10:37 cvs sshd[515]: error: chown /dev/pts/0 0 0 failed: Permission denied
Sep 27 11:10:37 cvs sshd[515]: error: chmod /dev/pts/0 0666 failed: Permission denied


#				TEST 1 ENFORCE=0
#
# First part is the same
Sep 27 11:32:45 cvs ssh(pam_unix)[559]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=scout.islandone.org  
user=root
Sep 27 11:32:50 cvs sshd[559]: Accepted password for root from 10.0.0.25 port 2982 ssh2
Sep 27 11:32:50 cvs sshd[559]: default security context is root:staff_r:staff_t
Sep 27 11:32:50 cvs sshd[559]: setting tty /dev/pts/0 context to root:object_r:staff_devpts_t

# But it succeeds and the session is good and the connection works.
Sep 27 11:32:50 cvs ssh(pam_unix)[559]: session opened for user root by (uid=0)
Sep 27 11:32:50 cvs sshd[561]: setting security context to root:staff_r:staff_t

Has anyone a suggestion as to what is happening? There are no avc's at this point so
this looks like something deeper.


--
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: ssh policy hassles

[Russell Coker]

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

On Sat, 27 Sep 2003 23:33, you wrote:
> On Sat, Sep 27, 2003 at 02:32:45PM +0100, Dale Amon wrote:
> > Yep, with that I get more avc's, and by dumping the
> > newrules into a file I can get ssh working in enforcing mode.
> > Now all I have to do is figure out which is the critical one:
> >
> > allow sshd_t staff_devpts_t:chr_file { ioctl setattr };
>
> Although the above looks awfully suspicious! :-)

From my latest policy:
# Relabel and access ptys created by sshd
# ioctl is necessary for logout() processing for utmp entry and for w to
# display the tty.
allow $1_t $3:chr_file { relabelto read write getattr ioctl };
dontaudit $1_t $3:chr_file setattr;


But your error message seems to indicate that the setattr is required for your 
sshd.

I have attached my latest ssh policy, please try it out as-is and try changing 
the "dontaudit" to "allow" for the setattr operation.

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

[-- Attachment #2: ssh.te --]
[-- Type: text/plain, Size: 5471 bytes --]

#DESC SSH - SSH daemon
#
# Authors:  Anthony Colatrella (NSA) <amcolat@epoch.ncsc.mil>
#           Stephen Smalley <sds@epoch.ncsc.mil>
#           Russell Coker <russell@coker.com.au>
# X-Debian-Packages: ssh
#

# sshd_exec_t is the type of the sshd executable.
# sshd_key_t is the type of the ssh private key files
type sshd_exec_t, file_type, exec_type, sysadmfile;
type sshd_key_t, file_type, sysadmfile;

type ssh_port_t, port_type;

ifdef(`inetd.te', `
ifdef(`run_ssh_inetd', `
define(`using_ssh_inetd', `')
')
')

define(`sshd_program_domain', `
# privowner is for changing the identity on the terminal device
# privfd is for passing the terminal file handle to the user process
# auth is for /etc/shadow
type $1_t, domain, privuser, privrole, privlog, privowner, privfd, auth, auth_chkpwd;
role system_r types $1_t;
dontaudit $1_t shadow_t:file { getattr read };
uses_shlib($1_t)
allow $1_t self:unix_dgram_socket create_socket_perms;
allow $1_t self:unix_stream_socket create_stream_socket_perms;
allow $1_t self:fifo_file rw_file_perms;
allow $1_t self:process { fork sigchld setsched };

dontaudit $1_t proc_t:dir search;

# do not allow statfs()
dontaudit $1_t fs_type:filesystem getattr;

allow $1_t bin_t:dir search;
allow $1_t bin_t:lnk_file read;

# Read /var.
allow $1_t var_t:dir { getattr search };

# Read /var/log.
allow $1_t var_log_t:dir search;

# Read /etc.
allow $1_t etc_t:dir search;
allow $1_t etc_t:{ file lnk_file } { getattr read };
allow $1_t etc_runtime_t:file { getattr read };
allow $1_t resolv_conf_t:file { getattr read };

# Read and write /dev/tty and /dev/null.
allow $1_t devtty_t:chr_file rw_file_perms;
allow $1_t { null_device_t zero_device_t }:chr_file rw_file_perms;

# Read /dev/random and /dev/zero.
allow $1_t random_device_t:chr_file r_file_perms;

can_network($1_t)

allow $1_t self:capability { sys_chroot sys_resource chown dac_override fowner fsetid setgid setuid sys_tty_config };
allow $1_t { home_root_t user_home_dir_type sysadm_home_dir_t }:dir { search getattr };

# Set exec context.
can_setexec($1_t)

# Allow shells to be run in sysadm_t as well.
# Commented out.  Use newrole rather than directly entering sysadm_t.
#domain_trans($1_t, shell_exec_t, sysadm_t)

# Update utmp.
allow $1_t initrc_var_run_t:file rw_file_perms;

# Update wtmp.
allow $1_t wtmp_t:file rw_file_perms;

# Get security policy decisions.
can_getsecurity($1_t)

ifdef(`OLD_SELINUX', `
# Obtain the SID to use for relabeling ptys
allow $1_t security_t:security change_sid;
')

# Allow read access to login context
allow $1_t default_context_t:file r_file_perms;

# Access key files
allow $1_t sshd_key_t:file { getattr read };

# Update /var/log/lastlog.
allow $1_t lastlog_t:file rw_file_perms;

read_locale($1_t)

# Can create ptys
can_create_pty($1, `, server_pty')
allow $1_t $1_devpts_t:chr_file { setattr getattr relabelfrom };
')dnl end sshd_program_domain

# macro for defining which domains a sshd can spawn
# $1_t is the domain of the sshd, $2 is the domain to be spawned, $3 is the
# type of the pty for the child
define(`sshd_spawn_domain', `
domain_trans($1_t, shell_exec_t, $2)
ifdef(`xauth.te', `
domain_trans($1_t, xauth_exec_t, $2)
')

# Signal the user domains.
allow $1_t $2:process signal;

# Relabel and access ptys created by sshd
# ioctl is necessary for logout() processing for utmp entry and for w to
# display the tty.
allow $1_t $3:chr_file { relabelto read write getattr ioctl };
dontaudit $1_t $3:chr_file setattr;

# inheriting stream sockets is needed for "ssh host command" as no pty
# is allocated
allow $2 $1_t:unix_stream_socket rw_stream_socket_perms;
')

#################################
#
# Rules for the sshd_t domain, et al.
#
# sshd_t is the domain for the sshd program.
# sshd_extern_t is the domain for ssh from outside our network
#
sshd_program_domain(sshd)
sshd_spawn_domain(sshd, unpriv_userdomain, userpty_type)

ifdef(`use_x_ports', `
# for X forwarding
allow sshd_t xserver_port_t:tcp_socket name_bind;
')

sshd_program_domain(sshd_extern)
sshd_spawn_domain(sshd_extern, user_mini_domain, mini_pty_type)

# for when the network connection breaks after running newrole -r sysadm_r
dontaudit sshd_t sysadm_devpts_t:chr_file setattr;

# Allow checking users mail at login
allow sshd_t { var_spool_t mail_spool_t }:dir search;
allow sshd_t mail_spool_t:lnk_file read;
allow sshd_t mail_spool_t:file getattr;

ifdef(`using_ssh_inetd', `
allow inetd_t ssh_port_t:tcp_socket name_bind;
domain_auto_trans(inetd_t, sshd_exec_t, sshd_t)
domain_trans(inetd_t, sshd_exec_t, sshd_extern_t)
allow { sshd_t sshd_extern_t } inetd_t:tcp_socket rw_socket_perms;
allow { sshd_t sshd_extern_t } var_run_t:dir { getattr search };
', `
allow { sshd_t sshd_extern_t } initrc_devpts_t:chr_file rw_file_perms;
allow { sshd_t sshd_extern_t } self:capability net_bind_service;
allow { sshd_t sshd_extern_t } ssh_port_t:tcp_socket name_bind;
domain_auto_trans(initrc_t, sshd_exec_t, sshd_t)
domain_trans(initrc_t, sshd_exec_t, sshd_extern_t)

# Inherit and use descriptors from init.
allow { sshd_t sshd_extern_t } init_t:fd use;

# Create /var/run/sshd.pid
var_run_domain(sshd)
var_run_domain(sshd_extern)
')

undefine(`sshd_program_domain')

# so a tunnel can point to another ssh tunnel...
can_tcp_connect(sshd_t, sshd_t)

tmp_domain(sshd)




# Type for the ssh executable.
type ssh_exec_t, file_type, exec_type, sysadmfile;

# Everything else is in the ssh_domain macro in
# macros/program/ssh_macros.te.

Re: ssh policy hassles

[Dale Amon]

On Sun, Sep 28, 2003 at 12:13:29AM +1000, Russell Coker wrote:
> But your error message seems to indicate that the setattr is required for your 
> sshd.
> 
> I have attached my latest ssh policy, please try it out as-is and try changing 
> the "dontaudit" to "allow" for the setattr operation.

Results:

with latest policy.tgz		FAIL
add  your new ssh.te		FAIL
add  staff_devpts_t 		SUCCESS

This single line does it:

	allow sshd_t staff_devpts_t:chr_file { ioctl setattr }

I don't know yet if both attributes are required. It's getting
late and it's a night...


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