[Gllug] Editors

[David Freeman]

 --- home at alexhudson.com wrote: > On Sun, Jul 29, 2001 at 06:26:14PM
+0100, David Freeman wrote:
> > > swapoff [part]
> > > 
> > > Not recommended though. 
> > 
> > Why is it not recommended?
> 
> Because when you have swap, and you start getting tight on memory,
> the
> computer grinds and goes real slow. If you don't have swap, the first
> indication of an app running out of the bounds of memory is that it
> gets
> OOM'd. Ie., disappears. Eg, "Hey! Where did X just go????". Linux
> overcommits memory, and the vm is tuned for swap access. You _can_ do
> without swap, but, it's not recommended :)

Ok this all makes sense. Might also explain why programs just die for
no apparent reason.
 
> > > Not for applications AFAIK - but it is certainly possible for an
> > > application to state that pages should be locked in RAM.
> > 
> > Can you say that again slowly?
> 
> Hmm, worded confusingly :) I don't know of any way to tell the OS to
> lock an
> app in RAM, but it is possible for an app to allocate a memory space
> which
> is locked in RAM. So - a specially written app could have the
> behaviour you
> require; I just don't know of a way to do it to any app you want.
> 
> Does that make more sense ?? :)

Perfect.
 
> > > Security is always a compromise. 
> > 
> > It might be, but more to the point is, should it be?
> 
> It has to be. Once you get beyond a certain point, the more secure a
> machine
> is, the more difficult it is to use. It comes to a point where your
> use of
> the computer becomes less and less efficient, and I think you have to
> justify that.

Ok I see your point here, comes back to the argument that the most
secure machine is one encased in concrete and buryied a mile below
ground.
 
> > I do understand both stegFS and RIP. I can agree with you on some
> of
> > the above. They ask for my pass phrase which I give them, they can
> then
> > unlock layer 1, but I can plausibly deny the existance of layers 2
> - 8
> > etc...
> 
> I would bet against you being able to plausibly deny their existence
> :) 

This sounds like a challenge.
 
> Let's say that you've set it up half-decently - no .historys, you've
> made
> sure stuff isn't going into swap, etc. What about application logs?
> You've
> got to turn those off, because otherwise you've logged the fact that
> you've
> edited files which don't exist (by the path they would also know what
> steg
> level it was in). Gotta get rid of those pesky core dumps too,
> although
> hopefully they wouldn't happen too often (nice way a spook could get
> a
> memory snapshot from your system, though, if they had you monitored -
> which
> they would before requested keys under RIP - and were able to crash
> your
> machine remotely). Have to make sure syslog isn't doing anything
> dodgy
> either. And we have to make sure that the stegfs stuff is shut down
> before
> any cron jobs run - they might start grepping our directories for
> cores,
> etc., and leave traces in their logs. 

Application logs, well as someone who works with a history (bash and
netscape) disabled and mainly cli utils I think this can be worked
around, how about links to different sectors.
 
> And that's just system stuff - we haven't even begun to delve into
> other
> areas - such as filesystem ("we notice the pattern of activity on
> this
> filesystem points to the fact you have a number of hidden files you
> haven't
> told us about"). Plus, the fact that you are able to plausibly deny
> (supposedly) the existence of files to authorities means that you are
> also
> able to plausibly deny their existence to the OS (i.e., it will trash
> files), so you're probably going to want to make backups too (this is
> sensitive data, right?), and take some kind of security precaution
> with
> those too...... back to square one...

I take it you have read the documents on the StegFS website? the fact
that you deny the existance to the OS is a feature not a bug, this is
why multipul copies of the encrypted data are stored. Also it has
secure delete, so hidden data and delted data looks the same. As for
backups, these can be stegongraphically encoded again, the existance of
them is then deniable, i.e. encoded in that images CD etc...

Thanks

D

> Cheers,
> 
> Alex.
> 
> -- 
> Gllug mailing list  -  Gllug at linux.co.uk
> http://list.ftech.net/mailman/listinfo/gllug 

____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug