RE: ssh policy hassles

RE: ssh policy hassles

[Inger, Slav (S.B.)]

-----Original Message-----
From: Dale Amon [mailto:amon@vnl.com]
Sent: Wednesday, September 24, 2003 4:31 PM
To: SELinux Mail List
Subject: ssh policy hassles

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

Don't know if this helps much, but the only reference I see to /var/lib in the trace is sshd doing a stat on directory /var/lib/empty.

--
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 Wed, Sep 24, 2003 at 05:55:40PM -0400, Inger, Slav (S.B.) wrote:
> Don't know if this helps much, but the only reference I see to /var/lib in the trace is sshd doing a stat on directory /var/lib/empty.

It certainly does. I wonder why I can't find it via a source grep? 
I guess that means it does have a valid reason to have access to 
that directory.

I'll have to go to the ssh.te now and figure out why it
isn't there already. Seems strange that it isn't if it
is commonly accessed.

--
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 Wed, Sep 24, 2003 at 11:11:57PM +0100, Dale Amon wrote:
> I'll have to go to the ssh.te now and figure out why it
> isn't there already. Seems strange that it isn't if it
> is commonly accessed.

I've added this:

# DMA20030924 Added search /var/lib 
allow $1 var_lib_t:dir search;

to ssh.te and it gets rid of that avc. I wonder if this
is needed in the master policy? Up to Steve I guess.

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

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

[Diyab]

Dale Amon wrote:
> On Wed, Sep 24, 2003 at 11:11:57PM +0100, Dale Amon wrote:
> 
>>I'll have to go to the ssh.te now and figure out why it
>>isn't there already. Seems strange that it isn't if it
>>is commonly accessed.
> 
> 
> I've added this:
> 
> # DMA20030924 Added search /var/lib 
> allow $1 var_lib_t:dir search;
> 
> to ssh.te and it gets rid of that avc. I wonder if this
> is needed in the master policy? Up to Steve I guess.
> 
> 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
> 

I don't get that /var/lib avc error.  Does the login work without that 
allow rule you added?  If so then maybe it doesn't really need it.

Maybe that "bad" link has something to do with it.  unmount /var and run 
an fsck on it then remount it and see if you still get the error.

Timothy,

-- 
I put instant coffee in a microwave and almost went back in time.
		-- Steven Wright


--
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 Wed, Sep 24, 2003 at 11:01:56PM -0400, Diyab wrote:
> Dale Amon wrote:
> I don't get that /var/lib avc error.  Does the login work without that 
> allow rule you added?  If so then maybe it doesn't really need it.

Nope. I cannot connect in enforcing mode. I've worked my way through
two ssh fatal avc's and this is the last one. None of them make
particular sense to me. To the point that I even did a 
forced reinstall of ssh...
 
> Maybe that "bad" link has something to do with it.  unmount /var and run 
> an fsck on it then remount it and see if you still get the error.

It's not a partition, just a plain directory. The whole disk is a
/ partition so all I could do is reboot. That will happen later
this morning anyway, since I shut the test bed down at night. It's
old and noisy. :-)

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

[Tom]

On Wed, Sep 24, 2003 at 11:11:57PM +0100, Dale Amon wrote:
> > Don't know if this helps much, but the only reference I see to /var/lib in the trace is sshd doing a stat on directory /var/lib/empty.
> 
> It certainly does. I wonder why I can't find it via a source grep? 

Because it is not hard-coded. It's whatever home-directory you set in
/etc/passwd for the privsep account.

That's also why others don't see that access. On Debian, for example,
it defaults to /var/empty

You might want to define a special type for the empty dir, so you can
move it around and don't have to give sshd access to all of /var

-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
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 16:46, Tom wrote:
> That's also why others don't see that access. On Debian, for example,
> it defaults to /var/empty
>
> You might want to define a special type for the empty dir, so you can
> move it around and don't have to give sshd access to all of /var

I don't think it really needs a separate type.  Only search access should be 
required, and search access for /var is necessary to even get to
/var/empty...

-- 
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 08:46:17AM +0200, Tom wrote:
> Because it is not hard-coded. It's whatever home-directory you set in
> /etc/passwd for the privsep account.
> That's also why others don't see that access. On Debian, for example,
> it defaults to /var/empty

Some ssh documentation recommends this as the default setup, 

 mkdir /var/empty
 chown root:sys /var/empty
 chmod 755 /var/empty
 groupadd sshd
 useradd -g sshd -c 'sshd privsep' -d /var/empty -s /bin/false sshd

But debian has this setup:

/etc/passwd
	sshd:x:102:65534::/var/run/sshd:/dev/null

/etc/group
	ssh:x:105:

/var
	drwxr-xr-x    2 root     root         1024 Aug 27  2002 empty

/var/run
	drwxr-xr-x    2 root     root         1024 Aug 22 22:26 /var/run/sshd

Which looks like it should be using /var/run/sshd insteady of /var/empty,
and yet the search priv on /var fixed one problem. 

> You might want to define a special type for the empty dir, so you can
> move it around and don't have to give sshd access to all of /var

That might be necessary. As far as I can tell, I've got
a straight out of the dpkg openssh install on this box. I'd think
anyone else on debian should be seeing the same problem if this
is the case, so I'm very interested in seeing where the real
problem lies, ie specific to my test machine, or a general
package problem for debian, or a generic problem for ssh policy.

I've now also got to follow up on Russ's suggestions. His note
that the missing inode is a /proc item might be very helpful on
that one.



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

[Diyab]

Dale Amon wrote:
> On Thu, Sep 25, 2003 at 08:46:17AM +0200, Tom wrote:
>>You might want to define a special type for the empty dir, so you can
>>move it around and don't have to give sshd access to all of /var
> 

