Difference between revisions of "Talk:Carver 2.0 Planning Page"

From ForensicsWiki
Jump to: navigation, search
(POLA)
 
(5 intermediate revisions by 3 users not shown)
Line 12: Line 12:
 
== Consolidation ==
 
== 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)
 
:: 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)
 +
 +
::: 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.
 +
== 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 [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.

Latest revision as of 16:40, 24 November 2008

License: have we even discussed a license yet? Who chose it? I'm not terribly opposed to a 3-clause BSD, but...? - RB 00:39, 30 October 2008 (UTC)

Joachim I prefer the LPGL it's restricts the usage of the code somewhat more. When its integrated in other (closed source) tooling which is published, they must publish that the tool uses this code.

LGPL?
.FUF 19:40, 31 October 2008 (UTC)
Joachim GNU Library or "Lesser" General Public License (LGPL) (http://www.opensource.org/licenses/alphabetical)
Joachim I prefer the LPGL :) .FUF 19:51, 31 October 2008 (UTC)
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. 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 (.FUF or 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. 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, Simsong? .FUF 18:12, 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. --RB 19:03, 1 November 2008 (UTC)
Joachim Separate the parts into topics. Have a discussion and an informational part per topic.

POLA

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.