Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.folklore.computers > #148047 > unrolled thread

Re: The joy of simplicity?

Back to article view | Back to alt.folklore.computers

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: The joy of simplicity? Mike Spencer <mds@bogus.nodomain.nowhere> - 2015-07-08 00:27 -0300
    Re: The joy of simplicity? Anne & Lynn Wheeler <lynn@garlic.com> - 2015-07-08 09:32 -0700
      Re: The joy of simplicity? "ratsack" <ratgsack281@nospam.com> - 2015-07-10 05:28 +1000
    Re: The joy of simplicity? hancock4@bbs.cpcn.com - 2015-07-08 09:54 -0700
      Re: The joy of simplicity? scott@slp53.sl.home (Scott Lurndal) - 2015-07-08 17:43 +0000
      Re: The joy of simplicity? Mike Spencer <mds@bogus.nodomain.nowhere> - 2015-07-08 15:48 -0300
        Re: The joy of simplicity? hda <agent700@ay.invalid> - 2015-07-08 22:03 +0200
          Re: The joy of simplicity? Mike Spencer <mds@bogus.nodomain.nowhere> - 2015-07-09 03:14 -0300
            Re: The joy of simplicity? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-07-09 07:38 +0000
            Re: The joy of simplicity? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-07-09 17:40 +0000
            Re: The joy of simplicity? Mike Spencer <mds@bogus.nodomain.nowhere> - 2015-07-09 16:32 -0300
            Re: The joy of simplicity? "ratsack" <ratgsack281@nospam.com> - 2015-07-10 05:35 +1000
            Re: The joy of simplicity? Mike Spencer <mds@bogus.nodomain.nowhere> - 2015-07-09 16:51 -0300
            Re: The joy of simplicity? Andrew Swallow <am.swallow@btinternet.com> - 2015-07-10 00:50 +0100
              Re: The joy of simplicity? Peter Flass <peter_flass@yahoo.com> - 2015-07-10 00:27 +0000
                Re: The joy of simplicity? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-07-10 16:36 +0000
                  Re: The joy of simplicity? Andrew Swallow <am.swallow@btinternet.com> - 2015-07-10 19:01 +0100
                    Re: The joy of simplicity? Stephen Sprunk <stephen@sprunk.org> - 2015-07-10 13:13 -0500
                  Re: The joy of simplicity? Stephen Sprunk <stephen@sprunk.org> - 2015-07-10 13:20 -0500
                  Re: The joy of simplicity? Peter Flass <peter_flass@yahoo.com> - 2015-07-10 18:59 +0000
                    Re: The joy of simplicity? Andrew Swallow <am.swallow@btinternet.com> - 2015-07-10 21:08 +0100
                      Re: The joy of simplicity? Morten Reistad <first@last.navn> - 2015-07-11 00:42 +0200
                        Re: The joy of simplicity? Andrew Swallow <am.swallow@btinternet.com> - 2015-07-11 20:47 +0100
                          Re: The joy of simplicity? jmfbahciv <See.above@aol.com> - 2015-07-12 12:53 +0000
                            Re: The joy of simplicity? "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-07-13 05:40 +1000
                              Re: The joy of simplicity? jmfbahciv <See.above@aol.com> - 2015-07-14 12:02 +0000
                                Re: The joy of simplicity? Andrew Swallow <am.swallow@btinternet.com> - 2015-07-14 13:32 +0100
                                  Re: The joy of simplicity? jmfbahciv <See.above@aol.com> - 2015-07-15 12:19 +0000
                                    Re: The joy of simplicity? Peter Flass <peter_flass@yahoo.com> - 2015-07-15 12:31 +0000
                                      Re: The joy of simplicity? "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-07-17 05:49 +1000
                                        Re: The joy of simplicity? Morten Reistad <first@last.navn> - 2015-07-17 18:43 +0200
                                          Re: The joy of simplicity? "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-07-19 09:01 +1000
                                            Re: The joy of simplicity? jmfbahciv <See.above@aol.com> - 2015-07-19 13:25 +0000
                                              Re: The joy of simplicity? "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-07-20 06:20 +1000
                                                Re: The joy of simplicity? jmfbahciv <See.above@aol.com> - 2015-07-20 13:29 +0000
                                                  Re: The joy of simplicity? Peter Flass <peter_flass@yahoo.com> - 2015-07-20 15:26 +0000
                                                    Re: The joy of simplicity? jmfbahciv <See.above@aol.com> - 2015-07-21 12:53 +0000
                                                  Re: The joy of simplicity? "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-07-21 05:52 +1000
                                          Re: The joy of simplicity? "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-07-19 09:49 +1000
                                          Re: The joy of simplicity? jmfbahciv <See.above@aol.com> - 2015-07-19 13:25 +0000
                                            Re: The joy of simplicity? Morten Reistad <first@last.navn> - 2015-07-19 18:15 +0200
                                              Re: The joy of simplicity? jmfbahciv <See.above@aol.com> - 2015-07-20 13:29 +0000
                                                Re: The joy of simplicity? "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-07-21 05:49 +1000
                                            Re: The joy of simplicity? "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-07-20 06:38 +1000
                                          Re: The joy of simplicity? jmfbahciv <See.above@aol.com> - 2015-07-20 13:29 +0000
                                            Re: The joy of simplicity? "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-07-21 05:55 +1000
                        Re: The joy of simplicity? "Hank" <hfd543@nospam.com> - 2015-07-12 06:00 +1000
                    Re: The joy of simplicity? Morten Reistad <first@last.navn> - 2015-07-11 00:38 +0200
                  Re: The joy of simplicity? "Charles Richmond" <numerist@aquaporin4.com> - 2015-07-10 15:27 -0500
                    Re: The joy of simplicity? Dave Garland <dave.garland@wizinfo.com> - 2015-07-11 00:18 -0500
                      Re: The joy of simplicity? "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-07-11 19:22 +1000
                  Re: The joy of simplicity? Gene Wirchenko <genew@telus.net> - 2015-07-10 17:53 -0700
                    Re: The joy of simplicity? "Osmium" <r124c4u102@comcast.net> - 2015-07-10 22:22 -0500
                      Re: The joy of simplicity? Gene Wirchenko <genew@telus.net> - 2015-07-10 23:39 -0700
            Re: The joy of simplicity? simon@twoplaces.co.uk (Simon Turner) - 2015-07-10 08:27 +0100
      Re: The joy of simplicity? Peter Flass <peter_flass@yahoo.com> - 2015-07-09 00:29 +0000
        Re: The joy of simplicity? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-07-09 07:38 +0000
    Re: The joy of simplicity? Daiyu Hurst <daiyu.hurst@gmail.com> - 2015-07-08 12:57 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#148203

On 10/07/2015 19:59, Peter Flass wrote:
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>> On 2015-07-10, Peter Flass <peter_flass@yahoo.com> wrote:
>>
>>> Andrew Swallow <am.swallow@btinternet.com> wrote:
>>>
>>>> On 09/07/2015 15:20, hancock4@bbs.cpcn.com wrote:
>>>> {snip}
>>>>
>>>>> Unfortunately, if you disable stuff, most websites simply won't work,
>>>>> or even won't let you access them.  If you have an old version of
>>>>> I/E, there are sites that block you from entering.
>>>>
>>>> The US Government is big enough and powerful enough to say make you
>>>> website work with our secure browser or our agencies and suppliers
>>>> will not work with you.
>>>
>>> They need a secure browser first, and I don't think such a beast exists.
>>> Security conflicts with a major goal of the internet project -openness.
>>
>> Still, there's nothing that says an open-source system can't be secure,
>> provided you keep the keys secret.  Knowing how a lock works doesn't
>> automatically mean you can crack it.  And what's the alternative?
>> Certainly not closed source, which can contain all sorts of back doors
>> whose existence can never be disproved.  "Security through obscurity"
>> has been pretty much discredited (except among True Believers, of course).
>
> The problem is you have to secure a lot of things.  Obviously javascript
> and java are out, unless it would be acceptable to download stuff from
> approved sites.  Flash is out.  What else is commonly used that would have
> to be redesigned to be secure?
>
>
Self playing things will have to go. Nothing executable from the internet.
A (new?) video format will need choosing. No holes in it.
Take the programmable macro facilities out of word processors and other 
office software. (Facilities like search, formatting and spelling 
checking will have to be coded into the source code.)

[toc] | [prev] | [next] | [standalone]

#148219