I did this when I installed it on slackware.  In ssh.fc I added

	/var/empty	system_u:object_r:sshd_privsep_dir_t

and in sshd.te I added

	type sshd_privsep_dir_t, file_type, sysadmfile;

and

	allow sshd_t sshd_privsep_dir_t:dir { getattr search };

Timothy,

-- 
I put instant coffee in a microwave and almost went back in time.
		-- Steven Wright


--
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:55, Diyab wrote:
> Dale Amon wrote:
> > On Thu, Sep 25, 2003 at 08:46:17AM +0200, Tom wrote:
> >>You might want to define a special type for the empty dir, so you can
> >>move it around and don't have to give sshd access to all of /var
>
> I did this when I installed it on slackware.  In ssh.fc I added
>
> 	/var/empty	system_u:object_r:sshd_privsep_dir_t
>
> and in sshd.te I added
>
> 	type sshd_privsep_dir_t, file_type, sysadmfile;
>
> and
>
> 	allow sshd_t sshd_privsep_dir_t:dir { getattr search };

Why not just label it as var_run_t?

In my latest policy I have the privsep directory (which is under /var/run in 
Debian) labeled as var_run_t.  In the case of sshd as a daemon it can create 
files under that, but in the case of sshd run from inetd (which is what you 
will be doing if you want to lock down sshd) then it gets { getattr search } 
access.

NB  The privsep process will be prevented from creating files by Unix 
permissions anyway.  Sshd does not have permissions to change the mode on the 
directory and the privsep process can not change it's UID.

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

[Diyab]

Russell Coker wrote:
> On Thu, 25 Sep 2003 22:55, Diyab wrote:
> 
>>Dale Amon wrote:
>>
>>>On Thu, Sep 25, 2003 at 08:46:17AM +0200, Tom wrote:
>>>
>>>>You might want to define a special type for the empty dir, so you can
>>>>move it around and don't have to give sshd access to all of /var
>>
>>I did this when I installed it on slackware.  In ssh.fc I added
>>
>>	/var/empty	system_u:object_r:sshd_privsep_dir_t
>>
>>and in sshd.te I added
>>
>>	type sshd_privsep_dir_t, file_type, sysadmfile;
>>
>>and
>>
>>	allow sshd_t sshd_privsep_dir_t:dir { getattr search };
> 
> 
> Why not just label it as var_run_t?

When I initially setup sshd with the default setting of /var/empty I 
decided to just give it it's own type in case there was ever a need to 
change the privsep location or the permissions it needs.

> In my latest policy I have the privsep directory (which is under /var/run in 
> Debian) labeled as var_run_t.  In the case of sshd as a daemon it can create 
> files under that, but in the case of sshd run from inetd (which is what you 
> will be doing if you want to lock down sshd) then it gets { getattr search } 
> access.

What do you get by running sshd through inetd that you don't get by 
running sshd alone?

Timothy,

-- 
I put instant coffee in a microwave and almost went back in time.
		-- Steven Wright


--
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 Fri, 26 Sep 2003 10:16, Diyab wrote:
> > In my latest policy I have the privsep directory (which is under /var/run
> > in Debian) labeled as var_run_t.  In the case of sshd as a daemon it can
> > create files under that, but in the case of sshd run from inetd (which is
> > what you will be doing if you want to lock down sshd) then it gets {
> > getattr search } access.
>
> What do you get by running sshd through inetd that you don't get by
> running sshd alone?

When run from inetd the sshd can not bind to port 22, so an attacker can't 
cause the current sshd to die and take over the port.

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

SELinux & UML FAQ

[Nick Davis]

Is there anything special required for getting UML working with 2.6
SELinux?  I've downloaded the patch and
applied it to 2.6.0-test3, which seemed to work fine.  But I get errors
when doing a 'make linux ARCH=um' as
suggested on the UML website documentation.  I was wondering if anything
has changed since the 2.4.x days; the docs are at least a couple years old.

Thanks,

Nick Davis
Center for Information Security
University of Tulsa



--
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: SELinux & UML FAQ

[Stephen Smalley]

On Mon, 2003-09-29 at 16:27, Nick Davis wrote:
> Is there anything special required for getting UML working with 2.6
> SELinux?  I've downloaded the patch and
> applied it to 2.6.0-test3, which seemed to work fine.  But I get errors
> when doing a 'make linux ARCH=um' as
> suggested on the UML website documentation.  I was wondering if anything
> has changed since the 2.4.x days; the docs are at least a couple years old.

I'd suggest using a newer kernel, as 2.6.0-test3 is fairly old.  We
should have an updated release on the NSA site soon based on 2.6.0-test6
along with updated userland components.  We did update the sourceforge
CVS tree last week, but that was prior to the release of 2.6.0-test6.

As for UML, I think Russell Coker had a trivial one line patch for it
a while back, available under http://www.coker.com.au/uml/.

-- 
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: SELinux & UML FAQ

[Russell Coker]

On Tue, 30 Sep 2003 06:27, Nick Davis wrote:
> Is there anything special required for getting UML working with 2.6
> SELinux?  I've downloaded the patch and
> applied it to 2.6.0-test3, which seemed to work fine.  But I get errors
> when doing a 'make linux ARCH=um' as
> suggested on the UML website documentation.  I was wondering if anything
> has changed since the 2.4.x days; the docs are at least a couple years old.

It's difficult to even guess at the problem you have when you don't include 
any of the error messages.

At this time I recommend 2.6.0-test5 as it's the latest kernel that I have got 
to compile with UML.  Hopefully a UML patch for test6 will be released soon.

For 2.6.0-test6 the nearest I got to compiling it was after applying the UML 
patch for 2.6.0-test5.  The compile didn't even get far enough to determine 
if the problems I've encountered before are still there.

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