Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #148047 > unrolled thread
| Started by | Mike Spencer <mds@bogus.nodomain.nowhere> |
|---|---|
| First post | 2015-07-08 00:27 -0300 |
| Last post | 2015-07-08 12:57 -0700 |
| Articles | 18 on this page of 58 — 20 participants |
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.
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 3 of 3 — ← Prev page 1 2 [3]
| From | Morten Reistad <first@last.navn> |
|---|---|
| Date | 2015-07-19 18:15 +0200 |
| Message-ID | <a1vs7c-4q1.ln1@sambook.reistad.name> |
| In reply to | #148511 |
In article <PM00051B3A08B01556@aca2e736.ipt.aol.com>, jmfbahciv <See.above@aol.com> wrote: >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. Or you can have separate user spaces running under the same kernel. There are half a dozen implementations. >>> 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. No, the simplest peon user can set up a process in a jail. That jail will only have as much permissions as that user, or less. Some manipulations of interfaces do require root permissions, though. >>> 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 -- mrr
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2015-07-20 13:29 +0000 |
| Message-ID | <PM00051B4E8D89A3D2@aca24085.ipt.aol.com> |
| In reply to | #148535 |
Morten Reistad wrote: > In article <PM00051B3A08B01556@aca2e736.ipt.aol.com>, > jmfbahciv <See.above@aol.com> wrote: >>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. > > Or you can have separate user spaces running under the same kernel. There > are half a dozen implementations. > > >>>> 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. > > No, the simplest peon user can set up a process in a jail. That jail > will only have as much permissions as that user, or less. The file daemon allows all accesses, even more. >Some manipulations > of interfaces do require root permissions, though. I can think of ways to implement sub-file daemons which would use the main file daemon for the root privs. In our experience, there wasn't a security problem with ppns which had IPCF paging privs. Everyone used IPCF when logging in/out, printing, submitting batch jobs and mounting devices. /BAH [rest not snipped for context] > > >>>> 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 > > -- mrr > >
[toc] | [prev] | [next] | [standalone]
| From | "Rod Speed" <rod.speed.aaa@gmail.com> |
|---|---|
| Date | 2015-07-21 05:49 +1000 |
| Message-ID | <d151moFgk8nU1@mid.individual.net> |
| In reply to | #148606 |
"jmfbahciv" <See.above@aol.com> wrote in message news:PM00051B4E8D89A3D2@aca24085.ipt.aol.com... > Morten Reistad wrote: >> In article <PM00051B3A08B01556@aca2e736.ipt.aol.com>, >> jmfbahciv <See.above@aol.com> wrote: >>>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. >> >> Or you can have separate user spaces running under the same kernel. There >> are half a dozen implementations. >> >> >>>>> 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. >> >> No, the simplest peon user can set up a process in a jail. That jail >> will only have as much permissions as that user, or less. > > The file daemon allows all accesses, even more. > >>Some manipulations >> of interfaces do require root permissions, though. > > I can think of ways to implement sub-file daemons which would use > the main file daemon for the root privs. In our experience, there > wasn't a security problem with ppns which had IPCF paging privs. > Everyone used IPCF when logging in/out, printing, submitting batch > jobs and mounting devices. And the world's moved on now with smartphones where it makes a lot more sense to do it the way Apple does it with iOS where the security can be as tight as you like, effortlessly. > [rest not snipped for context] >> >> >>>>> 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.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Speed" <rod.speed.aaa@gmail.com> |
|---|---|
| Date | 2015-07-20 06:38 +1000 |
| Message-ID | <d12g5gFrbubU1@mid.individual.net> |
| In reply to | #148511 |
"jmfbahciv" <See.above@aol.com> wrote in message news:PM00051B3A08B01556@aca2e736.ipt.aol.com... > 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. Then you need a new hearing aid, it isn't. >>> 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. Varys with the implementation. With iOS on apple iDevices the user decides what access apps have to their files and data. >>> 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.
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2015-07-20 13:29 +0000 |
| Message-ID | <PM00051B4EC0F8AF31@aca24085.ipt.aol.com> |
| In reply to | #148394 |
Morten Reistad wrote:
> In article <PM00051B266DEF881D@aca2d680.ipt.aol.com>,
> jmfbahciv <See.above@aol.com> wrote:
>>Morten Reistad wrote:
>>> 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.
>>
>>That's an interesting approach but it wouldn't it have to ignore
>>terminal I/O? And what about network accesses? ISTM there would have
>>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. 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.
>
> You can set a permissions mask when you make a jail. There are half
> a dozen implementations for various *n*xen. On some you can allow
> inwards, but not outwards calls on the network and/or disk space,
> i.e. someone else (with the right permissions) can mount your /
> (root) and look at the content. Ditto for networking, you can allow
> non-priviliged tcp/udp access, or you can allow everything but connect(),
> i.e. not allowing outgoing calls at all. But still allowing listen(),
> so you can take incoming sessions. Implementations vary.
>
> Or you can disallow network I/O completely, or only to localhost.
>
>>>>> 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.
>
> The issue with this approach is that the customer will have to
> do programming, and make that programming watertight. And the
> api was not a trivial one.
Well, that's how DEC did its business. When we implemneted a feature,
we tried to also ship an example using it so each customer
wouldn't have to figure out the basics. they could jump to their
site-specific coding. There were other product lines which didn't
ship examples like the PDP-10 did.
Look. I'm not even trying to say that this is the "right" way
for today's computing. I am trying to describe how we solved
similar problems on the auld timesharing systems.
What was described could have been solved with our file daemon.
If the security had to be different for contents of files,
a file daemon could be extended to protect that, too. In those
days, people weren't thinking about file pieces; the record
access business was just getting started with our customers.
>
> Much safer against program bugs to have a simple configure-based
> api with a gui on top where you can peruse and set a dozen or
> two permissions for the jail.
>
> My inclination for wanting a jail is that the kernel-user interface
> is a very solid one with bugs fixed asap, and using that with an
> extra permissions layer is a few orders of magnitude simpler than
> e.g. "fixing" java. Or some other language, done in software at
> the 10k library level. Much easier to have a permissions layer
> at the kernel-user interface, where you need to supply around 150
> OS calls, around 10 of which are the critical ones.
The software side of the computing has changed, especially
since the plug 'n play concept became the norm.
/BAH
[toc] | [prev] | [next] | [standalone]
| From | "Rod Speed" <rod.speed.aaa@gmail.com> |
|---|---|
| Date | 2015-07-21 05:55 +1000 |
| Message-ID | <d1520qFgn1hU1@mid.individual.net> |
| In reply to | #148604 |
"jmfbahciv" <See.above@aol.com> wrote in message
news:PM00051B4EC0F8AF31@aca24085.ipt.aol.com...
> Morten Reistad wrote:
>> In article <PM00051B266DEF881D@aca2d680.ipt.aol.com>,
>> jmfbahciv <See.above@aol.com> wrote:
>>>Morten Reistad wrote:
>>>> 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.
>>>
>>>That's an interesting approach but it wouldn't it have to ignore
>>>terminal I/O? And what about network accesses? ISTM there would have
>>>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. 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.
>>
>> You can set a permissions mask when you make a jail. There are half
>> a dozen implementations for various *n*xen. On some you can allow
>> inwards, but not outwards calls on the network and/or disk space,
>> i.e. someone else (with the right permissions) can mount your /
>> (root) and look at the content. Ditto for networking, you can allow
>> non-priviliged tcp/udp access, or you can allow everything but connect(),
>> i.e. not allowing outgoing calls at all. But still allowing listen(),
>> so you can take incoming sessions. Implementations vary.
>>
>> Or you can disallow network I/O completely, or only to localhost.
>>
>>>>>> 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.
>>
>> The issue with this approach is that the customer will have to
>> do programming, and make that programming watertight. And the
>> api was not a trivial one.
>
> Well, that's how DEC did its business. When we implemneted a feature,
> we tried to also ship an example using it so each customer
> wouldn't have to figure out the basics. they could jump to their
> site-specific coding. There were other product lines which didn't
> ship examples like the PDP-10 did.
>
> Look. I'm not even trying to say that this is the "right" way
> for today's computing. I am trying to describe how we solved
> similar problems on the auld timesharing systems.
>
> What was described could have been solved with our file daemon.
Makes a lot more sense to do it the way Apple does it with
iOS, sandbox the apps and require the owner of the system
to explicitly permit any access to their data and files instead.
> If the security had to be different for contents of files,
> a file daemon could be extended to protect that, too. In those
> days, people weren't thinking about file pieces; the record
> access business was just getting started with our customers.
>> Much safer against program bugs to have a simple configure-based
>> api with a gui on top where you can peruse and set a dozen or
>> two permissions for the jail.
>>
>> My inclination for wanting a jail is that the kernel-user interface
>> is a very solid one with bugs fixed asap, and using that with an
>> extra permissions layer is a few orders of magnitude simpler than
>> e.g. "fixing" java. Or some other language, done in software at
>> the 10k library level. Much easier to have a permissions layer
>> at the kernel-user interface, where you need to supply around 150
>> OS calls, around 10 of which are the critical ones.
>
> The software side of the computing has changed, especially
> since the plug 'n play concept became the norm.
There isn't much of that with smartphones.
[toc] | [prev] | [next] | [standalone]
| From | "Hank" <hfd543@nospam.com> |
|---|---|
| Date | 2015-07-12 06:00 +1000 |
| Message-ID | <d0davaFgclfU1@mid.individual.net> |
| In reply to | #148219 |
"Ahem A Rivet's Shot" <steveo@eircom.net> wrote in message news:20150711113057.ca08eb151b65b97bf7222d29@eircom.net... > On Sat, 11 Jul 2015 00:42:35 +0200 > Morten Reistad <first@last.navn> wrote: > >> In article <ILWdnVDmvrKguz3InZ2dnUU78WednZ2d@giganews.com>, >> Andrew Swallow <am.swallow@btinternet.com> wrote: > >> >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. > > The original idea of JavaScript, the first crack in the box was the > ability to populate a file upload field from JavaScript. But even when > fully sandboxed it still has access to every form field you fill in and > the > network so it can be used to create form loggers if it can be injected > into > a page But you are free to only use a form filler that you have access to the code of so you can check what it does with the form field data and know that it can not access anything but that data. > (see cross-site scripting). Irrelevant to access to other data on your system. By definition anything that supplies any data to the net can be supplying it to more than just what the user intends to supply data to. That is a separate problem entirely for which there is no solution at all and which is just as big a problem with data supplied verbally or on a paper form.
[toc] | [prev] | [next] | [standalone]
| From | Morten Reistad <first@last.navn> |
|---|---|
| Date | 2015-07-11 00:38 +0200 |
| Message-ID | <f4u57c-p54.ln1@sambook.reistad.name> |
| In reply to | #148200 |
In article <171436069458247542.238143peter_flass-yahoo.com@news.eternal-september.org>,
Peter Flass <peter_flass@yahoo.com> 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?
This is the wrong paradigm. We need the programmatic sugar to show
us the websites, emails and other media, but we need to sandbox them properly.
This is a far less complicated task than securing java, javascript,
etc etc. Just let them be the bloat that they currently are, but
make d*mned sure they cannot do anything outside the ephemeral sandbox
jail we execute them in.
Even flash is OK. If properly sandboxed it may at worst do a dos attack
on itself.
To make a sandbox we need to have the processor instructions properly
interpreted or executed with a local only contect, and we need all the
~150 os calls in *n*x properly secured. This is a task that is severeal
orders of magnitude simpler than "securing" java.
-- mrr
[toc] | [prev] | [next] | [standalone]
| From | "Charles Richmond" <numerist@aquaporin4.com> |
|---|---|
| Date | 2015-07-10 15:27 -0500 |
| Message-ID | <mnp9pa$4vi$1@dont-email.me> |
| In reply to | #148192 |
"Charlie Gibbs" <cgibbs@kltpzyxm.invalid> wrote in message news:mnosba0pdk@news3.newsguy.com... > On 2015-07-10, Peter Flass <peter_flass@yahoo.com> wrote: > > [snip...] [snip...] > [snip...] > > 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). > See "Reflections on Trusting Trust", Ken Thompson's 1984 ACM Turing Award speech: https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf -- numerist at aquaporin4 dot com
[toc] | [prev] | [next] | [standalone]
| From | Dave Garland <dave.garland@wizinfo.com> |
|---|---|
| Date | 2015-07-11 00:18 -0500 |
| Message-ID | <mnq8tc$th6$1@dont-email.me> |
| In reply to | #148205 |
On 7/10/2015 3:27 PM, Charles Richmond wrote: > "Charlie Gibbs" <cgibbs@kltpzyxm.invalid> wrote in message > news:mnosba0pdk@news3.newsguy.com... >> On 2015-07-10, Peter Flass <peter_flass@yahoo.com> wrote: >> >> [snip...] [snip...] [snip...] >> >> 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). >> > > See "Reflections on Trusting Trust", Ken Thompson's 1984 ACM Turing > Award speech: > > https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf > A paper that is highly relevant in these days of (often justified) paranoia. (Is it paranoia if they really are trying to "get" you? And don't even paranoids have real enemies?)
[toc] | [prev] | [next] | [standalone]
| From | "Rod Speed" <rod.speed.aaa@gmail.com> |
|---|---|
| Date | 2015-07-11 19:22 +1000 |
| Message-ID | <d0c5jiF73bbU1@mid.individual.net> |
| In reply to | #148215 |
"Dave Garland" <dave.garland@wizinfo.com> wrote in message news:mnq8tc$th6$1@dont-email.me... > On 7/10/2015 3:27 PM, Charles Richmond wrote: >> "Charlie Gibbs" <cgibbs@kltpzyxm.invalid> wrote in message >> news:mnosba0pdk@news3.newsguy.com... >>> On 2015-07-10, Peter Flass <peter_flass@yahoo.com> wrote: >>> >>> [snip...] [snip...] [snip...] >>> >>> 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). >>> >> >> See "Reflections on Trusting Trust", Ken Thompson's 1984 ACM Turing >> Award speech: >> >> https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf >> > > A paper that is highly relevant in these days of (often justified) > paranoia. Yes. > (Is it paranoia if they really are trying to "get" you? But they usually aren't. > And don't even paranoids have real enemies?) Very few of them do.
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@telus.net> |
|---|---|
| Date | 2015-07-10 17:53 -0700 |
| Message-ID | <63q0qa11lr13mgkupah5ij6a4jdboqgh8c@4ax.com> |
| In reply to | #148192 |
On 10 Jul 2015 16:36:58 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
wrote:
[snip]
>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).
Security by obscurity works fine, just not as the only thing done
for security.
Those who think that security by obscurity does not work at all,
kindly post a reply with all of your id's and passwords and details of
for what systems and all data relevant to signing on. Please do not
leave anything out; you would not want someone accusing you of
hypocrisy, would you?
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | "Osmium" <r124c4u102@comcast.net> |
|---|---|
| Date | 2015-07-10 22:22 -0500 |
| Message-ID | <d0bgf7F2bcnU1@mid.individual.net> |
| In reply to | #148209 |
"Gene Wirchenko" wrote: > On 10 Jul 2015 16:36:58 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid> > wrote: > > [snip] > >>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). > > Security by obscurity works fine, just not as the only thing done > for security. > > Those who think that security by obscurity does not work at all, > kindly post a reply with all of your id's and passwords and details of > for what systems and all data relevant to signing on. Please do not > leave anything out; you would not want someone accusing you of > hypocrisy, would you? I think you are reading too much into a slogan designed to fit on a bumper sticker.
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@telus.net> |
|---|---|
| Date | 2015-07-10 23:39 -0700 |
| Message-ID | <ffe1qa17hqgk503ic5ha8tmcm768fh661j@4ax.com> |
| In reply to | #148213 |
On Fri, 10 Jul 2015 22:22:15 -0500, "Osmium" <r124c4u102@comcast.net>
wrote:
>"Gene Wirchenko" wrote:
>
>> On 10 Jul 2015 16:36:58 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
>> wrote:
>>
>> [snip]
>>
>>>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).
>>
>> Security by obscurity works fine, just not as the only thing done
>> for security.
>>
>> Those who think that security by obscurity does not work at all,
>> kindly post a reply with all of your id's and passwords and details of
>> for what systems and all data relevant to signing on. Please do not
>> leave anything out; you would not want someone accusing you of
>> hypocrisy, would you?
>
>I think you are reading too much into a slogan designed to fit on a bumper
>sticker.
No, I am not. Unfortunately, all too many take it at face value
and do not think about it. I was snapping back some at that.
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | simon@twoplaces.co.uk (Simon Turner) |
|---|---|
| Date | 2015-07-10 08:27 +0100 |
| Message-ID | <20150710.0727.969634snz@twoplaces.co.uk> |
| In reply to | #148112 |
On Thursday, in article
<b976eab8-54b1-4568-91d1-0c446885aef2@googlegroups.com>
hancock4@bbs.cpcn.com wrote:
> On Thursday, July 9, 2015 at 2:15:06 AM UTC-4, Mike Spencer wrote:
>
> > Yes. That was the "arcane juju" to which I referred. How about a
> > nice ASCII text file in which I can search for "network:dnsPrefetch"
> > instead of a tedious interactive UI with its own usage rules
> > referencing an unreadable database? Not to mention that the entries
> > in about:config are mostly obscure in the extreme.
>
> One of the things I noticed in poking around is that set up files
> are harder to find and deal with, as you say. Instead of ASCII
> with clear names, it's binary files with obscure names.
If you make the config files easy to find and easy to modify, a
significant number of people will fiddle with them with dire results,
causing a tech support nightmare (in the course of which they will
usually deny having changed anything). These days, quite a few users
really are too stupid to own a computer.
--
Simon Turner DoD #0461
simon@twoplaces.co.uk
Trust me -- I know what I'm doing! -- Sledge Hammer
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2015-07-09 00:29 +0000 |
| Message-ID | <2132480585458094282.813304peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #148079 |
<hancock4@bbs.cpcn.com> wrote: > On Tuesday, July 7, 2015 at 11:27:57 PM UTC-4, Mike Spencer wrote: > >> Um, well, now we all do in the form of javascript, written by web >> turkeys^H^H^H^H^H^H^H designers, that can do all sorts of obnoxious >> stuff while you're reading the news or whatever. But it's not *your* >> agent, it's some corporate entity's agent, doing something *that* >> entity finds useful. Programs that launch automatically and hairballs >> that do their own thing while you're not looking are similar agents. >> And they're not your agents nor mine. Feh. > > Yes, indeed. > > Advocates of fancy automation say it helps the user experience. But in > reality it helps marketers sell more goods. > > For instance, just the day there was an article about malware exploiting > FlashPlayer. Do we really need the Flash Player at all? No, we do not. > Even if we did, its functionality could be far more limited, eliminating > the chance of malware being attached to it or exploiting it. Other > articles point to automated modern systems being hijacked. It's amazing > security people can keep track of all this stuff; but unfortunately, they > learn about it after the fact. Security has to be designed in from the start, not added in later. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2015-07-09 07:38 +0000 |
| Message-ID | <mnl8df120u5@news3.newsguy.com> |
| In reply to | #148108 |
On 2015-07-09, Peter Flass <peter_flass@yahoo.com> wrote: > Security has to be designed in from the start, not added in later. And you have to really want security, as opposed to something that just makes you feel good. -- /~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs) \ / I'm really at ac.dekanfrus if you read it the right way. X Top-posted messages will probably be ignored. See RFC1855. / \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
[toc] | [prev] | [next] | [standalone]
| From | Daiyu Hurst <daiyu.hurst@gmail.com> |
|---|---|
| Date | 2015-07-08 12:57 -0700 |
| Message-ID | <9c45dc8c-b177-4e5a-9923-a8d97ba8bb4d@googlegroups.com> |
| In reply to | #148047 |
On Wednesday, July 8, 2015 at 6:36:03 AM UTC-4, Andrew Swallow wrote: > On 08/07/2015 04:27, Mike Spencer wrote: > > hancock4@bbs.cpcn.com writes: > > > >> On Sunday, February 22, 2015 at 2:49:05 PM UTC-5, gareth wrote: > >> > >>> Oh, to have the simplicity of CP/M on a PC, with the > >>> processor speeds and oodles of storage of today! > >> > > > >> Now that this thread has been reactivated, I'll say that I wish > >> programs wouldn't execute on a PC unless explicitly commanded by the > >> user. (Also, a much simpler O/S). None of this open and run > >> automatically, which makes it so easy for malware to its thing. > > > > What he said! And add to it those huge hairballs of code (such as a > > browser) that go out and do stuff *on the net* without your knowledge, > > let alone your authorization. Apps that call home, distribute data or > > store it in the cloud^H^H^H^H^H smog because the authors want to > > engineer "improved user experience" [blech] keep me busy (if not > > exactly entertained) tinkering with firewall details to prevent it. > > > > Twent-five years ago, Nicholas Negroponte was keen on autonomous > > intelligent agents, bits of software that would go "out on the net" > > and do useful things for you, a la _Shockwave Rider_. Wait! Who's > > going to agree to allow such bits of *your* code into *their* machines? > > > > Um, well, now we all do in the form of javascript, written by web > > turkeys^H^H^H^H^H^H^H designers, that can do all sorts of obnoxious > > stuff while you're reading the news or whatever. But it's not *your* > > agent, it's some corporate entity's agent, doing something *that* > > entity finds useful. Programs that launch automatically and hairballs > > that do their own thing while you're not looking are similar agents. > > And they're not your agents nor mine. Feh. > > > > The one organisation that can bring this under control is the Department > of Defence. It needs much improved protection from hacking. Many of its > hostile hackers are spies working for foreign governments. Computer > security requires the DOD to start with operating systems designed to be > defend against attacks. > > The initial starting stage can be defined and agreed. This is called the Clean Slate Initiative. It's underway.
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | alt.folklore.computers
csiph-web