[scponly] .ssh

[Tony J. White]

> https://lists.ccs.neu.edu/pipermail/scponly/2004-January/000431.html
> 
> which seemed to indicate that this should no longer be problematic (at
> least no one objected to that proposition).

I wasn't aware of the new 'PermitUserEnvironment' OpenSSH directive, and 
yeah, that does seem to clear up the main security issue.   

> In the previous thread on this subject, Ralf asked if there were
> situations where it doesn't work to have only one writable subdirectory
> under $HOME. The two reasons I need $HOME to be writable are:
> 
> 1) Allow the creation of .courier (similar to .qmail) mail delivery
>    control files.
> 
> 2) Allow the automatic creation and later the manual modification of
>    $HOME/.spamassassin.
> 
> Admittedly these issues could be worked around with some bit of
> inconvenience, but inasmuch as it no longer appears necessary to limit
> access to .ssh, I don't see why $HOME can't just be writable.

I think it's best that scpjailer/chroot_setup.sh don't set $HOME 
to be writable by default since they have no way of knowing how sshd is
configured.  There may also be some other feature (or future feature) of 
OpenSSH that would allow an scponly user to gain more access than you 
intend to give by using his .ssh directory. 

Possibly this could be attacked from another angle.  For instance, another
way to block OpenSSH's use of the $HOME/.ssh directory is to create 
$HOME/.ssh as an unmutable empty file (chattr +i .ssh).  Then the user
wouldn't be able to remove it to create a new .ssh directory.  Although
I think chattr is a Linux/ext2 thing so it probably wouldn't be portable.
Do most systems/filesystems have similar features? 

-Tony

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : https://lists.ccs.neu.edu/pipermail/scponly/attachments/20040211/8ed58b7d/attachment.bin