On 24/10/09 21:14 +0200, Hartmut Goebel wrote: > Cédric Krier schrieb: > > > I start to be tired that you repeat this. This is non-constructive > > behavior and unfaire. > > No offence meant, just to say that your point of view is quite different > from what the real-world requirements are.
It is different from ours.
>
> >> Yes, the GPL allows the user to change the software. But the
> >> company policy forbids the user installing software on the
> >> companies computer. This is quite a difference.
> >
> > As I already said, tryton can be run without installlation.
>
> I start to be tired that you repeat this. ;-) Please rad the next
> paragraph again, carefully.
This is because I try to explain that we must keep things simple and it is not
necessrary to create "security" measure that can easily be bypassed.
>
> >> And, as already stated yesterday, the user may technically be able
> >> to download and run the Tryton client by his own. But normally the
> >> company policy forbids doing this on this companies computer.
> >
> > What I try to say is that it is not useful to create restriction in
> > the client if they can be easily bypassed.
>
> See above: You are missing real-work requirements. We have to implement
> restrictions the admin can to to prevent bypassing.
But if it is not possible...
>
> >> And further: The company policy should forbid connecting
> >> non-company devices to the company network.
> >
> > If we are in a safe network. Those enforcements are not necessary.
>
> You are naive! The is no such thing like a "safe network". IP networks
> are unsafe and prone to all kind of attracts -- even (and especially)
> LANs. Never trust your room colleague, he is the first to run
> man-in-the-middle attacks via simple ARP-spoofing.
It was sarcasm. I don't understand what is the environment you talk: some
time users can not run non-authorised program and after you talk about
arp-spoofing.
For me, we must focus on the weak case: open network, open computer etc.
> >> To round up: The user is expected to use the Tryton client
> >> installation provided to him by the system administrators. The
> >> admin has to take cake the user can no circumvent the policy -- if
> >> technical possible --, and to help the user avoiding errors (say:
> >> help him to work secure). Thus the admin has to restrict the
> >> options a user can change. this includes the Tryton connection
> >> settings -- as udono stated yesterday.
> >
> > How do you do this ?
>
> I do not want to discuss technical solutions until we agree the
> objectives! Anyway one simple possible solution could be: read
> /etc/trytonrc, read ~/.trytonrc, read /etc/trtonrc.forced.
If admin don't want user to change configuration. He can just remove write
access to the .tryton
>
> Yes, the user can still download and run the Tryton client -- but he is
> not authorized to to this. So this is an intended breach of the
> companies security and he will simply lose his job.
Yes, like it can be a also considered for changing security option of the
client.
To resume, my point of view:
We must protect against man-in-the-middle.
It can be done like this:
- store the "fingerprint" of the servers (DNS name + port) at first connection
- when opening a connection:
- we must check if the "fingerprint" is still the same and continue if it
matches.
- if the connection is not ssl but we had for this server a "fingerprint",
we must stop.
- we must store also the expire time, to accept change when the stored one
expire.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email: [email protected]
Jabber: [email protected]
Website: http://www.b2ck.com/
signature.asc
Description: Digital signature
