Re: isolating untrusted programs in ssh chroot jails

2015-03-19 Thread Jeff St. George
You said at beginning of your comments now i don't use
firefox (or any 'modern browser)
   may I ask which browser you like to use? And for what reasons?

thanks in advance

On Thu, Mar 19, 2015 at 7:56 PM, dan mclaughlin thev...@openmailbox.org
wrote:

 here are the scripts i wrote to make this easier. these really were made
 for my own use, but i hope others may find them useful. i would be
 interested to know if anyone else actually does find them useful. would
 also be glad to know of any errors/problems/things that can go wrong i
 didn't think of.


 the first one (jail_new) creates a new jail (and possibly the user).
 the second one (jail_pkgadd) adds a package and its dependencies to an
 existing jail. they are expected to be in the same directory (jail_new
 cannot add packages (-p) otherwise).

 to relate to my earlier examples:

 $ jail_new -tu _inmate:_chaingang /home/jail

 will create the jail in /home/jail and also the user _inmate and group
 _chaingang. this case it will be just be a regular shell account (just
 chrooted).

 $ jail_new -t _inmate:_chaingang /home/jail

 will create the jail, but will not create the user:group.


 a real case:

 $ jail_new -tux -k /home/null/.ssh/id_rsa.pub -p w3m,feh:/usr/release/pkg
 browse /home/browse w3m -B

 this command sets up the terminal (-t) and X (-x) in a directory (here
 /home/browse), creates a user (-u) (in this case 'browse'), uses the given
 key file (-k) for the authorized keys, installs the packages (-p) w3m and
 feh (and all of their dependencies) from directory /usr/release/pkg, and
 sets 'w3m -B' to run automatically via ForceCommand in sshd_config.

 this is the equivalent of:

 $ jail_new -tux -k /home/null/.ssh/id_rsa.pub browse /home/browse w3m -B
 $ jail_pkgadd -p /usr/release/pkg w3m /home/browse
 $ jail_pkgadd -p /usr/release/pkg feh /home/browse

 if you want bzip2 in there as well, you can always add it later:

 $ jail_pkgadd -p /usr/release/pkg bzip2 /home/browse

 or, if PKG_PATH is set (and not remote) you can omit -p

 $ jail_pkgadd bzip2 /home/browse

 if PKG_PATH is set, and is remote, you need:

 $ jail_pkgadd -r bzip2 /home/browse

 (note: will only allow a single directory for PKG_PATH)

 this can be used by running:

 $ Xephyr :1  env DISPLAY=:1 ssh -X browse@localhost

 (side note: w3m runs 'display' to display an image, so i create a symlink
 to feh to view images)


 another case:

 $ jail_new -tuxr -k /home/null/.ssh/id_rsa.pub -p 
 xpdf:scp://null@node02/usr/release/pkg
 pdf /home/pdf

 you need to specify -r (remote) directly to use remote pkg src.

 which is the equivalent of:

 $ jail_new -tux -k /home/null/.ssh/id_rsa.pub pdf /home/pdf
 $ jail_pkgadd -r -p scp://null@node02/usr/release/pkg xpdf /home/pdf

 which can be used:

 $ cp test.pdf /home/pdf/tmp
 $ Xephyr :1  env DISPLAY=:1 ssh -X browse@localhost xpdf -fullscreen
 /tmp/test.pdf

 (in this case it may be best not to use ForceCommand, since you may want to
 open multiple documents.)


 WARNING use at your own peril. if you can't read the scripts, you probably
 shouldn't use them, and then i am certain there are other glaring security
 flaws you need to know about. i include these because it is a dull pain in
 the ass to do this manually, and hopefully someone may get some use out of
 them.

 other than that, do with it what you wish.

 they are as fool-proof as i could make them, so that i don't shoot myself
 in
 the foot accidently (and i have been around long enough to have done that a
 few times, even while being careful). but you never know.

 jail_new:
 --
 #!/bin/ksh
 USAGE=${0##*/} [-jrtux] [-k authkeys] [-p pkg[,pkg2...][:pkgpath]]
 user[:group] path [cmd [args ...]]
 [[ $1 = -h ]]  { echo USAGE $USAGE; return 0; }

 #-t sets PermitTTY and copies files for term
 #-x sets X11Forwarding and copies files for X (fonts,xauth)
 #-u creates user; fails if user exists
 #-j joins group; needed to join existing group
 #-p pkg[,pkg2...][:pkgpath]
 #-r allows remote pkg access
 #uses existing PKG_PATH
 #pkgpath arg overrides PKG_PATH

 #only accepts a lone pkgpath

 PATH=/sbin:/bin:/usr/sbin:/usr/bin

 echov() {  eval echo \\$$1\;  }
 isemptyv() {  eval [ \${#$1} -eq 0 ];  }
 notemptyv() {  eval [ \${#$1} -gt 0 ];  }
 alias xt='set -o xtrace'
 alias xt-='set +o xtrace'

 if [ $(id -u) -eq 0 ];then
   echo ERR cannot run as root
   return 1
 fi

 _sshd_config=/etc/ssh/sshd_config
 _sshd_config_tmp=/tmp/sshd_config

 trap rm -f $_sshd_config_tmp 0 2

 #for convenience
 _fontdir=/usr/X11R6/lib/X11/fonts
 _terminfo=/usr/share/misc/terminfo.db
 _termcap=/usr/share/misc/termcap

 _do_x=no
 _do_tty=no
 _do_useradd=
 _do_joingrp=
 _do_remote=
 _authkeys=
 _pkg=
 _pkgpath=
 _userhome=/home/cell
 while getopts :jrtuxk:p: _opt;do
   case $_opt in
 j) _do_joingrp=yes ;;
 r) _do_remote=-r ;;
 t) _do_tty=yes ;;
 u) _do_useradd=yes ;;
 x) _do_x=yes ;;
 k) _authkeys=$OPTARG
if [ ! -f 

Re: Just a thank you.

2015-03-14 Thread Jeff St. George
Ditto!

On Sat, Mar 14, 2015 at 5:44 PM, Maurice McCarthy m...@mythic-beasts.com
wrote:

 On Fri, Mar 13, 2015 at 06:09:05PM -0700 or thereabouts, Benjamin Heath
 wrote:
  Hi,
 
  This seems non-sequitur somehow, but I would simply like thank all the
  developers of OpenBSD for continuing work on the only OS that I really
  trust. I learn plenty just by lurking on this list. I also appreciate
  having a set of developers with the fortitude to entirely reject very
  flawed systems, and I like that simply because someone has to.
 
  Just thanks.
  Ben.
 

 +1. Totally agree. I have now completely abandoned linux.

 Thanks Hugely
 Maurice



Re: lynx is gone?

2015-03-04 Thread Jeff St. George
Its not in my pay grade to offer a technical opinion on Lynx removal!
But ,,WHAT r u folks using instead, considering??

thanks OpenBSD



Re: Best way forward w.r.t. apache/nginx/httpd?

2014-12-29 Thread Jeff St. George
In more or less the same boat, without php as our virtual sites are simple
display only.

However for future business developement we have wondered the same.

I am inn agreement with your choice of (1) as that would be ours pending
feedback here from those who know.


On Mon, Dec 29, 2014 at 7:30 AM, T. Ribbrock emga...@gmx.net wrote:

 Hi all,

 I'm finally getting round to updating my home server (gets a fresh 5.6
 install).

 Of course, there were a lot of changes over the past versions, one of
 them being the whole apache - nginx - httpd migration. My webserver
 has a CMS running which requires PHP and MySQL, plus a few more
 PHP-applications. Also, I have two or three virtual sites running and
 I'm currently considering having a look at something like Owncloud
 and/or Citadel.

 Given the current state of development in OpenBSD, I'm now wondering
 what the best way forward is for me:

 a) Install apache-httpd-openbsd from ports and keep my configuration
basically as is
Advantage: Less work to get everything running - I've done OpenBSD
re-installs like that several times over the past years
Disadvantage: I guess that the new httpd will get a lot more
developer attention, so this does not seem the ideal option longterm,
but I could always migrate to httpd later, e.g. when upgrading to 5.7
or (more likely) 5.8

 b) Migrate to nginx
This seems to be the least interesting option - not only do I have to
migrate now, but once more in the future, as nginx is also on the way
out (so, the same developer attention caveat applies as with
apache)

 c) Migrate to httpd
From what I've gathered so far from this list, this would basically
require me to switch to -current, as the 5.6 version is too fresh and
too many changes have happened since - or am I being pessimistic
here? I've never run -current before, hence, I'm a bit hesitant...

 I tend to go for a) because I do not want to migrate twice - but maybe
 somebody else has some interesting points that I have not considered
 yet? I'd appreciate the input!

 Regards,

 Thomas
 --

 -
  Thomas Ribbrockhttp://www.ribbrock.org/
You have to live on the edge of reality - to make your dreams come
 true!