In article <ILWdnVDmvrKguz3InZ2dnUU78WednZ2d@giganews.com>,
Andrew Swallow  <am.swallow@btinternet.com> wrote:
>On 10/07/2015 19:59, Peter Flass wrote:
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>> On 2015-07-10, Peter Flass <peter_flass@yahoo.com> wrote:
>>>
>>>> Andrew Swallow <am.swallow@btinternet.com> wrote:
>>>>
>>>>> On 09/07/2015 15:20, hancock4@bbs.cpcn.com wrote:
>>>>> {snip}
>>>>>
>>>>>> Unfortunately, if you disable stuff, most websites simply won't work,
>>>>>> or even won't let you access them.  If you have an old version of
>>>>>> I/E, there are sites that block you from entering.
>>>>>
>>>>> The US Government is big enough and powerful enough to say make you
>>>>> website work with our secure browser or our agencies and suppliers
>>>>> will not work with you.
>>>>
>>>> They need a secure browser first, and I don't think such a beast exists.
>>>> Security conflicts with a major goal of the internet project -openness.
>>>
>>> Still, there's nothing that says an open-source system can't be secure,
>>> provided you keep the keys secret.  Knowing how a lock works doesn't
>>> automatically mean you can crack it.  And what's the alternative?
>>> Certainly not closed source, which can contain all sorts of back doors
>>> whose existence can never be disproved.  "Security through obscurity"
>>> has been pretty much discredited (except among True Believers, of course).
>>
>> The problem is you have to secure a lot of things.  Obviously javascript
>> and java are out, unless it would be acceptable to download stuff from
>> approved sites.  Flash is out.  What else is commonly used that would have
>> to be redesigned to be secure?
>>
>>
>Self playing things will have to go. Nothing executable from the internet.
>A (new?) video format will need choosing. No holes in it.
>Take the programmable macro facilities out of word processors and other 
>office software. (Facilities like search, formatting and spelling 
>checking will have to be coded into the source code.)


Good luck. 

There will always be some programmatic device that slips through the
mesh. Like all the lua-enabled systems.

Better to let them play out in a sandbox, where you set the execution
environment to be a safe one that can at the very worst use cpu cycles, 
send bits to and from the network, and do a dos attack against itself.

-- mrr

[toc] | [prev] | [next] | [standalone]

#148224

On 10/07/2015 23:42, Morten Reistad wrote:
> In article <ILWdnVDmvrKguz3InZ2dnUU78WednZ2d@giganews.com>,
> Andrew Swallow  <am.swallow@btinternet.com> wrote:
>> On 10/07/2015 19:59, Peter Flass wrote:
>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>>> On 2015-07-10, Peter Flass <peter_flass@yahoo.com> wrote:
>>>>
>>>>> Andrew Swallow <am.swallow@btinternet.com> wrote:
>>>>>
>>>>>> On 09/07/2015 15:20, hancock4@bbs.cpcn.com wrote:
>>>>>> {snip}
>>>>>>
>>>>>>> Unfortunately, if you disable stuff, most websites simply won't work,
>>>>>>> or even won't let you access them.  If you have an old version of
>>>>>>> I/E, there are sites that block you from entering.
>>>>>>
>>>>>> The US Government is big enough and powerful enough to say make you
>>>>>> website work with our secure browser or our agencies and suppliers
>>>>>> will not work with you.
>>>>>
>>>>> They need a secure browser first, and I don't think such a beast exists.
>>>>> Security conflicts with a major goal of the internet project -openness.
>>>>
>>>> Still, there's nothing that says an open-source system can't be secure,
>>>> provided you keep the keys secret.  Knowing how a lock works doesn't
>>>> automatically mean you can crack it.  And what's the alternative?
>>>> Certainly not closed source, which can contain all sorts of back doors
>>>> whose existence can never be disproved.  "Security through obscurity"
>>>> has been pretty much discredited (except among True Believers, of course).
>>>
>>> The problem is you have to secure a lot of things.  Obviously javascript
>>> and java are out, unless it would be acceptable to download stuff from
>>> approved sites.  Flash is out.  What else is commonly used that would have
>>> to be redesigned to be secure?
>>>
>>>
>> Self playing things will have to go. Nothing executable from the internet.
>> A (new?) video format will need choosing. No holes in it.
>> Take the programmable macro facilities out of word processors and other
>> office software. (Facilities like search, formatting and spelling
>> checking will have to be coded into the source code.)
>
>
> Good luck.
>
> There will always be some programmatic device that slips through the
> mesh. Like all the lua-enabled systems.
>
> Better to let them play out in a sandbox, where you set the execution
> environment to be a safe one that can at the very worst use cpu cycles,
> send bits to and from the network, and do a dos attack against itself.
>
> -- mrr
>

This will help but unfortunately the database you are keeping secret 
ends up inside the sandbox.

[toc] | [prev] | [next] | [standalone]

#148230

Andrew Swallow wrote:
> On 10/07/2015 23:42, Morten Reistad wrote:
>> In article <ILWdnVDmvrKguz3InZ2dnUU78WednZ2d@giganews.com>,
>> Andrew Swallow  <am.swallow@btinternet.com> wrote:
>>> On 10/07/2015 19:59, Peter Flass wrote:
>>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>>>> On 2015-07-10, Peter Flass <peter_flass@yahoo.com> wrote:
>>>>>
>>>>>> Andrew Swallow <am.swallow@btinternet.com> wrote:
>>>>>>
>>>>>>> On 09/07/2015 15:20, hancock4@bbs.cpcn.com wrote:
>>>>>>> {snip}
>>>>>>>
>>>>>>>> Unfortunately, if you disable stuff, most websites simply won't work,
>>>>>>>> or even won't let you access them.  If you have an old version of
>>>>>>>> I/E, there are sites that block you from entering.
>>>>>>>
>>>>>>> The US Government is big enough and powerful enough to say make you
>>>>>>> website work with our secure browser or our agencies and suppliers
>>>>>>> will not work with you.
>>>>>>
>>>>>> They need a secure browser first, and I don't think such a beast
exists.
>>>>>> Security conflicts with a major goal of the internet project -openness.
>>>>>
>>>>> Still, there's nothing that says an open-source system can't be secure,
>>>>> provided you keep the keys secret.  Knowing how a lock works doesn't
>>>>> automatically mean you can crack it.  And what's the alternative?
>>>>> Certainly not closed source, which can contain all sorts of back doors
>>>>> whose existence can never be disproved.  "Security through obscurity"
>>>>> has been pretty much discredited (except among True Believers, of
course).
>>>>
>>>> The problem is you have to secure a lot of things.  Obviously javascript
>>>> and java are out, unless it would be acceptable to download stuff from
>>>> approved sites.  Flash is out.  What else is commonly used that would
have
>>>> to be redesigned to be secure?
>>>>
>>>>
>>> Self playing things will have to go. Nothing executable from the internet.
>>> A (new?) video format will need choosing. No holes in it.
>>> Take the programmable macro facilities out of word processors and other
>>> office software. (Facilities like search, formatting and spelling
>>> checking will have to be coded into the source code.)
>>
>>
>> Good luck.
>>
>> There will always be some programmatic device that slips through the
>> mesh. Like all the lua-enabled systems.
>>
>> Better to let them play out in a sandbox, where you set the execution
>> environment to be a safe one that can at the very worst use cpu cycles,
>> send bits to and from the network, and do a dos attack against itself.
>>
>> -- mrr
>>
>
> This will help but unfortunately the database you are keeping secret
> ends up inside the sandbox.

Implement a file daemon like we did on TOPS-10.

/BAH

[toc] | [prev] | [next] | [standalone]

#148238

"jmfbahciv" <See.above@aol.com> wrote in message 
news:PM00051AAD3E31090D@aca46c7b.ipt.aol.com...
> Andrew Swallow wrote:
>> On 10/07/2015 23:42, Morten Reistad wrote:
>>> In article <ILWdnVDmvrKguz3InZ2dnUU78WednZ2d@giganews.com>,
>>> Andrew Swallow  <am.swallow@btinternet.com> wrote:
>>>> On 10/07/2015 19:59, Peter Flass wrote:
>>>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>>>>> On 2015-07-10, Peter Flass <peter_flass@yahoo.com> wrote:
>>>>>>
>>>>>>> Andrew Swallow <am.swallow@btinternet.com> wrote:
>>>>>>>
>>>>>>>> On 09/07/2015 15:20, hancock4@bbs.cpcn.com wrote:
>>>>>>>> {snip}
>>>>>>>>
>>>>>>>>> Unfortunately, if you disable stuff, most websites simply won't 
>>>>>>>>> work,
>>>>>>>>> or even won't let you access them.  If you have an old version of
>>>>>>>>> I/E, there are sites that block you from entering.
>>>>>>>>
>>>>>>>> The US Government is big enough and powerful enough to say make you
>>>>>>>> website work with our secure browser or our agencies and suppliers
>>>>>>>> will not work with you.
>>>>>>>
>>>>>>> They need a secure browser first, and I don't think such a beast
> exists.
>>>>>>> Security conflicts with a major goal of the internet 
>>>>>>> project -openness.
>>>>>>
>>>>>> Still, there's nothing that says an open-source system can't be 
>>>>>> secure,
>>>>>> provided you keep the keys secret.  Knowing how a lock works doesn't
>>>>>> automatically mean you can crack it.  And what's the alternative?
>>>>>> Certainly not closed source, which can contain all sorts of back 
>>>>>> doors
>>>>>> whose existence can never be disproved.  "Security through obscurity"
>>>>>> has been pretty much discredited (except among True Believers, of
> course).
>>>>>
>>>>> The problem is you have to secure a lot of things.  Obviously 
>>>>> javascript
>>>>> and java are out, unless it would be acceptable to download stuff from
>>>>> approved sites.  Flash is out.  What else is commonly used that would
> have
>>>>> to be redesigned to be secure?
>>>>>
>>>>>
>>>> Self playing things will have to go. Nothing executable from the 
>>>> internet.
>>>> A (new?) video format will need choosing. No holes in it.
>>>> Take the programmable macro facilities out of word processors and other
>>>> office software. (Facilities like search, formatting and spelling
>>>> checking will have to be coded into the source code.)
>>>
>>>
>>> Good luck.
>>>
>>> There will always be some programmatic device that slips through the
>>> mesh. Like all the lua-enabled systems.
>>>
>>> Better to let them play out in a sandbox, where you set the execution
>>> environment to be a safe one that can at the very worst use cpu cycles,
>>> send bits to and from the network, and do a dos attack against itself.
>>>
>>> -- mrr
>>>
>>
>> This will help but unfortunately the database you are keeping secret
>> ends up inside the sandbox.
>
> Implement a file daemon like we did on TOPS-10.

