Re: Security precautions, CVS commit mails was Re: [freenet-support] anonymity(NOT)

2004-08-04 Thread Zenon Panoussis
Toad wrote:
You have taken extraordinary measures to protect against [the 
ftp server being hacked], haven't you?

Umm, measures such as..? I don't see how you can defend against the
above, really.
Well, first of all the elementary stuff. No other services on the
same machine. You don't want your ftp server compromised because
of a flaw in mailman, or even sendmail, so put that stuff elsewhere.
Heavy firewalling. IDS. No compiler installed; most hacks begin
with a compilation. No unnecessary script interpreters; an ftp
server can live very well (and much longer) without PHP, python,
perl, java, whathaveyou. A super-lean kernel. A permanently up
to date system.
Then the more tedious stuff. Remote syslog. Remote md5sums of every
file on the machine, regularly checked. A draconic password policy.
Why not a read-only server running from a CD-ROM?
And then comes the really difficult part, physical security. A
gang of angry and hungry dobbermans in the outer perimeter, cobras
in the server room, tarantulas inside the server itself.
As a side-dish, network security. If your DNS can be compromised,
nobody needs to touch your ftp server before they can serve their
own files from your machine. Arp. There is really no way to
ensure that a visitor to your ftp server won't end up elsewhere,
but an unpredictable control mechanism can let you know if that
happens and mitigate the damage.
There is one thing though... I think the CVS announcement mails are
generated on the client side. They should be generated on the server
side. Anyone know how to do this?
What you mean by CVS announcements?
Z
--
Framtiden r som en babianrv, frggrann och full av skit.
 Arne Anka
___
Support mailing list
[EMAIL PROTECTED]
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]


Re: Security precautions, CVS commit mails was Re: [freenet-support] anonymity(NOT)

2004-08-04 Thread Zenon Panoussis
Toad wrote:
The fundamental issues revolve around changes to source code. 
Only in theory. In practice, the source code only affects your reputation.
The binary code affects the users. If you only protect the source code
(which is also what might get reviewed at some point or other), you will
only be protecting those users who are really careful and compile from
source and don't really need protection. Protecting the binaries is much
more crucial.
Of course I don't mean that protecting the source is unimportant. I have
the impression - from nowhere - that freenet is developed by a small and
rather tight team. If that is so, then commits can be based on personal
trust. If, on the contrary, source can be committed by not fully trusted
people, then there is no end to the auditing requirements before you can
call the resulting binaries safe.
They're
not easy to deal with. Specifically, no matter how deeply you secure the
server, you can't certify every single build as free from unexpected
code. 
It is human to err and, as builds 5085-5087 prove, errors will happen.
However, as long as the developers are well-willing but imperfect friends,
we can trust that there will be no spycode sending extensive reports to
nsa.gov. There is a fundamental difference between bugs and malicious code.
I am willing to take the risk of accidentally introduced security flaws,
but not the guaranteed-to-work intentional security breach that an outsider
would put in freenet if he could.
Hence the need to ensure that for example mails get sent out EVERY
time a CVS commit occurs, and if they bounce it will keep trying to send
them forever. How can we achieve this?
As far as I know how mail servers work, you can't. Then again, why would
you need to? Really, how many people have commit permissions? As long as
they are fewer than three dozen or so, you can have a cryptographically
secured system of notification acknowledgements which leads to phone calls
for missing acknowledgments after a certain threshold. The problem is
not some notifications not reaching their destination, but rather commits
happening without anyone at all being notified.
I think that what you are really saying is that you ned to ensure that
nothing can be committed without at least some notifications going out.
If the cvs server gets hacked, you can't. One way around this is what
I wrote about remotely stored md5sums of all files. The way cvs works
sabotages this though (existing file unchanged, newer file present but
not md5summed to begin with).
Z
--
Framtiden r som en babianrv, frggrann och full av skit.
 Arne Anka
___
Support mailing list
[EMAIL PROTECTED]
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]


Re: Re: Security precautions, CVS commit mails was Re: [freenet-support] anonymity(NOT)

2004-08-04 Thread Paul
Well, a very striped down version of OpenBSD running off a cd and
freenet's cache being on an encripted disk with a one-time key (ie a
new key is randomly generated at boot) would make setting up a freenet
machine simple, safe, and dificult to update. :-p , 9 years with
one remote hole
~Paul

On Thu, 05 Aug 2004 00:23:51 +0200, Zenon Panoussis
[EMAIL PROTECTED] wrote:
 
 Toad wrote:
 
  You have taken extraordinary measures to protect against [the
  ftp server being hacked], haven't you?
 
  Umm, measures such as..? I don't see how you can defend against the
  above, really.
 
 Well, first of all the elementary stuff. No other services on the
 same machine. You don't want your ftp server compromised because
 of a flaw in mailman, or even sendmail, so put that stuff elsewhere.
 Heavy firewalling. IDS. No compiler installed; most hacks begin
 with a compilation. No unnecessary script interpreters; an ftp
 server can live very well (and much longer) without PHP, python,
 perl, java, whathaveyou. A super-lean kernel. A permanently up
 to date system.
 
 Then the more tedious stuff. Remote syslog. Remote md5sums of every
 file on the machine, regularly checked. A draconic password policy.
 Why not a read-only server running from a CD-ROM?
 
 And then comes the really difficult part, physical security. A
 gang of angry and hungry dobbermans in the outer perimeter, cobras
 in the server room, tarantulas inside the server itself.
 
 As a side-dish, network security. If your DNS can be compromised,
 nobody needs to touch your ftp server before they can serve their
 own files from your machine. Arp. There is really no way to
 ensure that a visitor to your ftp server won't end up elsewhere,
 but an unpredictable control mechanism can let you know if that
 happens and mitigate the damage.
 
  There is one thing though... I think the CVS announcement mails are
  generated on the client side. They should be generated on the server
  side. Anyone know how to do this?
 
 What you mean by CVS announcements?
 
 Z
 
 --
 Framtiden är som en babianröv, färggrann och full av skit.
   Arne Anka
 ___
 Support mailing list
 [EMAIL PROTECTED]
 http://news.gmane.org/gmane.network.freenet.support
 Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
 Or mailto:[EMAIL PROTECTED]

___
Support mailing list
[EMAIL PROTECTED]
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]