>
> On Tue, 8 Jul 1997, Craig Sanders wrote:
>
> > On Sun, 6 Jul 1997, Alexander Kjeldaas wrote:
> >
> > It's not possible to do that with ANY unix. If you give someone a login
> > shell and a text editor, or even just an ftp-only login then they can
> > create executables.
>
> Please tell me how - given the following setup:
>
> * All filesystems are read-only.
Even /home? How are these people going to create any data if all filesystems
are read-only. Certainly, they have to have write access to some portion of
the system. Yes? If they do have write access anywhere on the system then
they can create executables.
> * (Re)mounting is disabled.
> * immutable-append-only are enforced by the kernel (i.e. you can't chmod
> them away).
Does this mean that you have to boot to a different kernel to do software
upgrades?
> * /var is _not_ read-only, but noexec, nodev.
> * all directories in /var are immutable - log-files are append-only.
How are you going to rotate your log files? They are going to get pretty
large. Are you going to take the system down to some maintenance run-level
every day or so in order to do your house-keeping?
> * No compiler, no advanced scripting languages available, no debugger, no
> dynamically linked executables.
When you say "no advanced scripting languages" are you including bash, tcsh
and zsh?
Shared libraries are a good thing. The system is going to require much more
memory to run if all executables are statically linked. And then when a new
library is made available, you're going to have to recompile all of your
executables. This doesn't sound desirable to me.
> * Read-only access to /proc
How does that affect /dev/{stdout,stdin,stderr}? They are sym-links into /proc
after all.
> * No direct access to devices.
>
> (the above are _some_ of the stuff we do on our linux-distribution)
Which Linux distribution do you currently base your system on?
>
> > if you really need this level of paranoia, then write a script to run
> > out of cron which does something like:
> > cd /var/log
> > mv -f executable.today executables.yesterday
> > find / -perms +111 -print >executables.today
> > diff executables.today executables.yesterday | mail -s "new
> > executables" root
> >
> > even that won't find plain text files which people can invoke like "perl
> > myprog.pl" or "sh myprog.sh".
>
> I don't think you listen to me - I don't want powerful interpreters so
> perl doesn't _exist_ - you'll have to introduce it into the system first.
OK, but that still leaves "sh myprog.sh".
>
> > in other words, the only way to do it on any unix is to be vigilant, and
> > to make sure your users understand what they are and are not allowed to
> > do on your system.
>
> You assume I have users on my systems - that isn't necessarily true.
>
If you have no users on your system, then what's the problem? It sounds
like you now have an embedded system. And with all of your filesystems
read-only, an embedded system that doesn't create any data. Sounds a lot
like a paper weight to me.
> > > Not that it's possible with redhat either, but the debian policy
> > > _should_ be to allow other types of distributions to be made based on
> > > the debian-packages.
> >
> > that IS one of debian's policies.
> >
> > > It isn't interesting to use debian-packages without using the
> > > package-system for example - so when the package-system is bloated,
> > > it just isn't feasible to make a specialized "distribution" based
> > > on debian.
> >
> > why not?
> >
> > > I had hoped that debian would stick to the GNU policy of using one
> > > implementation language - C, and only use perl as an "intermediate"
> > > step.
> >
> > Why? C is good, but so is sh, and perl, and C++, and java, and many
> > other languages. Each language has its own strengths and weaknesses.
> >
> > Some tasks are better done in perl (or even sh) than in C...why force
> > people to write programs that are 1000 times more complicated than they
> > need to be just so that they are written in the approved language?
>
> Because if you want others to make "specialized" distributions they might
> not be interested in having the run-time system of a dozen languages on
> their system. If the distribution is 40MB you don't want that 20MB of that
> consists of slang, perl and java run-time support.
>
The base Debian doesn't have "a dozen languages" on it. I thought we were
talking about needing Perl on a base Debian system? Perl is one language.
Java support is truly optional.
By "specialized" distributions, do you mean like the Linux Router Project
and other embedded systems? It seems to me that one could install the base
system and then remove the few packages that are not desired. Once that's
done, you've got the "specialized" distribution. yes?
> astor
>
The solutions you propose reminds me of the adage: "The only secure house
is one with no doors or windows." Secure, but not very useful.
The things that bother me about this set-up are: Who's data is it? Who is
serving whom? Any collection of data is susceptible to loss or corruption,
whether it's stored electronically, or on hard-copy. The automation of
data collection and manipulation is supposed to make life easier on those who
must deal with that data and use it to generate information. Yet when I read
the description of how you setup those systems I get the feeling that those
people's needs aren't being met as well as they could.
Chuck
--
Chuck Stickelman, Owner E-Mail: <[EMAIL PROTECTED]>
Practical Network Design Voice: (419) 529-3841
9 Chambers Road FAX: (419) 529-3625
Mansfield, OH 44906-1302 USA
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