Doesn’t do a damned thing about the problem he is talking about. 

[toc] | [prev] | [next] | [standalone]

#148246

Rod Speed wrote:
>
>
> "jmfbahciv" <See.above@aol.com> wrote in message
> news:PM00051AAD3E31090D@aca46c7b.ipt.aol.com...
>> Andrew Swallow wrote:
>>> On 10/07/2015 23:42, Morten Reistad wrote:
>>>> In article <ILWdnVDmvrKguz3InZ2dnUU78WednZ2d@giganews.com>,
>>>> Andrew Swallow  <am.swallow@btinternet.com> wrote:
>>>>> On 10/07/2015 19:59, Peter Flass wrote:
>>>>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>>>>>> On 2015-07-10, Peter Flass <peter_flass@yahoo.com> wrote:
>>>>>>>
>>>>>>>> Andrew Swallow <am.swallow@btinternet.com> wrote:
>>>>>>>>
>>>>>>>>> On 09/07/2015 15:20, hancock4@bbs.cpcn.com wrote:
>>>>>>>>> {snip}
>>>>>>>>>
>>>>>>>>>> Unfortunately, if you disable stuff, most websites simply won't
>>>>>>>>>> work,
>>>>>>>>>> or even won't let you access them.  If you have an old version of
>>>>>>>>>> I/E, there are sites that block you from entering.
>>>>>>>>>
>>>>>>>>> The US Government is big enough and powerful enough to say make you
>>>>>>>>> website work with our secure browser or our agencies and suppliers
>>>>>>>>> will not work with you.
>>>>>>>>
>>>>>>>> They need a secure browser first, and I don't think such a beast
>> exists.
>>>>>>>> Security conflicts with a major goal of the internet
>>>>>>>> project -openness.
>>>>>>>
>>>>>>> Still, there's nothing that says an open-source system can't be
>>>>>>> secure,
>>>>>>> provided you keep the keys secret.  Knowing how a lock works doesn't
>>>>>>> automatically mean you can crack it.  And what's the alternative?
>>>>>>> Certainly not closed source, which can contain all sorts of back
>>>>>>> doors
>>>>>>> whose existence can never be disproved.  "Security through obscurity"
>>>>>>> has been pretty much discredited (except among True Believers, of
>> course).
>>>>>>
>>>>>> The problem is you have to secure a lot of things.  Obviously
>>>>>> javascript
>>>>>> and java are out, unless it would be acceptable to download stuff from
>>>>>> approved sites.  Flash is out.  What else is commonly used that would
>> have
>>>>>> to be redesigned to be secure?
>>>>>>
>>>>>>
>>>>> Self playing things will have to go. Nothing executable from the
>>>>> internet.
>>>>> A (new?) video format will need choosing. No holes in it.
>>>>> Take the programmable macro facilities out of word processors and other
>>>>> office software. (Facilities like search, formatting and spelling
>>>>> checking will have to be coded into the source code.)
>>>>
>>>>
>>>> Good luck.
>>>>
>>>> There will always be some programmatic device that slips through the
>>>> mesh. Like all the lua-enabled systems.
>>>>
>>>> Better to let them play out in a sandbox, where you set the execution
>>>> environment to be a safe one that can at the very worst use cpu cycles,
>>>> send bits to and from the network, and do a dos attack against itself.
>>>>
>>>> -- mrr
>>>>
>>>
>>> This will help but unfortunately the database you are keeping secret
>>> ends up inside the sandbox.
>>
>> Implement a file daemon like we did on TOPS-10.
>
> Doesn’t do a damned thing about the problem he is talking about.

Of course it can.  The file daemone can do anything one wants it to.
In order to circumvent the security, a cracker has to patch the monitor
to redirect the IPCF messages _and_ its contents.

/BAH

>

[toc] | [prev] | [next] | [standalone]

#148248

On 14/07/2015 13:02, jmfbahciv wrote:
> Rod Speed wrote:
>>
>>
>> "jmfbahciv" <See.above@aol.com> wrote in message
>> news:PM00051AAD3E31090D@aca46c7b.ipt.aol.com...
>>> Andrew Swallow wrote:
{snip}

>>>>
>>>> This will help but unfortunately the database you are keeping secret
>>>> ends up inside the sandbox.
>>>
>>> Implement a file daemon like we did on TOPS-10.
>>
>> Doesn’t do a damned thing about the problem he is talking about.
>
> Of course it can.  The file daemone can do anything one wants it to.
> In order to circumvent the security, a cracker has to patch the monitor
> to redirect the IPCF messages _and_ its contents.
>
> /BAH
>
Can the virus tell the daemone to get the next database record?
If so repeat until the entire database has been extracted.

[toc] | [prev] | [next] | [standalone]

#148275

Andrew Swallow wrote:
> On 14/07/2015 13:02, jmfbahciv wrote:
>> Rod Speed wrote:
>>>
>>>
>>> "jmfbahciv" <See.above@aol.com> wrote in message
>>> news:PM00051AAD3E31090D@aca46c7b.ipt.aol.com...
>>>> Andrew Swallow wrote:
> {snip}
>
>>>>>
>>>>> This will help but unfortunately the database you are keeping secret
>>>>> ends up inside the sandbox.
>>>>
>>>> Implement a file daemon like we did on TOPS-10.
>>>
>>> Doesn’t do a damned thing about the problem he is talking about.
>>
>> Of course it can.  The file daemone can do anything one wants it to.
>> In order to circumvent the security, a cracker has to patch the monitor
>> to redirect the IPCF messages _and_ its contents.
>>
>> /BAH
>>
> Can the virus tell the daemone to get the next database record?
> If so repeat until the entire database has been extracted.
>
Only if the file daemon is designed to allow such access without security.

Using a file daemon to access otherwise protected files from a user,
including an app, allows access without the user/app having to have
the system privileges one would need if a daemon wasn't available.

The sample JMF wrote, was designed to extend access to files.  There isn't
anything preventing a daemon from accessing the contents of files.
The neat thing was that you could protect a file from [1,2] accessing
it.  [1,2] was the equivalent user to Unix' sudo (I think that's what
it's called.)

/BAH

[toc] | [prev] | [next] | [standalone]

#148276

jmfbahciv <See.above@aol.com> wrote:
> Andrew Swallow wrote:
>> On 14/07/2015 13:02, jmfbahciv wrote:
>>> Rod Speed wrote:
>>>> 
>>>> 
>>>> "jmfbahciv" <See.above@aol.com> wrote in message
>>>> news:PM00051AAD3E31090D@aca46c7b.ipt.aol.com...
>>>>> Andrew Swallow wrote:
>> {snip}
>> 
>>>>>> 
>>>>>> This will help but unfortunately the database you are keeping secret
>>>>>> ends up inside the sandbox.
>>>>> 
>>>>> Implement a file daemon like we did on TOPS-10.
>>>> 
>>>> Doesn’t do a damned thing about the problem he is talking about.
>>> 
>>> Of course it can.  The file daemone can do anything one wants it to.
>>> In order to circumvent the security, a cracker has to patch the monitor
>>> to redirect the IPCF messages _and_ its contents.
>>> 
>>> /BAH
>>> 
>> Can the virus tell the daemone to get the next database record?
>> If so repeat until the entire database has been extracted.
>> 
> Only if the file daemon is designed to allow such access without security.
> 
> Using a file daemon to access otherwise protected files from a user,
> including an app, allows access without the user/app having to have
> the system privileges one would need if a daemon wasn't available.
> 
> The sample JMF wrote, was designed to extend access to files.  There isn't
> anything preventing a daemon from accessing the contents of files.
> The neat thing was that you could protect a file from [1,2] accessing
> it.  [1,2] was the equivalent user to Unix' sudo (I think that's what
> it's called.)
> 

