On Thu, 30 Sep 1999, guy keren wrote:
>
> On Wed, 29 Sep 1999, Nir Soffer wrote:
>
> > Break into my home machine. All I have now running is sshd (Which is
> > vulnerable, I know, but at least enough people use it to clear it out of
> > the bugs, and I can keep track.) , and I'm about to suspen
On Wed, 29 Sep 1999, Nir Soffer wrote:
> Break into my home machine. All I have now running is sshd (Which is
> vulnerable, I know, but at least enough people use it to clear it out of
> the bugs, and I can keep track.) , and I'm about to suspend it too.
are you really only running sshd ? are y
> > To give an example, you don't need to know a lot to run OpenBSD. But
> > the security people at OpenBSD do know what they're doing. (Notethat
> > I'm NOT saying that OpenBSD is 100% secure.)
>
> then in your own words, openBSD is insecure (i.e. anything less then 100%
> is insecure)?
See
On Wed, 29 Sep 1999, guy keren wrote:
> next thing you'l tell me that you can write a program that has 0 bugs...
No. But a program that is designed properly and only does one thing has
less chances of having bugs than bloated pieces of crap.
> and that you can 'inspect and secure' each and eve
On 27 Sep 1999, Adam Morrison wrote:
> To give an example, you don't need to know a lot to run OpenBSD. But
> the security people at OpenBSD do know what they're doing. (Notethat
> I'm NOT saying that OpenBSD is 100% secure.)
then in your own words, openBSD is insecure (i.e. anything less th
In <[EMAIL PROTECTED]>, guy keren
<[EMAIL PROTECTED]> writes:
> On 26 Sep 1999, Adam Morrison wrote:
>
> > The point being, again, that you probably can't rewrite you entire
> > system securely. But you can implement and verify a few select
> > services.
>
> you'll need to ba a super-programm
In <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Alexander L. Belikoff)
writes:
> So?! Just make all SUID binaries mode 4750 belonging to some
> designated group (suid) and make only _trusted_ users members of that
> group. Of course, the untrusted guys will have problems changing
> passwords / runnin
On Sun, 26 Sep 1999, Or Sagi wrote:
> Take for example a university setting. You need to give students accounts,
> and you most certainly don't trust them ..
Had you known how much effort was being spent at HUJI while I worked there
to prevent students from compromising root - And how fruitless
On Sun, Sep 26, 1999 at 07:48:35PM +0200, Adam Morrison wrote:
> > Assuming sufficient skill on the intruders part, there isn't much you can
> > do. There are precautions you can take to make things harder, and to help
> > you analyze things after the event happened (Tripwire/ the likes).
>
> Ag
Hmm...How's about OpenSSL and using the SSL wrapper for
telnet?
And speaking of sendmail, can anyone comment on
Exim (www.exim.org) ?
--
Best regards,
Ilya Konstantinov, GalaNet Webmaster
[mailto:[EMAIL PROTECTED]]
=
To unsubscri
Aviram Jenik <[EMAIL PROTECTED]> writes:
> Man, I'd like to be a user on your system...
>
> Given a shell account, it's almost trivial to gain root. Read bugtraq and
> you'll see. A rootshell bug is discovered every week. In a course of a year,
So?! Just make all SUID binaries mode 4750 belongi
On 26 Sep 1999, Adam Morrison wrote:
> The point being, again, that you probably can't rewrite you entire
> system securely. But you can implement and verify a few select
> services.
you'll need to ba a super-programmer to be 100% sure that the code for the
services you are running can NOT be
In <[EMAIL PROTECTED]>, Or Sagi
<[EMAIL PROTECTED]> writes:
> > ``Adequately protected'', in this case, refers to allowing a very specific
> > (and minimal) set of services to be reachable from the network. Because of
> > their small numbers, they can be inspected and secured.
>
> They can be
On Sun, 26 Sep 1999, Adam Morrison wrote:
> > *every* computer connected to the net, or with users on it can be
> > compromised.
>
> That's misleading.
>
> For any security discussion not to become silly, the relevant threat model
> must be defined. The threat model in this case, as I see it,
Or Sagi wrote:
> > So if you don't trust your internal users - DON'T give them accounts. Going
> > from regular user to root is trivial and only a matter of time (even if
> > you're superadmin).
>
> *every* computer connected to the net, or with users on it can be
> compromised.
That's misleadi
>
> *every* computer connected to the net, or with users on it can be
> compromised.
>
So? Do you see the world in black and white? You do understand there are
gradients, right?
Just because eventually someone can break into my computer, doesn't mean
I'll help him do it. Give people you don't tru
On Sun, 26 Sep 1999, Aviram Jenik wrote:
> So if you don't trust your internal users - DON'T give them accounts. Going
> from regular user to root is trivial and only a matter of time (even if
> you're superadmin).
*every* computer connected to the net, or with users on it can be
compromised.
t
better prepared for
marriage. They've experienced pain and bought jewellery.
- Rita Rudner
- Original Message -
From: "Or Sagi" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, September 26, 1999 2:12 PM
Subject: Re: How to block telnet access.
>
On Sun, 26 Sep 1999, Adam Morrison wrote:
>
> Sorry, but you are in trouble. If you have untrusted users on your system,
> then your security is broken by definition (and in practice).
>
I Disagree. There's no such thing as a perfectly secure system, but it's
quite possible to build a system w
> The problem is that they are several teen agrees that will probably give away
> their passwords and very soon i will have the whole hacker world in my server.
>
> Since i must give them telnet (ssh actually) access and i can't restrict the
> servers witch the ssh will be from (they are using d
Greetings,
> Hi list.
> How can i block access to directories and commands on my server ?
> i need to give telnet access to some ppl and i do not want to give them
> full access to the disks and commands.
>
> for example, i do not want to give them access to /etc/
>
By de
So, looking for some security HOWTO/Tutorials ? ...
** First, there's an "official" security HOWTO at LDP local mirror site:
http://www.cs.huji.ac.il/support/docs/Linux/mdw/HOWTO/Security-HOWTO.html
** Check out the following links. They're a bit not-Linux-oriented and possibly a
bit out dated,
M>> Is there a way to control the server time and process that they are using ?
/etc/security/limits.conf
M>> So they could not simply run something that will crush my system ?
M>> Can i limit their access to the network ? So they could not use sniffy in
M>> order to sniff my passwords ?
Sniffe
The problem is that they are several teen agrees that will probably give away
their passwords and very soon i will have the whole hacker world in my server.
Since i must give them telnet (ssh actually) access and i can't restrict the
servers witch the ssh will be from (they are using dailup) then
On Thu, 23 Sep 1999, Mike wrote:
> How can i block access to directories and commands on my server ?
using access permissions, groups, etc.
> i need to give telnet access to some ppl and i do not want to give them
> full access to the disks and commands.
they have only read-only access to dir
Hi list.
How can i block access to directories and commands on my server ?
i need to give telnet access to some ppl and i do not want to give them
full access to the disks and commands.
for example, i do not want to give them access to /etc/
Thanks,
Mike
==
26 matches
Mail list logo
