Talk:Carver 2.0 Planning Page - Revision history

Capibara: /* POLA */

2008-11-24T21:40:01Z

‎POLA

Capibara: /* POLA */

2008-11-24T21:36:28Z

‎POLA

Capibara: /* POLA */

2008-11-24T21:21:40Z

‎POLA

Capibara at 08:48, 24 November 2008

2008-11-24T08:48:40Z

Joachim Metz: /* Consolidation */

2008-11-02T08:45:33Z

‎Consolidation

RB: /* Consolidation */

2008-11-01T19:03:49Z

‎Consolidation

.FUF at 18:12, 1 November 2008

2008-11-01T18:12:10Z

RB: /* Consolidation */ new section

2008-11-01T17:48:08Z

‎Consolidation: new section

RB: forgot to sign...

2008-11-01T16:59:47Z

forgot to sign...

RB: LGPL discussion

2008-11-01T16:57:45Z

LGPL discussion

← Older revision		Revision as of 21:40, 24 November 2008
Line 21:		Line 21:
	== POLA ==		== POLA ==

−	[[User:Capibara\|Capibara]] :Just noticed a presentation by Simson when looking for 'usable security' on google that included notes on designation and access (authority). From this I would gather that Simson has something of a background in [[capability security theory]]. This makes me feel we might have sufficient ground to discuss 'open file handles as capabilities' at the library level. [[AppArmor]] allows instances of executables to be confined to least privilege. Unix domain sockets allow open file handles to be passed around as capabilities. The combination of these two results in the possibility of using [[object capability]] based least authority at the process level of granularity. For such to work with libraries such as libaff, libewf and libtsk, these libraries must not insist on opening their own files. At the moment this rules out using libaff or libewf directly as such. [http://ocfa.sourceforge.net/libcarvpath/ CarvFs] can provide a way around this, but it may be desirable to not have to use CarvFs in some cases. Given that the authors of both libaff and libewf are quite active here, It may be valid to discuss the possibility of extending the API of these libs so that the libs dont demand to open their own files, but could also be used by a confined carving tool that would get open file handles passed to it over a unix domain socket.	+	[[User:Capibara\|Capibara]] :Just noticed a presentation by Simson when looking for 'usable security' on google that included notes on designation and access (authority). From this I would gather that Simson has something of a background in [http://en.wikipedia.org/wiki/Capability-based_security capability security theory]. This makes me feel we might have sufficient ground to discuss 'open file handles as capabilities' at the library level. [[AppArmor]] allows instances of executables to be confined to least privilege. Unix domain sockets allow open file handles to be passed around as capabilities. The combination of these two results in the possibility of using [http://en.wikipedia.org/wiki/Object_capability object capability] based least authority at the process level of granularity. For such to work with libraries such as libaff, libewf and libtsk, these libraries must not insist on opening their own files. At the moment this rules out using libaff or libewf directly as such. [http://ocfa.sourceforge.net/libcarvpath/ CarvFs] can provide a way around this, but it may be desirable to not have to use CarvFs in some cases. Given that the authors of both libaff and libewf are quite active here, It may be valid to discuss the possibility of extending the API of these libs so that the libs dont demand to open their own files, but could also be used by a confined carving tool that would get open file handles passed to it over a unix domain socket.

← Older revision		Revision as of 21:36, 24 November 2008
Line 21:		Line 21:
	== POLA ==		== POLA ==

−	[[User:Capibara\|Capibara]] :Just noticed a presentation by Simson when looking for 'usable security' on google that included notes on designation and access (authority). From this I would gather that Simson has something of a background in [[capability security theory]]. This makes me feel we might have sufficient ground to discuss 'open file handles as capabilities' at the library level. [[AppArmor]] allows instances of executables to be confined to least privilege. Unix domain sockets allow open file handles to be passed around as capabilities. The combination of these two results in the possibility of using [[object capability]] based least authority at the process level of granularity. For such to work with libraries such as libaff, libewf and libtsk, these libraries must not insist on opening their own files. At the moment this rules out using libaff or libewf directly as such. [[CarvFs]] can provide a way around this, but it may be desirable to not have to use CarvFs in some cases. Given that the authors of both libaff and libewf are quite active here, It may be valid to discuss the possibility of extending the API of these libs so that the libs dont demand to open their own files, but could also be used by a confined carving tool that would get open file handles passed to it over a unix domain socket.	+	[[User:Capibara\|Capibara]] :Just noticed a presentation by Simson when looking for 'usable security' on google that included notes on designation and access (authority). From this I would gather that Simson has something of a background in [[capability security theory]]. This makes me feel we might have sufficient ground to discuss 'open file handles as capabilities' at the library level. [[AppArmor]] allows instances of executables to be confined to least privilege. Unix domain sockets allow open file handles to be passed around as capabilities. The combination of these two results in the possibility of using [[object capability]] based least authority at the process level of granularity. For such to work with libraries such as libaff, libewf and libtsk, these libraries must not insist on opening their own files. At the moment this rules out using libaff or libewf directly as such. [http://ocfa.sourceforge.net/libcarvpath/ CarvFs] can provide a way around this, but it may be desirable to not have to use CarvFs in some cases. Given that the authors of both libaff and libewf are quite active here, It may be valid to discuss the possibility of extending the API of these libs so that the libs dont demand to open their own files, but could also be used by a confined carving tool that would get open file handles passed to it over a unix domain socket.

← Older revision		Revision as of 21:21, 24 November 2008
Line 21:		Line 21:
	== POLA ==		== POLA ==

−	[[User:Capibara\|Capibara]] :Just noticed a presentation by Simson when looking for 'usable security' on google that included notes on designation ~~nd authorization~~. From this I would gather that Simson has something of a background in [[capability security theory]]. This makes me feel we might have sufficient ground to discuss 'open file handles as capabilities' at the library level. [[AppArmor]] allows instances of executables to be confined to least privilege. Unix domain sockets allow open file handles to be passed around as capabilities. The combination of these two results in the possibility of using [[object capability]] based least authority at the process level of granularity. For such to work with libraries such as libaff, libewf and libtsk, these libraries must not insist on opening their own files. At the moment this rules out using libaff or libewf directly as such. [[CarvFs]] can provide a way around this, but it may be desirable to not have to use CarvFs in some cases. Given that the authors of both libaff and libewf are quite active here, It may be valid to discuss the possibility of extending the API of these libs so that the libs dont demand to open their own files, but could also be used by a confined carving tool that would get open file handles passed to it over a unix domain socket.	+	[[User:Capibara\|Capibara]] :Just noticed a presentation by Simson when looking for 'usable security' on google that included notes on designation and access (authority). From this I would gather that Simson has something of a background in [[capability security theory]]. This makes me feel we might have sufficient ground to discuss 'open file handles as capabilities' at the library level. [[AppArmor]] allows instances of executables to be confined to least privilege. Unix domain sockets allow open file handles to be passed around as capabilities. The combination of these two results in the possibility of using [[object capability]] based least authority at the process level of granularity. For such to work with libraries such as libaff, libewf and libtsk, these libraries must not insist on opening their own files. At the moment this rules out using libaff or libewf directly as such. [[CarvFs]] can provide a way around this, but it may be desirable to not have to use CarvFs in some cases. Given that the authors of both libaff and libewf are quite active here, It may be valid to discuss the possibility of extending the API of these libs so that the libs dont demand to open their own files, but could also be used by a confined carving tool that would get open file handles passed to it over a unix domain socket.

← Older revision		Revision as of 08:48, 24 November 2008
Line 19:		Line 19:

	:::: [[User:Joachim Metz\|Joachim]] Separate the parts into topics. Have a discussion and an informational part per topic.		:::: [[User:Joachim Metz\|Joachim]] Separate the parts into topics. Have a discussion and an informational part per topic.
		+	== POLA ==
		+
		+	[[User:Capibara\|Capibara]] :Just noticed a presentation by Simson when looking for 'usable security' on google that included notes on designation nd authorization. From this I would gather that Simson has something of a background in [[capability security theory]]. This makes me feel we might have sufficient ground to discuss 'open file handles as capabilities' at the library level. [[AppArmor]] allows instances of executables to be confined to least privilege. Unix domain sockets allow open file handles to be passed around as capabilities. The combination of these two results in the possibility of using [[object capability]] based least authority at the process level of granularity. For such to work with libraries such as libaff, libewf and libtsk, these libraries must not insist on opening their own files. At the moment this rules out using libaff or libewf directly as such. [[CarvFs]] can provide a way around this, but it may be desirable to not have to use CarvFs in some cases. Given that the authors of both libaff and libewf are quite active here, It may be valid to discuss the possibility of extending the API of these libs so that the libs dont demand to open their own files, but could also be used by a confined carving tool that would get open file handles passed to it over a unix domain socket.

← Older revision		Revision as of 08:45, 2 November 2008
Line 17:		Line 17:

	::: One option could be to break each major section into its own page so it can be properly discussed without clutter, then transclude each to this page. A dedicated namespace would probably be overkill, but since we're throwing out ideas should at least be mentioned. --[[User:RB\|RB]] 19:03, 1 November 2008 (UTC)		::: One option could be to break each major section into its own page so it can be properly discussed without clutter, then transclude each to this page. A dedicated namespace would probably be overkill, but since we're throwing out ideas should at least be mentioned. --[[User:RB\|RB]] 19:03, 1 November 2008 (UTC)
		+
		+	:::: [[User:Joachim Metz\|Joachim]] Separate the parts into topics. Have a discussion and an informational part per topic.

@@ Line 12: / Line 12: @@
 == Consolidation ==
-We've got a '''lot''' of good ideas here, but in interest of not stepping on anyone's toes, it's getting rather disjointed and hard to read.  Is anyone willing to (or allow me to) try to consolidate them into some sort of coherency?  I'd like at least one of the admins ([[User:.FUF|FUF]] or [[User:Simsong|Simsong]] to concur before anyone moves forward.  I know the wiki way is to just let it grow, but even watching each addition I'm starting to have trouble visualizing where we are.
+We've got a '''lot''' of good ideas here, but in interest of not stepping on anyone's toes, it's getting rather disjointed and hard to read.  Is anyone willing to (or allow me to) try to consolidate them into some sort of coherency?  I'd like at least one of the admins ([[User:.FUF|.FUF]] or [[User:Simsong|Simsong]] to concur before anyone moves forward.  I know the wiki way is to just let it grow, but even watching each addition I'm starting to have trouble visualizing where we are. [[User:RB|RB]]
 :: That's good idea, but it is important to consolidate without losing the ideas and opinions. I think it's better for this page to enter some "stable" branch. And then we'll move to the next phase. What do you think, [[User:Simsong|Simsong]]? [[User:.FUF|.FUF]] 18:12, 1 November 2008 (UTC)

← Older revision		Revision as of 18:12, 1 November 2008
Line 13:		Line 13:

	We've got a '''lot''' of good ideas here, but in interest of not stepping on anyone's toes, it's getting rather disjointed and hard to read. Is anyone willing to (or allow me to) try to consolidate them into some sort of coherency? I'd like at least one of the admins ([[User:.FUF\|FUF]] or [[User:Simsong\|Simsong]] to concur before anyone moves forward. I know the wiki way is to just let it grow, but even watching each addition I'm starting to have trouble visualizing where we are.		We've got a '''lot''' of good ideas here, but in interest of not stepping on anyone's toes, it's getting rather disjointed and hard to read. Is anyone willing to (or allow me to) try to consolidate them into some sort of coherency? I'd like at least one of the admins ([[User:.FUF\|FUF]] or [[User:Simsong\|Simsong]] to concur before anyone moves forward. I know the wiki way is to just let it grow, but even watching each addition I'm starting to have trouble visualizing where we are.
		+
		+	:: That's good idea, but it is important to consolidate without losing the ideas and opinions. I think it's better for this page to enter some "stable" branch. And then we'll move to the next phase. What do you think, [[User:Simsong\|Simsong]]? [[User:.FUF\|.FUF]] 18:12, 1 November 2008 (UTC)

← Older revision		Revision as of 17:48, 1 November 2008
Line 9:		Line 9:
	:::::: [[User:Joachim Metz\|Joachim]] To quote Homer Simpson "Doh!"		:::::: [[User:Joachim Metz\|Joachim]] To quote Homer Simpson "Doh!"
	:: Agreed. I sit on the fence between BSD and GPL: the business half of me agrees that open licensing should place as few restrictions or qualifications as possible, whereas the idealist/OSS side wants to ensure the project's freedom. The LGPL is a more reasonable balance, encouraging widespread use but ensuring modifications' freedom. [[User:RB\|RB]] 16:59, 1 November 2008 (UTC)		:: Agreed. I sit on the fence between BSD and GPL: the business half of me agrees that open licensing should place as few restrictions or qualifications as possible, whereas the idealist/OSS side wants to ensure the project's freedom. The LGPL is a more reasonable balance, encouraging widespread use but ensuring modifications' freedom. [[User:RB\|RB]] 16:59, 1 November 2008 (UTC)
		+
		+	== Consolidation ==
		+
		+	We've got a '''lot''' of good ideas here, but in interest of not stepping on anyone's toes, it's getting rather disjointed and hard to read. Is anyone willing to (or allow me to) try to consolidate them into some sort of coherency? I'd like at least one of the admins ([[User:.FUF\|FUF]] or [[User:Simsong\|Simsong]] to concur before anyone moves forward. I know the wiki way is to just let it grow, but even watching each addition I'm starting to have trouble visualizing where we are.

@@ Line 8: / Line 8: @@
 :::: ''Joachim I prefer the LPGL'' :) [[User:.FUF|.FUF]] 19:51, 31 October 2008 (UTC)
 :::::: [[User:Joachim Metz|Joachim]] To quote Homer Simpson "Doh!"
-:: Agreed.  I sit on the fence between BSD and GPL: the business half of me agrees that open licensing should place as few restrictions or qualifications as possible, whereas the idealist/OSS side wants to ensure the project's freedom.  The LGPL is a more reasonable balance, encouraging widespread use but ensuring modifications' freedom.
+:: Agreed.  I sit on the fence between BSD and GPL: the business half of me agrees that open licensing should place as few restrictions or qualifications as possible, whereas the idealist/OSS side wants to ensure the project's freedom.  The LGPL is a more reasonable balance, encouraging widespread use but ensuring modifications' freedom. [[User:RB|RB]] 16:59, 1 November 2008 (UTC)

← Older revision		Revision as of 16:57, 1 November 2008
Line 8:		Line 8:
	:::: ''Joachim I prefer the LPGL'' :) [[User:.FUF\|.FUF]] 19:51, 31 October 2008 (UTC)		:::: ''Joachim I prefer the LPGL'' :) [[User:.FUF\|.FUF]] 19:51, 31 October 2008 (UTC)
	:::::: [[User:Joachim Metz\|Joachim]] To quote Homer Simpson "Doh!"		:::::: [[User:Joachim Metz\|Joachim]] To quote Homer Simpson "Doh!"
		+	:: Agreed. I sit on the fence between BSD and GPL: the business half of me agrees that open licensing should place as few restrictions or qualifications as possible, whereas the idealist/OSS side wants to ensure the project's freedom. The LGPL is a more reasonable balance, encouraging widespread use but ensuring modifications' freedom.