A daemon has nothing to do with this. The file system has to run at a
higher privilege level (which most do) and have no bugs or security holes
(which doesn't seem to be true).  The problem seems to be that unauthorized
code takes advantage of holes in the system get an elevated privilege level
and access things it shouldn't.

-- 
Pete

[toc] | [prev] | [next] | [standalone]

#148321

"jmfbahciv" <See.above@aol.com> wrote in message 
news:PM00051AFE21B80058@aca42e0b.ipt.aol.com...
> Peter Flass wrote:
>> jmfbahciv <See.above@aol.com> wrote:
>>> Andrew Swallow wrote:
>>>> On 14/07/2015 13:02, jmfbahciv wrote:
>>>>> Rod Speed wrote:
>>>>>>
>>>>>>
>>>>>> "jmfbahciv" <See.above@aol.com> wrote in message
>>>>>> news:PM00051AAD3E31090D@aca46c7b.ipt.aol.com...
>>>>>>> Andrew Swallow wrote:
>>>> {snip}
>>>>
>>>>>>>>
>>>>>>>> This will help but unfortunately the database you are keeping 
>>>>>>>> secret
>>>>>>>> ends up inside the sandbox.
>>>>>>>
>>>>>>> Implement a file daemon like we did on TOPS-10.
>>>>>>
>>>>>> Doesn’t do a damned thing about the problem he is talking about.
>>>>>
>>>>> Of course it can.  The file daemone can do anything one wants it to.
>>>>> In order to circumvent the security, a cracker has to patch the 
>>>>> monitor
>>>>> to redirect the IPCF messages _and_ its contents.
>>>>>
>>>>> /BAH
>>>>>
>>>> Can the virus tell the daemone to get the next database record?
>>>> If so repeat until the entire database has been extracted.
>>>>
>>> Only if the file daemon is designed to allow such access without 
>>> security.
>>>
>>> Using a file daemon to access otherwise protected files from a user,
>>> including an app, allows access without the user/app having to have
>>> the system privileges one would need if a daemon wasn't available.
>>>
>>> The sample JMF wrote, was designed to extend access to files.  There 
>>> isn't
>>> anything preventing a daemon from accessing the contents of files.
>>> The neat thing was that you could protect a file from [1,2] accessing
>>> it.  [1,2] was the equivalent user to Unix' sudo (I think that's what
>>> it's called.)
>>>
>>
>> A daemon has nothing to do with this. The file system has to run at a
>> higher privilege level (which most do) and have no bugs or security holes
>> (which doesn't seem to be true).  The problem seems to be that 
>> unauthorized
>> code takes advantage of holes in the system get an elevated privilege 
>> level
>> and access things it shouldn't.
>
> If you have a file daemon, you can protect all files and directories from
> any access at all times.

There you go, utterly mangling the terminology just like you always do.

> when an access fails, the file daemon can be called to decide
> if access should be allowed.

But it needs to have some basis for making that decision.

> With that you can have MBs of code examining the situation and making
> decisions.  What's more you could also create sectors of file daemons
> called by the master file daemon.  A lot of protections on the PDP-10s
> were built into the way we handled [P,PN]s.  ppn protections were
> stricter and easier than access ids which were names.

That last isn't the problem being discussed.

And iOS essentially does what you are talking about and
so utterly misnamed by sandboxing so nothing gets access
to the data that belongs to an app except the app itself and
with stuff like the contacts where more than one app needs
to have access to some of the data at times, the user gets
to authorise access by other than the app that owns the data.

Its never going to be possible for 'a file daemon' to decide
just what need to have access to stuff like the contacts. 

[toc] | [prev] | [next] | [standalone]

#148394

In article <d0qg66Fqs5uU1@mid.individual.net>,
Rod Speed <rod.speed.aaa@gmail.com> wrote:
>
>
>"jmfbahciv" <See.above@aol.com> wrote in message 
>news:PM00051AFE21B80058@aca42e0b.ipt.aol.com...
>> Peter Flass wrote:
>>> jmfbahciv <See.above@aol.com> wrote:
>>>> Andrew Swallow wrote:
>>>>> On 14/07/2015 13:02, jmfbahciv wrote:
>>>>>> Rod Speed wrote:
>>>>>>>
>>>>>>>
>>>>>>> "jmfbahciv" <See.above@aol.com> wrote in message
>>>>>>> news:PM00051AAD3E31090D@aca46c7b.ipt.aol.com...
>>>>>>>> Andrew Swallow wrote:
>>>>> {snip}
>>>>>
>>>>>>>>>
>>>>>>>>> This will help but unfortunately the database you are keeping 
>>>>>>>>> secret
>>>>>>>>> ends up inside the sandbox.
>>>>>>>>
>>>>>>>> Implement a file daemon like we did on TOPS-10.
>>>>>>>
>>>>>>> Doesn’t do a damned thing about the problem he is talking about.
>>>>>>
>>>>>> Of course it can.  The file daemone can do anything one wants it to.
>>>>>> In order to circumvent the security, a cracker has to patch the 
>>>>>> monitor
>>>>>> to redirect the IPCF messages _and_ its contents.
>>>>>>
>>>>>> /BAH
>>>>>>
>>>>> Can the virus tell the daemone to get the next database record?
>>>>> If so repeat until the entire database has been extracted.
>>>>>
>>>> Only if the file daemon is designed to allow such access without 
>>>> security.
>>>>
>>>> Using a file daemon to access otherwise protected files from a user,
>>>> including an app, allows access without the user/app having to have
>>>> the system privileges one would need if a daemon wasn't available.
>>>>
>>>> The sample JMF wrote, was designed to extend access to files.  There 
>>>> isn't
>>>> anything preventing a daemon from accessing the contents of files.
>>>> The neat thing was that you could protect a file from [1,2] accessing
>>>> it.  [1,2] was the equivalent user to Unix' sudo (I think that's what
>>>> it's called.)
>>>>
>>>
>>> A daemon has nothing to do with this. The file system has to run at a
>>> higher privilege level (which most do) and have no bugs or security holes
>>> (which doesn't seem to be true).  The problem seems to be that 
>>> unauthorized
>>> code takes advantage of holes in the system get an elevated privilege 
>>> level
>>> and access things it shouldn't.
>>
>> If you have a file daemon, you can protect all files and directories from
>> any access at all times.
>
>There you go, utterly mangling the terminology just like you always do.

No, she has just given some references to som DEC systems that have
fallen into disuse.

Both tops10 and tops20 have decent file protection primitives (contrasted
to *n*x native and windows). They are almost as good as the multics ones
from the later versions. 

In addition you could connect a user mode process to a partition, and have
the failed requests come in for a secondary view, and you could permit them
anyhow. If you wanted every open request to go through that daemon you just
set permissions 000 (unix-speak) on the mount point.

These user mode daemons handle open()s, and set the subsequent read(), 
write(), append() and select()/poll() permissions on the file handle as long
as it is kept open.

This is one solution to the jail-process-problem, but I think the 
jail() version of chroot() is a much better one. For one, you have a 
system-provided check that you stay within your jail on every (of ~150)
system call the process performs. This limits the scope of the external
impact from every program executed within that process. 

>> when an access fails, the file daemon can be called to decide
>> if access should be allowed.
>
>But it needs to have some basis for making that decision.
>
>> With that you can have MBs of code examining the situation and making
>> decisions.  What's more you could also create sectors of file daemons
>> called by the master file daemon.  A lot of protections on the PDP-10s
>> were built into the way we handled [P,PN]s.  ppn protections were
>> stricter and easier than access ids which were names.
>
>That last isn't the problem being discussed.
>
>And iOS essentially does what you are talking about and
>so utterly misnamed by sandboxing so nothing gets access
>to the data that belongs to an app except the app itself and
>with stuff like the contacts where more than one app needs
>to have access to some of the data at times, the user gets
>to authorise access by other than the app that owns the data.
>
>Its never going to be possible for 'a file daemon' to decide
>just what need to have access to stuff like the contacts. 

Don't dismiss it outright. I have seen user-mode file systems do
similar things on modern systems.

-- mrr

[toc] | [prev] | [next] | [standalone]

#148487

Morten Reistad <first@last.navn> wrote
> Rod Speed <rod.speed.aaa@gmail.com> wrote
>> jmfbahciv <See.above@aol.com> wrote
>>> Peter Flass wrote
>>>> jmfbahciv <See.above@aol.com> wrote
>>>>> Andrew Swallow wrote
>>>>>> jmfbahciv wrote
>>>>>>> Rod Speed wrote
>>>>>>>> jmfbahciv <See.above@aol.com> wrote
>>>>>>>>> Andrew Swallow wrote

>>>>>>>>>> This will help but unfortunately the database you
>>>>>>>>>> are keeping secret ends up inside the sandbox.

>>>>>>>>> Implement a file daemon like we did on TOPS-10.

>>>>>>>> Doesn't do a damned thing about the problem he is talking about.

>>>>>>> Of course it can.  The file daemone can do anything one wants
>>>>>>> it to. In order to circumvent the security, a cracker has to patch
>>>>>>> the monitor to redirect the IPCF messages _and_ its contents.

>>>>>> Can the virus tell the daemone to get the next database record?
>>>>>> If so repeat until the entire database has been extracted.

>>>>> Only if the file daemon is designed to allow such access without 
>>>>> security.

>>>>> Using a file daemon to access otherwise protected files from a user,
>>>>> including an app, allows access without the user/app having to have
>>>>> the system privileges one would need if a daemon wasn't available.

>>>>> The sample JMF wrote, was designed to extend access to files.
>>>>> There isn't anything preventing a daemon from accessing the
>>>>> contents of files. The neat thing was that you could protect a
>>>>> file from [1,2] accessing it.  [1,2] was the equivalent user to
>>>>> Unix' sudo (I think that's what it's called.)

>>>> A daemon has nothing to do with this. The file system has to run
>>>> at a higher privilege level (which most do) and have no bugs or
>>>> security holes (which doesn't seem to be true).  The problem seems
>>>> to be that unauthorized code takes advantage of holes in the system
>>>> get an elevated privilege level and access things it shouldn't.

>>> If you have a file daemon, you can protect all files
>>> and directories from any access at all times.

>> There you go, utterly mangling the terminology just like you always do.

> No, she has just given some references to
> som DEC systems that have fallen into disuse.

She isn't doing that in this case with her claim that 'you can
protect all files and directories from any access at all times'

> Both tops10 and tops20 have decent file protection
> primitives (contrasted to *n*x native and windows).

Yes, but it’s a lie to claim that 'you can protect all
files and directories from any access at all times'

> They are almost as good as the multics ones from the later versions.

> In addition you could connect a user mode process to a partition, and
> have the failed requests come in for a secondary view, and you could
> permit them anyhow. If you wanted every open request to go through
> that daemon you just set permissions 000 (unix-speak) on the mount point.

> These user mode daemons handle open()s, and set the subsequent read(),
> write(), append() and select()/poll() permissions on the file handle as 
> long
> as it is kept open.

But that is nothing like her claim that 'you can protect
all files and directories from any access at all times'

> This is one solution to the jail-process-problem, but I think the
> jail() version of chroot() is a much better one. For one, you have a
> system-provided check that you stay within your jail on every (of ~150)
> system call the process performs. This limits the scope of the external
> impact from every program executed within that process.

>>> when an access fails, the file daemon can be
>>> called to decide if access should be allowed.

>> But it needs to have some basis for making that decision.

>>> With that you can have MBs of code examining the situation and making
>>> decisions.  What's more you could also create sectors of file daemons
>>> called by the master file daemon.  A lot of protections on the PDP-10s
>>> were built into the way we handled [P,PN]s.  ppn protections were
>>> stricter and easier than access ids which were names.

>> That last isn't the problem being discussed.

>> And iOS essentially does what you are talking about and
>> so utterly misnamed by sandboxing so nothing gets access
>> to the data that belongs to an app except the app itself and
>> with stuff like the contacts where more than one app needs
>> to have access to some of the data at times, the user gets
>> to authorise access by other than the app that owns the data.

>> Its never going to be possible for 'a file daemon' to decide
>> just what need to have access to stuff like the contacts.

> Don't dismiss it outright.

I was only dismissing the claim that 'you can protect all
files and directories from any access at all times' outright.

> I have seen user-mode file systems do
> similar things on modern systems.

Sure, but still nothing like 'you can protect all
files and directories from any access at all times'
 

[toc] | [prev] | [next] | [standalone]

#148505

Rod Speed wrote:
> Morten Reistad <first@last.navn> wrote
>> Rod Speed <rod.speed.aaa@gmail.com> wrote
>>> jmfbahciv <See.above@aol.com> wrote
>>>> Peter Flass wrote
>>>>> jmfbahciv <See.above@aol.com> wrote
>>>>>> Andrew Swallow wrote
>>>>>>> jmfbahciv wrote
>>>>>>>> Rod Speed wrote
>>>>>>>>> jmfbahciv <See.above@aol.com> wrote
>>>>>>>>>> Andrew Swallow wrote
>
>>>>>>>>>>> This will help but unfortunately the database you
>>>>>>>>>>> are keeping secret ends up inside the sandbox.
>
>>>>>>>>>> Implement a file daemon like we did on TOPS-10.
>
>>>>>>>>> Doesn't do a damned thing about the problem he is talking about.
>
>>>>>>>> Of course it can.  The file daemone can do anything one wants
>>>>>>>> it to. In order to circumvent the security, a cracker has to patch
>>>>>>>> the monitor to redirect the IPCF messages _and_ its contents.
>
>>>>>>> Can the virus tell the daemone to get the next database record?
>>>>>>> If so repeat until the entire database has been extracted.
>
>>>>>> Only if the file daemon is designed to allow such access without
>>>>>> security.
>
>>>>>> Using a file daemon to access otherwise protected files from a user,
>>>>>> including an app, allows access without the user/app having to have
>>>>>> the system privileges one would need if a daemon wasn't available.
>
>>>>>> The sample JMF wrote, was designed to extend access to files.
>>>>>> There isn't anything preventing a daemon from accessing the
>>>>>> contents of files. The neat thing was that you could protect a
>>>>>> file from [1,2] accessing it.  [1,2] was the equivalent user to
>>>>>> Unix' sudo (I think that's what it's called.)
>
>>>>> A daemon has nothing to do with this. The file system has to run
>>>>> at a higher privilege level (which most do) and have no bugs or
>>>>> security holes (which doesn't seem to be true).  The problem seems
>>>>> to be that unauthorized code takes advantage of holes in the system
>>>>> get an elevated privilege level and access things it shouldn't.
>
>>>> If you have a file daemon, you can protect all files
>>>> and directories from any access at all times.
>
>>> There you go, utterly mangling the terminology just like you always do.
>
>> No, she has just given some references to
>> som DEC systems that have fallen into disuse.
>
> She isn't doing that in this case with her claim that 'you can
> protect all files and directories from any access at all times'

I did this every day at work.  Even the god ppn [1,2] couldn't access
my files if I didn't want them to.  The ones I did allow to access
left a log in my directory.

<snip>

/BAH

[toc] | [prev] | [next] | [standalone]

#148545

"jmfbahciv" <See.above@aol.com> wrote in message 
news:PM00051B39D5D75EA9@aca2e736.ipt.aol.com...
> Rod Speed wrote:
>> Morten Reistad <first@last.navn> wrote
>>> Rod Speed <rod.speed.aaa@gmail.com> wrote
>>>> jmfbahciv <See.above@aol.com> wrote
>>>>> Peter Flass wrote
>>>>>> jmfbahciv <See.above@aol.com> wrote
>>>>>>> Andrew Swallow wrote
>>>>>>>> jmfbahciv wrote
>>>>>>>>> Rod Speed wrote
>>>>>>>>>> jmfbahciv <See.above@aol.com> wrote
>>>>>>>>>>> Andrew Swallow wrote
>>
>>>>>>>>>>>> This will help but unfortunately the database you
>>>>>>>>>>>> are keeping secret ends up inside the sandbox.
>>
>>>>>>>>>>> Implement a file daemon like we did on TOPS-10.
>>
>>>>>>>>>> Doesn't do a damned thing about the problem he is talking about.
>>
>>>>>>>>> Of course it can.  The file daemone can do anything one wants
>>>>>>>>> it to. In order to circumvent the security, a cracker has to patch
>>>>>>>>> the monitor to redirect the IPCF messages _and_ its contents.
>>
>>>>>>>> Can the virus tell the daemone to get the next database record?
>>>>>>>> If so repeat until the entire database has been extracted.
>>
>>>>>>> Only if the file daemon is designed to allow such access without
>>>>>>> security.
>>
>>>>>>> Using a file daemon to access otherwise protected files from a user,
>>>>>>> including an app, allows access without the user/app having to have
>>>>>>> the system privileges one would need if a daemon wasn't available.
>>
>>>>>>> The sample JMF wrote, was designed to extend access to files.
>>>>>>> There isn't anything preventing a daemon from accessing the
>>>>>>> contents of files. The neat thing was that you could protect a
>>>>>>> file from [1,2] accessing it.  [1,2] was the equivalent user to
>>>>>>> Unix' sudo (I think that's what it's called.)
>>
>>>>>> A daemon has nothing to do with this. The file system has to run
>>>>>> at a higher privilege level (which most do) and have no bugs or
>>>>>> security holes (which doesn't seem to be true).  The problem seems
>>>>>> to be that unauthorized code takes advantage of holes in the system
>>>>>> get an elevated privilege level and access things it shouldn't.
>>
>>>>> If you have a file daemon, you can protect all files
>>>>> and directories from any access at all times.
>>
>>>> There you go, utterly mangling the terminology just like you always do.
>>
>>> No, she has just given some references to
>>> som DEC systems that have fallen into disuse.
>>
>> She isn't doing that in this case with her claim that 'you can
>> protect all files and directories from any access at all times'

> I did this every day at work.

You never protected' all files and directories from any access at all times'

> Even the god ppn [1,2] couldn't access my files if I didn't want them to.

That is nothing even remotely like 'all files
and directories from any access at all times'

> The ones I did allow to access left a log in my directory.

Not true of other access to other files. And that approach
requires someone or something to check those logs anyway. 

[toc] | [prev] | [next] | [standalone]

#148605

Rod Speed wrote:
>
>
> "jmfbahciv" <See.above@aol.com> wrote in message
> news:PM00051B39D5D75EA9@aca2e736.ipt.aol.com...
>> Rod Speed wrote:
>>> Morten Reistad <first@last.navn> wrote
>>>> Rod Speed <rod.speed.aaa@gmail.com> wrote
>>>>> jmfbahciv <See.above@aol.com> wrote
>>>>>> Peter Flass wrote
>>>>>>> jmfbahciv <See.above@aol.com> wrote
>>>>>>>> Andrew Swallow wrote
>>>>>>>>> jmfbahciv wrote
>>>>>>>>>> Rod Speed wrote
>>>>>>>>>>> jmfbahciv <See.above@aol.com> wrote
>>>>>>>>>>>> Andrew Swallow wrote
>>>
>>>>>>>>>>>>> This will help but unfortunately the database you
>>>>>>>>>>>>> are keeping secret ends up inside the sandbox.
>>>
>>>>>>>>>>>> Implement a file daemon like we did on TOPS-10.
>>>
>>>>>>>>>>> Doesn't do a damned thing about the problem he is talking about.
>>>
>>>>>>>>>> Of course it can.  The file daemone can do anything one wants
>>>>>>>>>> it to. In order to circumvent the security, a cracker has to patch
>>>>>>>>>> the monitor to redirect the IPCF messages _and_ its contents.
>>>
>>>>>>>>> Can the virus tell the daemone to get the next database record?
>>>>>>>>> If so repeat until the entire database has been extracted.
>>>
>>>>>>>> Only if the file daemon is designed to allow such access without
>>>>>>>> security.
>>>
>>>>>>>> Using a file daemon to access otherwise protected files from a user,
>>>>>>>> including an app, allows access without the user/app having to have
>>>>>>>> the system privileges one would need if a daemon wasn't available.
>>>
>>>>>>>> The sample JMF wrote, was designed to extend access to files.
>>>>>>>> There isn't anything preventing a daemon from accessing the
>>>>>>>> contents of files. The neat thing was that you could protect a
>>>>>>>> file from [1,2] accessing it.  [1,2] was the equivalent user to
>>>>>>>> Unix' sudo (I think that's what it's called.)
>>>
>>>>>>> A daemon has nothing to do with this. The file system has to run
>>>>>>> at a higher privilege level (which most do) and have no bugs or
>>>>>>> security holes (which doesn't seem to be true).  The problem seems
>>>>>>> to be that unauthorized code takes advantage of holes in the system
>>>>>>> get an elevated privilege level and access things it shouldn't.
>>>
>>>>>> If you have a file daemon, you can protect all files
>>>>>> and directories from any access at all times.
>>>
>>>>> There you go, utterly mangling the terminology just like you always do.
>>>
>>>> No, she has just given some references to
>>>> som DEC systems that have fallen into disuse.
>>>
>>> She isn't doing that in this case with her claim that 'you can
>>> protect all files and directories from any access at all times'
>
>> I did this every day at work.
>
> You never protected' all files and directories from any access at all times'
>
>> Even the god ppn [1,2] couldn't access my files if I didn't want them to.
>
> That is nothing even remotely like 'all files
> and directories from any access at all times'
>
>> The ones I did allow to access left a log in my directory.
>
> Not true of other access to other files. And that approach
> requires someone or something to check those logs anyway.


Yes, which I did.    I was maintainer of the Black Packs.
I assigned who could access what.  Noone else was allowed
particular types of accesses.

I also protected my ppn and its subdirectories from all accesses.

/BAH

[toc] | [prev] | [next] | [standalone]

#148625

jmfbahciv <See.above@aol.com> wrote:
> Rod Speed wrote:
>> 
>> 
>> "jmfbahciv" <See.above@aol.com> wrote in message
>> news:PM00051B39D5D75EA9@aca2e736.ipt.aol.com...
>>> Rod Speed wrote:
>>>> Morten Reistad <first@last.navn> wrote
>>>>> Rod Speed <rod.speed.aaa@gmail.com> wrote
>>>>>> jmfbahciv <See.above@aol.com> wrote
>>>>>>> Peter Flass wrote
>>>>>>>> jmfbahciv <See.above@aol.com> wrote
>>>>>>>>> Andrew Swallow wrote
>>>>>>>>>> jmfbahciv wrote
>>>>>>>>>>> Rod Speed wrote
>>>>>>>>>>>> jmfbahciv <See.above@aol.com> wrote
>>>>>>>>>>>>> Andrew Swallow wrote
>>>> 
>>>>>>>>>>>>>> This will help but unfortunately the database you
>>>>>>>>>>>>>> are keeping secret ends up inside the sandbox.
>>>> 
>>>>>>>>>>>>> Implement a file daemon like we did on TOPS-10.
>>>> 
>>>>>>>>>>>> Doesn't do a damned thing about the problem he is talking about.
>>>> 
>>>>>>>>>>> Of course it can.  The file daemone can do anything one wants
>>>>>>>>>>> it to. In order to circumvent the security, a cracker has to patch
>>>>>>>>>>> the monitor to redirect the IPCF messages _and_ its contents.
>>>> 
>>>>>>>>>> Can the virus tell the daemone to get the next database record?
>>>>>>>>>> If so repeat until the entire database has been extracted.
>>>> 
>>>>>>>>> Only if the file daemon is designed to allow such access without
>>>>>>>>> security.
>>>> 
>>>>>>>>> Using a file daemon to access otherwise protected files from a user,
>>>>>>>>> including an app, allows access without the user/app having to have
>>>>>>>>> the system privileges one would need if a daemon wasn't available.
>>>> 
>>>>>>>>> The sample JMF wrote, was designed to extend access to files.
>>>>>>>>> There isn't anything preventing a daemon from accessing the
>>>>>>>>> contents of files. The neat thing was that you could protect a
>>>>>>>>> file from [1,2] accessing it.  [1,2] was the equivalent user to
>>>>>>>>> Unix' sudo (I think that's what it's called.)
>>>> 
>>>>>>>> A daemon has nothing to do with this. The file system has to run
>>>>>>>> at a higher privilege level (which most do) and have no bugs or
>>>>>>>> security holes (which doesn't seem to be true).  The problem seems
>>>>>>>> to be that unauthorized code takes advantage of holes in the system
>>>>>>>> get an elevated privilege level and access things it shouldn't.
>>>> 
>>>>>>> If you have a file daemon, you can protect all files
>>>>>>> and directories from any access at all times.
>>>> 
>>>>>> There you go, utterly mangling the terminology just like you always do.
>>>> 
>>>>> No, she has just given some references to
>>>>> som DEC systems that have fallen into disuse.
>>>> 
>>>> She isn't doing that in this case with her claim that 'you can
>>>> protect all files and directories from any access at all times'
>> 
>>> I did this every day at work.
>> 
>> You never protected' all files and directories from any access at all times'
>> 
>>> Even the god ppn [1,2] couldn't access my files if I didn't want them to.
>> 
>> That is nothing even remotely like 'all files
>> and directories from any access at all times'
>> 
>>> The ones I did allow to access left a log in my directory.
>> 
>> Not true of other access to other files. And that approach
>> requires someone or something to check those logs anyway.
> 
> 
> Yes, which I did.    I was maintainer of the Black Packs.
> I assigned who could access what.  Noone else was allowed
> particular types of accesses.
> 
> I also protected my ppn and its subdirectories from all accesses.
> 

Did your data get backed up?  Unless the backups were encrypted it would be
simple to access your data for someone who could get the tape.


-- 
Pete

[toc] | [prev] | [next] | [standalone]

#148700

Peter Flass wrote:
> jmfbahciv <See.above@aol.com> wrote:
>> Rod Speed wrote:
>>>
>>>
>>> "jmfbahciv" <See.above@aol.com> wrote in message
>>> news:PM00051B39D5D75EA9@aca2e736.ipt.aol.com...
>>>> Rod Speed wrote:
>>>>> Morten Reistad <first@last.navn> wrote
>>>>>> Rod Speed <rod.speed.aaa@gmail.com> wrote
>>>>>>> jmfbahciv <See.above@aol.com> wrote
>>>>>>>> Peter Flass wrote
>>>>>>>>> jmfbahciv <See.above@aol.com> wrote
>>>>>>>>>> Andrew Swallow wrote
>>>>>>>>>>> jmfbahciv wrote
>>>>>>>>>>>> Rod Speed wrote
>>>>>>>>>>>>> jmfbahciv <See.above@aol.com> wrote
>>>>>>>>>>>>>> Andrew Swallow wrote
>>>>>
>>>>>>>>>>>>>>> This will help but unfortunately the database you
>>>>>>>>>>>>>>> are keeping secret ends up inside the sandbox.
>>>>>
>>>>>>>>>>>>>> Implement a file daemon like we did on TOPS-10.
>>>>>
>>>>>>>>>>>>> Doesn't do a damned thing about the problem he is talking about.
>>>>>
>>>>>>>>>>>> Of course it can.  The file daemone can do anything one wants
>>>>>>>>>>>> it to. In order to circumvent the security, a cracker has to
patch
>>>>>>>>>>>> the monitor to redirect the IPCF messages _and_ its contents.
>>>>>
>>>>>>>>>>> Can the virus tell the daemone to get the next database record?
>>>>>>>>>>> If so repeat until the entire database has been extracted.
>>>>>
>>>>>>>>>> Only if the file daemon is designed to allow such access without
>>>>>>>>>> security.
>>>>>
>>>>>>>>>> Using a file daemon to access otherwise protected files from a
user,
>>>>>>>>>> including an app, allows access without the user/app having to have
>>>>>>>>>> the system privileges one would need if a daemon wasn't available.
>>>>>
>>>>>>>>>> The sample JMF wrote, was designed to extend access to files.
>>>>>>>>>> There isn't anything preventing a daemon from accessing the
>>>>>>>>>> contents of files. The neat thing was that you could protect a
>>>>>>>>>> file from [1,2] accessing it.  [1,2] was the equivalent user to
>>>>>>>>>> Unix' sudo (I think that's what it's called.)
>>>>>
>>>>>>>>> A daemon has nothing to do with this. The file system has to run
>>>>>>>>> at a higher privilege level (which most do) and have no bugs or
>>>>>>>>> security holes (which doesn't seem to be true).  The problem seems
>>>>>>>>> to be that unauthorized code takes advantage of holes in the system
>>>>>>>>> get an elevated privilege level and access things it shouldn't.
>>>>>
>>>>>>>> If you have a file daemon, you can protect all files
>>>>>>>> and directories from any access at all times.
>>>>>
>>>>>>> There you go, utterly mangling the terminology just like you always
do.
>>>>>
>>>>>> No, she has just given some references to
>>>>>> som DEC systems that have fallen into disuse.
>>>>>
>>>>> She isn't doing that in this case with her claim that 'you can
>>>>> protect all files and directories from any access at all times'
>>>
>>>> I did this every day at work.
>>>
>>> You never protected' all files and directories from any access at all
times'
>>>
>>>> Even the god ppn [1,2] couldn't access my files if I didn't want them to.
>>>
>>> That is nothing even remotely like 'all files
>>> and directories from any access at all times'
>>>
>>>> The ones I did allow to access left a log in my directory.
>>>
>>> Not true of other access to other files. And that approach
>>> requires someone or something to check those logs anyway.
>>
>>
>> Yes, which I did.    I was maintainer of the Black Packs.
>> I assigned who could access what.  Noone else was allowed
>> particular types of accesses.
>>
>> I also protected my ppn and its subdirectories from all accesses.
>>
>
> Did your data get backed up?  Unless the backups were encrypted it would be
> simple to access your data for someone who could get the tape.

We didn't protect files in-house that far.  The files were saved with
protections intact.  I did have to have an entry in my ACCESS file for
BACKUPs or they wouldn't get saved.  System saves were not done with
the /INTERCHANGE switch.

/BAH

[toc] | [prev] | [next] | [standalone]

#148656

"jmfbahciv" <See.above@aol.com> wrote in message 
news:PM00051B4E99E3812C@aca24085.ipt.aol.com...
> Rod Speed wrote:
>>
>>
>> "jmfbahciv" <See.above@aol.com> wrote in message
>> news:PM00051B39D5D75EA9@aca2e736.ipt.aol.com...
>>> Rod Speed wrote:
>>>> Morten Reistad <first@last.navn> wrote
>>>>> Rod Speed <rod.speed.aaa@gmail.com> wrote
>>>>>> jmfbahciv <See.above@aol.com> wrote
>>>>>>> Peter Flass wrote
>>>>>>>> jmfbahciv <See.above@aol.com> wrote
>>>>>>>>> Andrew Swallow wrote
>>>>>>>>>> jmfbahciv wrote
>>>>>>>>>>> Rod Speed wrote
>>>>>>>>>>>> jmfbahciv <See.above@aol.com> wrote
>>>>>>>>>>>>> Andrew Swallow wrote
>>>>
>>>>>>>>>>>>>> This will help but unfortunately the database you
>>>>>>>>>>>>>> are keeping secret ends up inside the sandbox.
>>>>
>>>>>>>>>>>>> Implement a file daemon like we did on TOPS-10.
>>>>
>>>>>>>>>>>> Doesn't do a damned thing about the problem he is talking 
>>>>>>>>>>>> about.
>>>>
>>>>>>>>>>> Of course it can.  The file daemone can do anything one wants
>>>>>>>>>>> it to. In order to circumvent the security, a cracker has to 
>>>>>>>>>>> patch
>>>>>>>>>>> the monitor to redirect the IPCF messages _and_ its contents.
>>>>
>>>>>>>>>> Can the virus tell the daemone to get the next database record?
>>>>>>>>>> If so repeat until the entire database has been extracted.
>>>>
>>>>>>>>> Only if the file daemon is designed to allow such access without
>>>>>>>>> security.
>>>>
>>>>>>>>> Using a file daemon to access otherwise protected files from a 
>>>>>>>>> user,
>>>>>>>>> including an app, allows access without the user/app having to 
>>>>>>>>> have
>>>>>>>>> the system privileges one would need if a daemon wasn't available.
>>>>
>>>>>>>>> The sample JMF wrote, was designed to extend access to files.
>>>>>>>>> There isn't anything preventing a daemon from accessing the
>>>>>>>>> contents of files. The neat thing was that you could protect a
>>>>>>>>> file from [1,2] accessing it.  [1,2] was the equivalent user to
>>>>>>>>> Unix' sudo (I think that's what it's called.)
>>>>
>>>>>>>> A daemon has nothing to do with this. The file system has to run
>>>>>>>> at a higher privilege level (which most do) and have no bugs or
>>>>>>>> security holes (which doesn't seem to be true).  The problem seems
>>>>>>>> to be that unauthorized code takes advantage of holes in the system
>>>>>>>> get an elevated privilege level and access things it shouldn't.
>>>>
>>>>>>> If you have a file daemon, you can protect all files
>>>>>>> and directories from any access at all times.
>>>>
>>>>>> There you go, utterly mangling the terminology just like you always 
>>>>>> do.
>>>>
>>>>> No, she has just given some references to
>>>>> som DEC systems that have fallen into disuse.
>>>>
>>>> She isn't doing that in this case with her claim that 'you can
>>>> protect all files and directories from any access at all times'
>>
>>> I did this every day at work.
>>
>> You never protected' all files and directories from any access at all 
>> times'
>>
>>> Even the god ppn [1,2] couldn't access my files if I didn't want them 
>>> to.
>>
>> That is nothing even remotely like 'all files
>> and directories from any access at all times'
>>
>>> The ones I did allow to access left a log in my directory.
>>
>> Not true of other access to other files. And that approach
>> requires someone or something to check those logs anyway.

> Yes, which I did.

And you have fuck all real security for the user who doesn’t.

That's why the Apple approach with iOS works much better now.

> I was maintainer of the Black Packs. I assigned who could access
> what.  Noone else was allowed particular types of accesses.

> I also protected my ppn and its subdirectories from all accesses.

And the user doesn’t have to do that with iOS, that is the default
and you have to explicitly give permission to anything that wants
access to any of your data and files. That is a much better approach. 

[toc] | [prev] | [next] | [standalone]

#148488

jmfbahciv <See.above@aol.com> wrote
> Morten Reistad wrote
>> Rod Speed <rod.speed.aaa@gmail.com> wrote:
>>> jmfbahciv <See.above@aol.com> wrote
>>>> Peter Flass wrote
>>>>> jmfbahciv <See.above@aol.com> wrote
>>>>>> Andrew Swallow wrote
>>>>>>> jmfbahciv wrote
>>>>>>>> Rod Speed wrote
>>>>>>>>> jmfbahciv <See.above@aol.com> wrote
>>>>>>>>>> Andrew Swallow wrote
>>>>>>> {snip}
>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This will help but unfortunately the database you are keeping
>>>>>>>>>>> secret
>>>>>>>>>>> ends up inside the sandbox.
>>>>>>>>>>
>>>>>>>>>> Implement a file daemon like we did on TOPS-10.
>>>>>>>>>
>>>>>>>>> Doesn’t do a damned thing about the problem he is talking about.
>>>>>>>>
>>>>>>>> Of course it can.  The file daemone can do anything one wants it 
>>>>>>>> to.
>>>>>>>> In order to circumvent the security, a cracker has to patch the
>>>>>>>> monitor
>>>>>>>> to redirect the IPCF messages _and_ its contents.
>>>>>>>>
>>>>>>>> /BAH
>>>>>>>>
>>>>>>> Can the virus tell the daemone to get the next database record?
>>>>>>> If so repeat until the entire database has been extracted.
>>>>>>>
>>>>>> Only if the file daemon is designed to allow such access without
>>>>>> security.
>>>>>>
>>>>>> Using a file daemon to access otherwise protected files from a user,
>>>>>> including an app, allows access without the user/app having to have
>>>>>> the system privileges one would need if a daemon wasn't available.
>>>>>>
>>>>>> The sample JMF wrote, was designed to extend access to files.  There
>>>>>> isn't
>>>>>> anything preventing a daemon from accessing the contents of files.
>>>>>> The neat thing was that you could protect a file from [1,2] accessing
>>>>>> it.  [1,2] was the equivalent user to Unix' sudo (I think that's what
>>>>>> it's called.)
>>>>>>
>>>>>
>>>>> A daemon has nothing to do with this. The file system has to run at a
>>>>> higher privilege level (which most do) and have no bugs or security 
>>>>> holes
>>>>> (which doesn't seem to be true).  The problem seems to be that
>>>>> unauthorized
>>>>> code takes advantage of holes in the system get an elevated privilege
>>>>> level
>>>>> and access things it shouldn't.
>>>>
>>>> If you have a file daemon, you can protect all files and directories 
>>>> from
>>>> any access at all times.
>>>
>>>There you go, utterly mangling the terminology just like you always do.
>>
>> No, she has just given some references to som DEC systems that have
>> fallen into disuse.
>>
>> Both tops10 and tops20 have decent file protection primitives (contrasted
>> to *n*x native and windows). They are almost as good as the multics ones
>> from the later versions.
>>
>> In addition you could connect a user mode process to a partition, and 
>> have
>> the failed requests come in for a secondary view, and you could permit 
>> them
>> anyhow. If you wanted every open request to go through that daemon you 
>> just
>> set permissions 000 (unix-speak) on the mount point.
>>
>> These user mode daemons handle open()s, and set the subsequent read(),
>> write(), append() and select()/poll() permissions on the file handle as 
>> long
>> as it is kept open.
>>
>> This is one solution to the jail-process-problem, but I think the
>> jail() version of chroot() is a much better one. For one, you have a
>> system-provided check that you stay within your jail on every (of ~150)
>> system call the process performs. This limits the scope of the external
>> impact from every program executed within that process.
>
> That's an interesting approach but it wouldn't it have to ignore
> terminal I/O?

Nope.

> And what about network accesses?

Doesn’t have to ignore that either.

> ISTM there would have
> to be a list of system calls that would need ignoring.  I suppose that
> approach could provide a blanket security

Corse it can and that is what iOS does with its sandboxing
and that controls the terminal IO and network access too.

> but not control over contents of speicfic files/directories.

Wrong. That is what sandboxing does in spades.
The app only gets any access to its own files.

> The latter technique would only be invoked if, and only
> if, the "owner" of the file/directory wanted to invoke it.

And that is what sandboxing is about.

> With your approach, it would be a system invocation rather
> than something set up privately by a user within that system.

Wrong.

>>>> when an access fails, the file daemon can be called to decide
>>>> if access should be allowed.
>>>
>>>But it needs to have some basis for making that decision.
>>>
>>>> With that you can have MBs of code examining the situation and making
>>>> decisions.  What's more you could also create sectors of file daemons
>>>> called by the master file daemon.  A lot of protections on the PDP-10s
>>>> were built into the way we handled [P,PN]s.  ppn protections were
>>>> stricter and easier than access ids which were names.
>>>
>>>That last isn't the problem being discussed.
>>>
>>>And iOS essentially does what you are talking about and
>>>so utterly misnamed by sandboxing so nothing gets access
>>>to the data that belongs to an app except the app itself and
>>>with stuff like the contacts where more than one app needs
>>>to have access to some of the data at times, the user gets
>>>to authorise access by other than the app that owns the data.
>>>
>>>Its never going to be possible for 'a file daemon' to decide
>>>just what need to have access to stuff like the contacts.
>>
>> Don't dismiss it outright. I have seen user-mode file systems do
>> similar things on modern systems.
>
> We did all kinds of things with the example file daemon TOPS-10
> shipped.  And that was a simple-minded example for the customers
> to look at.
 

[toc] | [prev] | [next] | [standalone]

#148511

Ahem A Rivet's Shot wrote:
> On 18 Jul 2015 13:34:19 GMT
> jmfbahciv <See.above@aol.com> wrote:
>
>> Morten Reistad wrote:
>
>> > This is one solution to the jail-process-problem, but I think the
>> > jail() version of chroot() is a much better one. For one, you have a
>> > system-provided check that you stay within your jail on every (of ~150)
>> > system call the process performs. This limits the scope of the external
>> > impact from every program executed within that process.
>>
>> That's an interesting approach but it wouldn't it have to ignore
>> terminal I/O?
>
>     Yes terminal I/O is by default not available in a jail unless you
> connect a virtual terminal to the virtual terminal port and the jail is
> running something connected to the virtual terminal port (often there's a
> full OS image running in the jail - sometimes not the same OS as the host).

Sounds expensive.

>
>> And what about network accesses?  ISTM there would have
>
>     Jails have separate network configuration to the host, which is
> provided by the host. I have one jail running here that sees only a VPN
> connection and has no access to my LAN which limits the incursions possible
> from the other side of that VPN.
>
>> to be a list of system calls that would need ignoring.  I suppose that
>> approach could provide a blanket security but not control over
>> contents of speicfic files/directories.
>
>     Jails live in a chroot evnvironment so the directory tree they see
> is a subset of that on the host.

OK.  That sounds like the system manager sets it up instead of the
user/owner of the service area within the system.

>
>>  The latter technique would
>> only be invoked if, and only if, the "owner" of the file/directory
>> wanted to invoke it.  With your approach, it would be a system
>> invocation rather than something set up privately by a user within
>> that system.
>
>     Yes jails are a system level thing usually used to isolate network
> services from each other and the rest of the system.
>
>     File daemons if I'm understanding correctly provide a programmed
> way to give controlled access to otherwise forbidden operations on selected
> files and directories.

It's more elegant than that.  The user can cause file protection faults for
any file or directory s/he owns.  The file daemon is invoked when an access
is attempted.  the user has a file in the directory which can iterate who
may access the file, who may not access the file and which kinds of access
specific ppns can do.  this was the example implementation of our file
daemon.  It can get more complicated with contents of files.

To cause a blanket protection failure for everyone, including ppns with
privs, I simply protected my ppn.UFD and *.SFD files to cause a protection
failure.  Not even the operators could access my area without invoking the
file daemon.  Note that there wasn't a security hole if the file daemon
wasn't running because the protections which invoked the file daemon
were greater than normal.

>In a unix environment this is usually done with a
> service but that doesn't present like a file system access instead you talk
> the service protocol to a server which manipulates the files you're not
> allowed to touch.
>
>     A file system supporting file daemons would probably be easy to put
> together under the user space filesystem layer in Linux, a little harder
> without user space filesystem support.

TOPS-10 was a timesharing system with projects.  EAch project was able
to control its own areas without sysadmin human intervention.

For instance a prof who had a class could get a project number
of 306.  Each student would have a ppn of [306, nnn].  the prof could
set up his area and theirs for accessing.  he could allow read only
access to some files in his area for only the [306,*]  ppns.  He can
also log accesses and set up the students' ppns so he could read
anything in those directories...or write anything.

/BAH

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | alt.folklore.computers

csiph-web