Re: [apparmor] GSoC Project on new AppArmor profile development tool
On Fri, May 03, 2013 at 09:43:15PM +0200, Christian Boltz wrote: > Indeed - creating some profiles with genprof and logprof (and at the > same time reading the audit.log and the resulting profile) is the easier > and probably faster way to understand how genprof and logprof work. > > Goal: you should be able to read an audit.log and write a profile in > $EDITOR - at least for a simple application or script. Yes, this is a far better approach to understanding the tools. > Nevertheless, it might be needed to read the code for some details - but > that should be very targeted at the relevant code section. For the simple cases, the results would be easier studied by cause and effect, rather than code. For complicated cases, the code will be unreadable. (And I say that as a friend. :) > > (You wouldn't want to modify the current tools to do a profile > > repository, it just wouldn't be fun.) > > Nothing is useless - it can still serve as a bad example ;-)) Please, if you use any of my code in your giant list of bad coding practices, feel free to not attribute me. :) > > The repository API may be interesting to review -- if it could be > > found again -- but there was nothing in the API that was especially > > enlightened. (It was just a simple CRUD-style application.) > > Reviewing the API could indeed provide some ideas - but given the fact > that the profile repo is disabled in the tools since years, creating a > completely new API won't do any harm or break anything. Agreed -- I meant the operations that the API enabled, not the exact details _of_ the API. > -- > Perl - the only language that looks the same before and after RSA > encryption. -- Keith Bostic Well-chosen, as always. :) Thanks signature.asc Description: Digital signature -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] GSoC Project on new AppArmor profile development tool
Hello, Am Mittwoch, 1. Mai 2013 schrieb Seth Arnold: > On Wed, May 01, 2013 at 05:35:03PM +0200, Christian Boltz wrote: > > http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/kshitij8/1 > I've got a handful of concerns; I'm afraid to give them voice, because > I do not wish to blunt enthusiasm :) ;-) > but this plan looks very optimistic. ;-) > I don't recommend spending much time learning Perl. The densest of our > Perl code will still be completely unintelligible regardless if > you've got one week or one month Perl experience. If you've got a > year, it'd be more approachable, but the complete lack of > datastructures makes the code readability near zero. This reminds me of ... - well, see non-random signature ;-) Indeed - creating some profiles with genprof and logprof (and at the same time reading the audit.log and the resulting profile) is the easier and probably faster way to understand how genprof and logprof work. Goal: you should be able to read an audit.log and write a profile in $EDITOR - at least for a simple application or script. Nevertheless, it might be needed to read the code for some details - but that should be very targeted at the relevant code section. > I'd recommend putting the profile repository at the end of the project > -- I expect the other tools will take more time to work on. It is already planned in the last weeks, after the tools are finished, so I don't see a big problem here. (Worst case: If writing the tools will really takes more time, the profile repo part has to be skipped.) > (You wouldn't want to modify the current tools to do a profile > repository, it just wouldn't be fun.) Nothing is useless - it can still serve as a bad example ;-)) > The repository API may be interesting to review -- if it could be > found again -- but there was nothing in the API that was especially > enlightened. (It was just a simple CRUD-style application.) Reviewing the API could indeed provide some ideas - but given the fact that the profile repo is disabled in the tools since years, creating a completely new API won't do any harm or break anything. > It feels like it'd be nice to have some of the simpler / basic tools > done 'sooner' than the full merging mechanism -- aa-complain, > aa-enforce, aa-unconfined, etc., are all pretty handy little tools. > You'll probably want them along the way. :) Good point - they are much easier to start with than genprof and logprof, and some of them could also serve as a proof that the first code parts work. Regards, Christian Boltz -- Perl - the only language that looks the same before and after RSA encryption. -- Keith Bostic -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] GSoC Project on new AppArmor profile development tool
On Wed, May 01, 2013 at 05:35:03PM +0200, Christian Boltz wrote: > Am Sonntag, 28. April 2013 schrieb Seth Arnold: > > I don't know anything about the GSoC project or process, but it'd be > > Let's change that ;-) > > We (Kshitij, John and I) discussed several things in private mails, > but Kshitij's proposal is public - feel free to have a look at it ;-) > > http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/kshitij8/1 > > If you have any questions or comments on the proposal, just reply to this > mail ;-) Excellent, this is a big improvement in my understanding :) Thanks. I've got a handful of concerns; I'm afraid to give them voice, because I do not wish to blunt enthusiasm :) but this plan looks very optimistic. I don't recommend spending much time learning Perl. The densest of our Perl code will still be completely unintelligible regardless if you've got one week or one month Perl experience. If you've got a year, it'd be more approachable, but the complete lack of datastructures makes the code readability near zero. I'd recommend putting the profile repository at the end of the project -- I expect the other tools will take more time to work on. (You wouldn't want to modify the current tools to do a profile repository, it just wouldn't be fun.) Feel free to ignore my old repository codebase. It was written for Ruby On Rails, an ancient version, and I used standard SQL storage (which might not be the best tool) _and_ I used the SOAP/XML-RPC bindings because REST toolkits on clients were very poor in comparison. There's no reason to try to revive that. :) The repository API may be interesting to review -- if it could be found again -- but there was nothing in the API that was especially enlightened. (It was just a simple CRUD-style application.) It feels like it'd be nice to have some of the simpler / basic tools done 'sooner' than the full merging mechanism -- aa-complain, aa-enforce, aa-unconfined, etc., are all pretty handy little tools. You'll probably want them along the way. :) > Well, I will be the final enemy^Wtestcase *eg* - I'm quite sure you know > how hard that can be ;-) > -- > > "Quite low" is 1 in 4 billion. Murphy could make me believe you saw it > > once, but not twice. You could plausibly see it in a stress test rig > This _is_ Christian :) he has a knack for finding bugs no one else can.. > [> Crispin Cowan and Seth Arnold in apparmor-general] Hehe, as always entertaining. :) Thanks Kshitij, Christian, and John signature.asc Description: Digital signature -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] GSoC Project on new AppArmor profile development tool
Hello, Am Sonntag, 28. April 2013 schrieb Seth Arnold: > I don't know anything about the GSoC project or process, but it'd be Let's change that ;-) We (Kshitij, John and I) discussed several things in private mails, but Kshitij's proposal is public - feel free to have a look at it ;-) http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/kshitij8/1 If you have any questions or comments on the proposal, just reply to this mail ;-) (You won't be able to comment directly on the page because you are not a GSoC mentor. Only John and I can add comments.) > fun to have some fresh input on AppArmor and the tools. The existing > Perl-based tools feel a bit .. brittle. (At least, I'm scared of > modifying them.) ;-) > One thing we'd really like is some good tests to go with the new > tools; I have found that code that was written with the intention of > testing tends to be better code anyway, as the thought "how do I test > this?" forces a better design. (Some people prefer to take this to > the extreme and do test-driven development. I haven't tried, so I > can't comment on the effectiveness, but I'm a bit worried about the > idea of "stopping when the tests all pass". Well, I will be the final enemy^Wtestcase *eg* - I'm quite sure you know how hard that can be ;-) Regards, Christian Boltz PS: non-random sig ;-) -- > "Quite low" is 1 in 4 billion. Murphy could make me believe you saw it > once, but not twice. You could plausibly see it in a stress test rig This _is_ Christian :) he has a knack for finding bugs no one else can.. [> Crispin Cowan and Seth Arnold in apparmor-general] -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] GSoC Project on new AppArmor profile development tool
On Wed, Apr 24, 2013 at 05:06:01PM +0530, Kshitij Gupta wrote: > I am Kshitij and I would like to work on developing a new AppArmor profile > management tool to further strengthen the AppArmor project as my Google > Summer of Code project. I have been using both C/C++ and Python for a while > and hope to finish this project while learning more about open-source > culture. > > The wonderful project proposed is a brain child of John Johansen and > Christian Boltz. > > We believe its necessary to do rewrite of the profile management > application from scratch to fix all the pending bugs and make it more > maintainable. > > Looking forward to support and any ideas that maybe presented. Hello Kshitij, I don't know anything about the GSoC project or process, but it'd be fun to have some fresh input on AppArmor and the tools. The existing Perl-based tools feel a bit .. brittle. (At least, I'm scared of modifying them.) One thing we'd really like is some good tests to go with the new tools; I have found that code that was written with the intention of testing tends to be better code anyway, as the thought "how do I test this?" forces a better design. (Some people prefer to take this to the extreme and do test-driven development. I haven't tried, so I can't comment on the effectiveness, but I'm a bit worried about the idea of "stopping when the tests all pass". It might work fine if you've written astonishingly comprehensive tests up front...) Anyway, welcome, and thanks for the interest. :) signature.asc Description: Digital signature -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
