[Cryptography] What do we mean by Secure?

Rob Meijer pibara at gmail.com
Tue Feb 10 02:18:54 EST 2015


2015-02-09 17:23 GMT+01:00 Phillip Hallam-Baker <phill at hallambaker.com>:

>
>
> On Sat, Feb 7, 2015 at 7:05 PM, Bill Frantz <frantz at pwpconsult.com> wrote:
>
>> On 2/6/15 at 3:10 PM, kentborg at borg.org (Kent Borg) wrote:
>>
>>  Ah, but then one would have to stop and figure out what one is trying to
>>> do...damn! Can't I just ask for Wholesome Apple Pie and be done?
>>>
>>
>> The more I hear people talk about making thing secure, the more I hope
>> they will explain what they mean by secure. What I mean, in the broadest
>> sense, is "Bad Things Won't Happen". Now this is a bit over nebulous. :-)
>>
>> In general, we think computers should enforce a policy. But what policy?
>> When I ask this question, the answer I generally get is, "Any policy you
>> want". But there are many policies we can't implement with our current
>> security mechanisms.
>>
>> On our home computers, my wife and my security policy is that both of us
>> should have full ownership permissions on all of our files since the owner
>> is the only one who can change certain meta-data, like who can access the
>> file.. However, on our Unix based systems, a file can have only one owner.
>> Our solution is to share accounts. As far as the computer is concerned,
>> there is only one of us.)
>>
>
> This is the wrong policy. You are never going to open those files, nor is
> your wife. You don't speak binary.
>
> Applications are going to open those files and what matters is that one
> application does not go rogue.
>
> We have the wrong metaphor for applications. They are not static objects,
> they are zombies or gollems . We can give them tasks, but their true
> masters are the wizards that originally brought them to life by their
> incantations.
>
>
> Of course, I don't know of any system that would make such a policy viable.
>


​Unfortunately due to different circumstances that have made me have to
rearrange my spare time and have made me reconsider on the forensic
aspects, I'm more than a year behind schedule so the system does still not
exist, ​but you might find my slides and speaker notes on MinorFS-2 for the
general gist of how a system like that could work at the FS level.

http://ohm2013.capibara.com/

I was hoping the talk would have been available as video by now but
unfortunately the video material for the whole tent+day seems to have been
lost. I tried to make a video myself by narrating the slides, but I seem to
have the opposite of stage fright. While I have no issues speaking before
an audience, I seem unable to speak at my computer without an audience for
30+ minutes narrating the slides without  messing up all the time :-(

The file:

http://ohm2013.capibara.com/slides/ohm2013_trojans_with_notes.pdf

​has gotten all the slides twice, once without and once with the speaker
notes, so if you open that file and forward to slide 59 you should be able
to see both the slides and notes together from there.

The basic idea is that:

* You provide processes with private storage at different granularity
levels.
* ​You provide a private $TEMP to any process.
* By default, anything in the user's directory with a name that starts with
a dot maps to
   user+program granularity (other mappings are possible)
* By default, non dot files and directories map to user granularity (other
mappings are possible)

One thing that is not in the slides is the whole user versus owner problem,
but that's been discussed on this list recently, so the slides should give
you a general idea.

I know the file-system is only part of the rights granularity problem being
locked at the level of the user account, but at least its a start.



> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150210/bea1775e/attachment.html>


More information about the cryptography mailing list