1 |
On Tuesday 25 November 2008 22:14:47 RB wrote: |
2 |
> On Tue, Nov 25, 2008 at 14:58, Jan Klod <janklodvan@×××××.com> wrote: |
3 |
> > Actually, that sound like there is practically no way to keep networked |
4 |
> > workstation really secure. |
5 |
> |
6 |
> That's kind of outside the realm of this discussion. The difference |
7 |
> between the attack surface of a network interface versus that of a |
8 |
> local application is several orders of magnitude. |
9 |
Gives nothing, if all ways outside (network, no plaintext filesystems!) are |
10 |
closed and sessions are secure (locked, if not legitimately operated in AND |
11 |
enough bug-free). |
12 |
Yes, but who is going to work on disconnected system? |
13 |
Adding some kind of proxy with firewall opens up a possibility of malicious |
14 |
transfer to some trusted outside service, which can theoretically be |
15 |
compromised by then. |
16 |
Also I didn't count some wild tricks with operating hardware... But that |
17 |
doesn't count, as RAM can be partially read by coldboot att. |
18 |
|
19 |
> > As a conclusion of what I have read this far I can state: hardened OS is |
20 |
> > useless for non-server. Would that be too much? Well, I think, in a |
21 |
> > "black and white" no. (later is a discussion of what is better: to have 3 |
22 |
> > holes or 300) |
23 |
> |
24 |
> The problem, as I see it, is that you haven't defined your problem |
25 |
> scope. |
26 |
My problem is stupidly simple: I just want a safe (well, as safe as possible) |
27 |
way to exchange my mails. If I leave my physical hardware to be "as safe as |
28 |
possible", outside channel to mailserver remains (and can then once become a |
29 |
tunnel for other information). |
30 |
|
31 |
> Taking "extra precautions" is nice, but unless you [even |
32 |
> broadly] classify what you consider a viable threat, you're not going |
33 |
> to gain much ground. My advice would be to sit back and try to define |
34 |
> what you're defending against. |
35 |
Anything, that would allow to leak information through network or wipe local |
36 |
files, which is not an exact list of things, of course. I would appreciate, |
37 |
if someone throws in a link(s) to where people show / discuss ways it could |
38 |
be done, even if Linux user is careful (but not "paranoid") about how he uses |
39 |
the system. |
40 |
|
41 |
> There are measures you can take, but |
42 |
> blindly applying security policies is more likely to end up with a |
43 |
> broken system than a secure one. |
44 |
Sure. |