Re: [cobalt-users] Telnet users see all

[Jeff Lasman <jblists@xxxxxxxxxxxxx>]

Jens Kristian Søgaard wrote:

> Ehm, I have built chroot jails before ?!?!

Yes; note later down in my post that I was thinking all along of chroot.
I am waaaay guilty of oversimplifying, though; I probably shouldn't
have.

But I see it as having relatively unsurmountable problems... as do you,
later down in your reply to me.

> These two aren't showstoppers, but this last thing certainly is:
> 
>     3. You need to _copy_ all this files to a special directory for the
> user.
> 
> This means that every telnet users would need a lot of disk space just for
> setting up his account.

Which I thought was my point.  In fact, rereading my post now, I still
think it was my point.  I'm way too far behind in reading though; I'm
not giving enough thought to my replies; probably not enough to this one
either <frown>; I've got 538 more posts on this list to read until I'm
caught up <frown>.

> When using this strategy on RaQs, you also need to take care of some other
> things:
> 
>     1. Restricting user access through FTP (easy)
>     2. Any user that can execute CGI-scripts using the standard installation
> of Apache, can also use that to login (and effectively bypassing your neat
> chroot jail). This means you also have to chroot apache.

My guess is that's not easy considering the way Apache's implemented on
the RaQ...  I haven't looked at all the issues, though.

> No, you can't. You can't just use your own special version of bash -- you
> need to chroot it!!
> 
> If you just wrote a bash that were "locked down" so you couldn't cd out of
> your homedirectory, that would then prevent the user from downloading a new
> bash binary and running that command from his locked down shell (effectively
> giving him a full open shell).

I agree now that I look at those issues.

> > Linux/unix are NOT designed to be secure operating systems.
> 
> Oh, yes they are. Designers have just had to make some decisions - security,
> cost and usuability. A system could be made very secure, it would however
> also be very non-userfriendly. You can't have all.

Okay, I change my sentence to:

Linux/unix WERE NOT designed to be secure operating systems.

I stand by that; they were basicaly written for and in open educational
environments.  In fact, Dennis Ritchie wrote (quoted in Practical Unix &
Internet Security [O'Reilly]): "It was not designed from the start to be
secure. It was designed with the necessary characteristics to make
security serviceable."

So, yes, we can make linux secure. But it was NOT designed to be
secure.  Or shall we argue with Ritchie <smile>?

The book also writes about "secure" versions of Unix, including "Trusted
Xenis" and "System V/MLS".

It's a great text, imho; with lots of realworld examples and practical
text.

> Linux is designed to be reasonably secure.

I think fairer to say that Linux is designed to be reasonably
securable.  Which most vendors don't do, again, imho.

> It is however not designed to be secure for users that can't be bothered to
> actually set their permissions right on their files (and then you might
> argue that this is required because you want apache to serve files, but
> that's a different issue).

If you've got a limited number of sites served by Apache, then you can;
you can make Apache's "user" a member of a bunch of groups, and let the
files belong to the specific user and a specific group; one of those
groups Apache belongs to.

> Try reading Bruce Schneier's new book - Secrets and Lies. It's a very good
> non-technical introduction to security.

Okay, when I finally finish the aforementioned "Practical Unix &
Internet Security"; it's only about 975 pages <smile>.

Jeff
-- 
Jeff Lasman <jblists@xxxxxxxxxxxxx>
nobaloney.net
P. O. Box 52672
Riverside, CA  92517
voice: (909) 787-8589  *  fax: (909) 782-0205