[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian Installation experience




On Tue, 8 Jul 1997, Craig Sanders wrote:

> On Sun, 6 Jul 1997, Alexander Kjeldaas wrote:
> 
> 
> > Is it a goal for debian not to require perl? I don't think so - and
> > that is one of the things I don't like with debian. It seems that
> > debian is infested with perlism. There are "smart" perl-scripts doing
> > all sorts of things.
> 
> perl is no less secure than sh + sed + awk + cut + (all the other useful
> unix utilities). anything you can do in perl you can do with those tools
> too, but not quite as easily (for some things, a shell script is easier
> than perl).

You are just plain wrong. Perl has syscall which makes it possible to do
_anything_.  You can't to _anything_ with sed. As for awk - I don't use
it. 

> > I don't want powerful interpreters on my system and definitively not
> > compilers - I regard them as a security risk since I want to set
> > up my systems so that they do not accept the introduction of new
> > executables (mounting noexec, nodev, read-only etc). It doesn't seem
> > to be possible to do that with debian yet.
> 
> 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.  
* (Re)mounting is disabled.
* immutable-append-only are enforced by the kernel (i.e. you can't chmod
  them away).  
* /var is _not_ read-only, but noexec, nodev.  
* all directories in /var are immutable - log-files are append-only. 
* No compiler, no advanced scripting languages available, no debugger, no
  dynamically linked executables.  
* Read-only access to /proc
* No direct access to devices.

(the above are _some_ of the stuff we do on our linux-distribution)

> 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. 

> 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.

> > 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.

astor


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: