hiding system directories

"jarqs" <jarqs@nospaminteria.pl> writes:

>for now i figured it out to "chmod o-r" on /home for better securing data
>stored by users (file names not seen by others).

>i've done it on system directories too - like /etc - of course it doesn't
>make sense for users who know a bit about linux system; helps with beginners
>maybe.

Sure it helps. It makes the system completely useless and thus the users
will abandon it and it will no longer bother you with security issues.

>if ssh would have something like a chroot option for a limited basic system
>operation - for educational purposes only or something like that - would be
>great.

Sure. It has. Give each user their own computer which noone else can log
onto. That is what you are suggesting for the chroot stuff, since ALL of
the programs, files, libraries has to be in the chroot jail. Ie, you need
to duplicate the whole system for each user. HOpe you have a lot of disk
space.

>>for now i figured it out to "chmod o-r" on /home for better securing data
>>stored by users (file names not seen by others).
>
>>i've done it on system directories too - like /etc - of course it doesn't
>>make sense for users who know a bit about linux system; helps with
>>beginners
>>maybe.
>
> Sure it helps. It makes the system completely useless and thus the users
> will abandon it and it will no longer bother you with security issues.

are you sure you know what are you talking about, or just had a bad day?


>>if ssh would have something like a chroot option for a limited basic
>>system
>>operation - for educational purposes only or something like that - would
>>be
>>great.
>
> Sure. It has. Give each user their own computer which noone else can log
> onto. That is what you are suggesting for the chroot stuff, since ALL of
> the programs, files, libraries has to be in the chroot jail. Ie, you need
> to duplicate the whole system for each user. HOpe you have a lot of disk
> space.

hope you'll never give your advice to anyone again.

chroot is a simpler solution to your problem:
* mount -obind : man mount - learn how binding works create a jail for
every user
* run ssh from with the chroot
e.g in bash
#our chroot for users will be /home/chrooted
mkdir -vp
/home/chrooted/{tmp,dev,var,proc,home,bin,etc,lib,usr/{bin,lib}}
for d in home lib proc dev var tmp; do
mount -v -obind /$d /home/chrooted/$d
done
#do the same for all allowed binaries or use something like busybox
then
chroot /home/chrooted

ps: you see, you must learn and know what you talking about.
Silah!
---
jarqs wrote:
> >>for now i figured it out to "chmod o-r" on /home for better securing data
> >>stored by users (file names not seen by others).
> >
blah blah blah...

jarqs wrote:
>>> for now i figured it out to "chmod o-r" on /home for better securing data
>>> stored by users (file names not seen by others).
>>> i've done it on system directories too - like /etc - of course it doesn't
>>> make sense for users who know a bit about linux system; helps with
>>> beginners
>>> maybe.
>> Sure it helps. It makes the system completely useless and thus the users
>> will abandon it and it will no longer bother you with security issues.
>
> are you sure you know what are you talking about, or just had a bad day?

You might try it before you bash the poster. chmod o-w /etc will break
a bunch of things such as:
* /etc/profile is not available for sourcing
* /etc/passwd is not available for uid to username conversions
* cd ~user doesn't work - cannot look up the username
* name resolution doesn't work - /etc/hosts and /etc/resolv.conf
are not available
* At least under gentoo, gcc is not available - gcc-config depends
on /etc/init.d/functions.sh

>
>
>>> if ssh would have something like a chroot option for a limited basic
>>> system
>>> operation - for educational purposes only or something like that - would
>>> be
>>> great.
>> Sure. It has. Give each user their own computer which noone else can log
>> onto. That is what you are suggesting for the chroot stuff, since ALL of
>> the programs, files, libraries has to be in the chroot jail. Ie, you need
>> to duplicate the whole system for each user. HOpe you have a lot of disk
>> space.
>
> hope you'll never give your advice to anyone again.

Let's see...
You cannot browse the web, send email, or compile programs. Your shell
scripts from other systems no longer work. What are you planning on
using the system for that still is functional?

Doug

> You might try it before you bash the poster. chmod o-w /etc will break

when did i tell anything about chmod o-w ?...

jarqs wrote:
>> You might try it before you bash the poster. chmod o-w /etc will break
>
> when did i tell anything about chmod o-w ?...
>
>

It should have been chmod o-r - sorry for the typo. The errors I listed
are for 'chmod o-r /etc'.

You did say that you've used chmod o-r on system directories like /etc
and that it works.

In news:eoivhd$fln$1@scrotar.nss.udel.edu,
Douglas O'Neal <oneal@dbi.udel.edu> wrote:

> You might try it before you bash the poster. chmod o-w /etc will
> break
> a bunch of things such as:
> * /etc/profile is not available for sourcing
> * /etc/passwd is not available for uid to username conversions

Removing write perms for others on /etc does that? Are you on drugs or
something? That's the default system configuration:

$ ls -l / | grep etc
drwxr-xr-x 38 root root 4096 Dec 20 19:43 etc

patrick wrote:
> In news:eoivhd$fln$1@scrotar.nss.udel.edu,
> Douglas O'Neal <oneal@dbi.udel.edu> wrote:
>
>> You might try it before you bash the poster. chmod o-w /etc will
>> break
>> a bunch of things such as:
>> * /etc/profile is not available for sourcing
>> * /etc/passwd is not available for uid to username conversions
>
> Removing write perms for others on /etc does that? Are you on drugs or
> something? That's the default system configuration:
>
> $ ls -l / | grep etc
> drwxr-xr-x 38 root root 4096 Dec 20 19:43 etc

That's a typo - the OP said he ran chmod o-r on system directories like
/etc and I was replying to that. I should never post before my second
cup of coffee.

Another aproach, if you have the resources availible.
Put a virtual machine inside the debian machine, and let the accounts
reside on it. This would keep all the server files isolated, and
the users would only see a second system.
Robert

On Thu, 11 Jan 2007 10:27:47 +0100, jarqs wrote:

> hi
>
> I need help in securing my debian server: i want group "users" not to have
> access (via shell) to system directories (like /etc). How to do it and not
> to have the system crashed :).
> thanks

On 22 Feb, 09:30, robert <slackwarerob...@netscape.net> wrote:
> Another aproach, if you have the resources availible.
> Put a virtual machine inside the debian machine, and let the accounts
> reside on it. This would keep all the server files isolated, and
> the users would only see a second system.
> Robert

Goodness, this is an old thread now! But still valid.

I've been having good success with Xen lately, for doing fully
customized development environments and keeping developers (who need
root to modify packages and configurations) the heck out of the
server's system configurations, and to redeploy virtual servers from a
base image in a matter of minutes, rather than wasting time re-
installing entire hardware setups.