On 6/29/07, Matt <[EMAIL PROTECTED]> wrote:
2) Chroot jails / limited shells - do's and don'ts
I understand the implications of chroot jails. I understand they are not
worth the risk. Which is a shame really as they bring certain
functionality (or limits if you will) that I would consider nice to have.
How do you prevent people from snooping around the system, looking for
that sloppy permissioned file / gathering intelligence about your
clientbase? All by setting permissions manually?
How do you prevent them from compiling and installing all sorts of things?
regarding the info about client database, it depends what kind of
backend are you using, if it is flat files than permissions are sane
way to protect them IMO.
regarding compiling, IMO not worth the hassle to try to prevent that,
it is not really hard to compile the code on other machine + lack of
compiler makes it painfull for you to follow -current.
regarding all sorts of junk that they might throw at you, well, i use
ulimit. it works.
3) Mail setups
I can find lots of setups with virtual mailusers. I have been
succesfully using a Courier-imap/Postfix/MySQL setup for several years
now, connected to a webbased mailmanagement tool.
If I was to drop all that in favor of a more 'core' OpenBSD setup - what
would be a nice maintainable (both for users and myself) way to offer
single users multiple domains / mailboxes?
i like virtual mail users.
4) Other considerations
Any advice on what to avoid and what to certainly do/check/follow up on
is appreciated.
I will certainly miss stuff that might present a problem down the road.
For instance things like cronjobs- do you limit their use by custom
scripts or do you just monitor abuse?
IMO not worth the effort to restrict usage of crontab. (afterall it is
fairly simple to setup ssh keys and a cronjob on local machine that
will execute some code/script/whatever)
I am aware of things like 'accounting', 'quota' and 'ulimit' - any other
handy utils I might check?
logcheck (never set it up on OBSD tho, just linux).
--
almir
