It would be most helpful if the installation process clarified what was
meant by these different options, too; both what they include and what
they omit.
My guess is that under this philosophy he didn't want a "server" at all,
but rather a "development" box with "server" capabilities.
Mike Corbeil wrote:
>
> If the server in question has enough disk space, the server does not need to be
> constantly up, and the the person who posted the question of this thread does
> not have a second machine to use, then this person could and perhaps should
> consider installing a second, separate, configuration on the same machine, for
> doing builds and such work.
>
> Then, when builds and such need to be done, shutdown the server, boot into the
> development configuration, do the coding or code changes, builds, and tests,
> and copy the files to the appropriate locations on the server partition(s), and
> reboot into the server.
>
> However, if the server must be constantly, or near constantly, up, then this
> won't be a good solution, because this kind of work can require considerable
> time.
>
> I agree that these tasks should be kept out of a serious server
> configuration. Even if it would or could be difficult for a hacker to break
> into the server and do damage using make and or running compilers on the server
> configuration, the added security of not having these tools accessable at all
> definitely makes much sense, at least for serious environments, and serious
> environments can usually afford a second machine for this kind of work,
> especially when considering PCs.
>
> If these tools are available, but there's no source code available, then this
> might help to decrease risk, especially if people using the server cannot
> upload to the machine.
>
> The least best choice, imo, is to make these tools available on the server,
> within the server configuration; unless as per the last above paragraph.
> However, if this is the only choice, then perhaps there's a way to allow only
> root and perhaps some special user account to have access to these tools.
>
> If there's no way to prevent people using the server from having access to
> these tools, then monitoring would need to be done "microscopically" using yet
> another daemon. Or, the server administrator sh/could install, do the builds
> and testing, and then uninstall, these tools, on an as needed basis, instead of
> leaving these persistently on the server.
>
> If this kind of attack on the server is not a concern, then advance at your own
> risks. If no hacker penetration ever occurs, then great; otherwise, "live and
> learn".
>
> On the other hand, perhaps it is possible to install these development tools
> and leave them on the server configuration, while assigning these tools
> [strictly] to a specific group, e.g., "developer", making sure that the server
> does not belong to the developer group, creating a special user account for
> doing development, making this user part of the developer group, and while the
> server is up, login as a developer to do this development work.
>
> However, this would probably be better using a separate machine, to login to
> the server as a developer user, and if the person who posted this thread has
> the ability to do this, then this person should consider making that second
> machine the second machine already refered to, which would leave the server
> strictly a server.
>
> Server and developer or development platforms are not necessarily synonymous.
> A development server is, however file servers and isp servers, for example, are
> not. In this sense, it might be useful to know exactly what type of server is
> at the center of the question of this thread.
>
> Servers can be used as central to or strictly for development, but this
> probably isn't what the most typical use is. Servers are usually thought of as
> for file servers, isp servers, and database data servers, for example; however,
> servers can also be used for development tools.
>
> In this sense, it might be useful to have a little more clarity on the exact
> nature of the server this thread's about.
>
> mike
>
> P.S. A little long winded, eh.
>
> Alen Salamun wrote:
>
> > Charles Curley wrote:
> > > Yes, they are the most common utils in the Unix world. Which is EXACTLY
> > > why you don't want them on a server. If a cracker were to gain access,
> > > would you want the cracker to be able to compile for your computer?
> > >
> > > For proper security, do your own compiling on some other computer and copy
> > > the executables over. If you must compile on your server, install the
> > > compiler as needed and remove it when you are done.
> > Hi!
> >
> > Ohhh what a smart thing...It is SO HARD for a cracker to compile his
> > hacking/cracking tool on other machine and move it to this
> > one...Expecially on x86 architecture that is so uncommon...
> >
> > I have (almost) never saw a computer without c compiler on it...This is
> > like having a screw-driver in a trunk of a car and saying, it will help
> > a burglar to brake in...He can bring his own with him....
> >
> > Bye, Alen
> > --
> > *---------------------------------------------------*
> > * E-Mail: Alen Salamun <[EMAIL PROTECTED]> *
> > * LiNUX - The choice of GNU Generation! *
> > *---------------------------------------------------*
--
"Brian, the man from babble-on" [EMAIL PROTECTED]
Brian T. Schellenberger http://www.babbleon.org
Support http://www.eff.org. Support decss
defendents.
Support http://www.programming-freedom.org. Boycott amazon.com.
