unix_chkpwd

unix_chkpwd

[Russell Coker]

When sshd is launched from inetd it inherits the open file handle for the TCP 
socket.  It does not use fcntl(fd, F_SETFD..) to make it close on exec for 
child processes, so when pam_unix.so runs unix_chkpwd (*) the file handle is 
inherited.

We can do one of three things:
1)  dontaudit system_chkpwd_t inetd_t:fd use;
2)  Change sshd to use fcntl() before doing any PAM stuff.
3)  Put code in pam_unix.so to close all file handles after the fork().

Which do you think is best?  2 seems most correct to me, but may be most 
difficult to get accepted upstream.  3 means ~1000 close() calls, which 
doesn't take too long on modern machines.  1 is a hack.

(*) This only happens with my modified PAM and SE Linux policy to prevent all 
login processes from being able to read /etc/shadow directly.

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

[Stephen C. Tweedie]

Hi,

On Fri, 2003-11-14 at 08:01, Russell Coker wrote:

> We can do one of three things:
> 1)  dontaudit system_chkpwd_t inetd_t:fd use;
> 2)  Change sshd to use fcntl() before doing any PAM stuff.
> 3)  Put code in pam_unix.so to close all file handles after the fork().
> 
> Which do you think is best?  2 seems most correct to me

2 would require fcntl()ing it back again afterwards, of course.  Having
your shell inherit FD_CLOEXEC on stdin could be confusing, at best. :-)

2 seems clearly the cleanest solution, but is also a rather
PAM+SELinux-specific hack.  I guess that we're going to be maintaining
SELinux-specific patches against a lot of core utils for some time,
until it becomes so widespread that all maintainers are desperate to
merge full SELinux support :-), and this specific change seems a
relatively minimal and painless one to maintain in that manner.

--Stephen


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

[Russell Coker]

On Fri, 14 Nov 2003 23:38, "Stephen C. Tweedie" <sct@redhat.com> wrote:
> > We can do one of three things:
> > 1)  dontaudit system_chkpwd_t inetd_t:fd use;
> > 2)  Change sshd to use fcntl() before doing any PAM stuff.
> > 3)  Put code in pam_unix.so to close all file handles after the fork().
> >
> > Which do you think is best?  2 seems most correct to me
>
> 2 would require fcntl()ing it back again afterwards, of course.  Having
> your shell inherit FD_CLOEXEC on stdin could be confusing, at best. :-)

That handle isn't used by the application and I need to have the policy deal 
with unix_chkpwd inheriting file handles for the pty/tty device anyway for 
the case of screen blankers etc.  So setting it back shouldn't be necessary.

> 2 seems clearly the cleanest solution, but is also a rather
> PAM+SELinux-specific hack.

It's not really SE Linux specific.  There is no need for a program that sshd 
executes to receive a copy of that file handle.  So the best practise (IMHO) 
is to ensure that such programs don't get it.

> I guess that we're going to be maintaining
> SELinux-specific patches against a lot of core utils for some time,

I certainly hope not.  Maintaining such patches is extremely painful and time 
consuming.  We want to get upstream support for SE Linux things as soon as 
possible.

> until it becomes so widespread that all maintainers are desperate to
> merge full SELinux support :-), and this specific change seems a
> relatively minimal and painless one to maintain in that manner.

I don't think that maintainers will be desperate for SE Linux support for a 
while.  However during our SE Linux work we often find and fix other bugs 
that may have security implications.  It would be rather embarassing for an 
upstream maintainer if the SE Linux version of a program was the only version 
that did not have a security hole and people who don't use SE Linux were 
forced to use the SE Linux version to close the hole!

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

[Stephen C. Tweedie]

Hi,

On Fri, 2003-11-14 at 21:59, Russell Coker wrote:

> > 2 would require fcntl()ing it back again afterwards, of course.  Having
> > your shell inherit FD_CLOEXEC on stdin could be confusing, at best. :-)
> 
> That handle isn't used by the application and I need to have the policy deal 
> with unix_chkpwd inheriting file handles for the pty/tty device anyway for 
> the case of screen blankers etc.  So setting it back shouldn't be necessary.

Hmm, I think I just forgot that we were dealing with privilege
separation here.  Do we have a guarantee that the pam call is only done
by the unprivileged temporary fork?  If so, we needn't worry about the
final shell inheriting the CLOEXEC flag.

> It would be rather embarassing for an 
> upstream maintainer if the SE Linux version of a program was the only version 
> that did not have a security hole and people who don't use SE Linux were 
> forced to use the SE Linux version to close the hole!

Quite!

--Stephen


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

[James Morris]

On Fri, 14 Nov 2003, Russell Coker wrote:

> We can do one of three things:
> 1)  dontaudit system_chkpwd_t inetd_t:fd use;
> 2)  Change sshd to use fcntl() before doing any PAM stuff.
> 3)  Put code in pam_unix.so to close all file handles after the fork().
> 
> Which do you think is best?  2 seems most correct to me, but may be most 
> difficult to get accepted upstream.

Yes, 2 seems correct to me as well, what objections would they have 
upstream?


- James
-- 
James Morris
<jmorris@redhat.com>



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

[Daniel J Walsh]

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

James Morris wrote:

>On Fri, 14 Nov 2003, Russell Coker wrote:
>
>  
>
>>We can do one of three things:
>>1)  dontaudit system_chkpwd_t inetd_t:fd use;
>>2)  Change sshd to use fcntl() before doing any PAM stuff.
>>3)  Put code in pam_unix.so to close all file handles after the fork().
>>
>>Which do you think is best?  2 seems most correct to me, but may be most 
>>difficult to get accepted upstream.
>>    
>>
>
>Yes, 2 seems correct to me as well, what objections would they have 
>upstream?
>
>
>- James
>  
>

I still think the safest thing is to manual close all sockets, since 
this prevents the case where someone has opened a socket accidently 
since you don't know where pam is going to be used.  The time it takes 
to run 0-max open file descriptors is tiny.

Dan

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