Hi Folks,
ModelSecurity helps Ruby on Rails developers implement a security
defense in depth by implementing access control within the data model.
If you are like most developers, you think about security when you
program controllers and views. But a bug in your controller or view can
compromise the security of your application, unless your data model has
also been secured.
The economical, flexible, and extremely readable means of specifying
access controls provided by ModelSecurity makes it easier for the
developer to think about security, and makes security assumptions that
might otherwise live in one developers head concrete and communicable to
others.
I need people to go through the tutorial, just to make sure it works for
someone other than me. Please
see http://perens.com/FreeSoftware/ModelSecurity/Tutorial.html .
Many Thanks
Bruce Perens
Bruce Perens wrote:>Hi Folks, > >ModelSecurity helps Ruby on Rails developers implement a security >defense in depth by implementing access control within the data model. > >If you are like most developers, you think about security when you >program controllers and views. But a bug in your controller or view can >compromise the security of your application, unless your data model has >also been secured. > >The economical, flexible, and extremely readable means of specifying >access controls provided by ModelSecurity makes it easier for the >developer to think about security, and makes security assumptions that >might otherwise live in one developers head concrete and communicable to >others. > >I need people to go through the tutorial, just to make sure it works for >someone other than me. Please >see http://perens.com/FreeSoftware/ModelSecurity/Tutorial.html . > > Many Thanks > > Bruce Perens >_______________________________________________ >Rails mailing list >Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >http://lists.rubyonrails.org/mailman/listinfo/rails > > >When attempting to run: mysql -u /MYSQL-ADMIN-NAME/ -p < demo.sql I get: ERROR 1074 at line 1 in file: ''users.sql'': Too big column length for column ''cypher'' (max = 255). Use BLOB instead mysql Ver 12.22 Distrib 4.0.24, for pc-linux-gnu (i686) I will continue after some sleep........ Geoff
Bruce, I didnt have the mysql error that worked fine. I went to user/new created an admin user it threw an error (below) though it created the record. and all looks ok I then created a regular user and it threw the same error (couldnt find the created.rhtml) view the views do exists Ive checked. Sam -------------------------------------------- Errno::ENOENT in User#new No such file or directory - app/views/user/admin_created.rhtml /app/controllers/user_controller.rb:128:in `new'' Show framework trace /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/actionpack-1.9.1/lib/action_view/base.rb:265:in `read'' /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/actionpack-1.9.1/lib/action_view/base.rb:265:in `read_template_file'' /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/actionpack-1.9.1/lib/action_view/base.rb:170:in `render_file'' /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/actionpack-1.9.1/lib/action_controller/base.rb:588:in `render_with_no_layout'' /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/actionpack-1.9.1/lib/action_controller/layout.rb:216:in `render_without_benchmark'' /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/actionpack-1.9.1/lib/action_controller/benchmarking.rb:25:in `render'' /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/actionpack-1.9.1/lib/action_controller/benchmarking.rb:25:in `measure'' /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/actionpack-1.9.1/lib/action_controller/benchmarking.rb:25:in `render'' /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/actionpack-1.9.1/lib/action_controller/base.rb:756:in `send'' /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/actionpack-1.9.1/lib/action_controller/base.rb:756:in `perform_action_without_filters'' /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/actionpack-1.9.1/lib/action_controller/filters.rb:295:in `perform_action_without_benchmark'' /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/actionpack-1.9.1/lib/action_controller/benchmarking.rb:41:in `perform_action_without_rescue'' /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/actionpack-1.9.1/lib/action_controller/benchmarking.rb:41:in `measure'' /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/actionpack-1.9.1/lib/action_controller/benchmarking.rb:41:in `perform_action_without_rescue'' /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/actionpack-1.9.1/lib/action_controller/rescue.rb:80:in `perform_action'' /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/actionpack-1.9.1/lib/action_controller/base.rb:356:in `send'' /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/actionpack-1.9.1/lib/action_controller/base.rb:356:in `process'' /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/rails-0.13.1/lib/dispatcher.rb:32:in `dispatch'' /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/rails-0.13.1/lib/fcgi_handler.rb:144:in `process_request'' /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/rails-0.13.1/lib/fcgi_handler.rb:64:in `process!'' /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/rails-0.13.1/lib/fcgi_handler.rb:55:in `each_cgi'' /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/fcgi-0.8.6.1/./fcgi.rb:597:in `each'' /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/fcgi-0.8.6.1/./fcgi.rb:597:in `each_cgi'' /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/rails-0.13.1/lib/fcgi_handler.rb:55:in `process!'' /Applications/Locomotive/Bundles/rails-0.13.1-max.bundle/Contents/Resources/ports/lib/ruby/gems/1.8/gems/rails-0.13.1/lib/fcgi_handler.rb:21:in `process!'' /Users/smayes/railsprojects/sectest/public/dispatch.fcgi:24 On 10/6/05, Bruce Perens <bruce-Dp076HI/R8PQT0dZR+AlfA@public.gmane.org> wrote:> Hi Folks, > > ModelSecurity helps Ruby on Rails developers implement a security > defense in depth by implementing access control within the data model. > > If you are like most developers, you think about security when you > program controllers and views. But a bug in your controller or view can > compromise the security of your application, unless your data model has > also been secured. > > The economical, flexible, and extremely readable means of specifying > access controls provided by ModelSecurity makes it easier for the > developer to think about security, and makes security assumptions that > might otherwise live in one developers head concrete and communicable to > others. > > I need people to go through the tutorial, just to make sure it works for > someone other than me. Please > see http://perens.com/FreeSoftware/ModelSecurity/Tutorial.html . > > Many Thanks > > Bruce Perens > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
I am not far enough along in Rails yet to be able to test this for you. But, I just had to say that after looking at the project this is something I have looking for for a very long time. When I''m farther down the tracks and I''ve started on my next major project I will be be looking very seriously at this. I think the decision to use Rails has just been made. Thanks! -Eric On Oct 6, 2005, at 2:02 PM, Bruce Perens wrote:> Hi Folks, > > ModelSecurity helps Ruby on Rails developers implement a security > defense in depth by implementing access control within the data model. > > If you are like most developers, you think about security when you > program controllers and views. But a bug in your controller or view > can > compromise the security of your application, unless your data model > has > also been secured. > > The economical, flexible, and extremely readable means of specifying > access controls provided by ModelSecurity makes it easier for the > developer to think about security, and makes security assumptions that > might otherwise live in one developers head concrete and > communicable to > others. > > I need people to go through the tutorial, just to make sure it > works for > someone other than me. Please > see http://perens.com/FreeSoftware/ModelSecurity/Tutorial.html . > > Many Thanks > > Bruce Perens > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Thursday 06 October 2005 21:02, Bruce Perens wrote:> Hi Folks, > > ModelSecurity helps Ruby on Rails developers implement a security > defense in depth by implementing access control within the data > model.Bruce, I looked closely at 0.0.1 when you announced it, I only had time for a glance at 0.0.5. As intend to use it, I''ll have to have a closer look soon. One thing I noticed is that the generator copies unchanged files into app/, lib/, and test/. In my opinion this should be avoided if possible. Files that are not intended to be changed by the application programmer, I prefer to have completely out of the way. One option would be a subdirectory of vendor/. The best way would probably be to use the recently introduced plugin mechanism[*]. Michael [*] http://dev.rubyonrails.org/changeset/2465 -- Michael Schuerig Those who call the shots mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org Are never in the line of fire http://www.schuerig.de/michael/ --Ani DiFranco, Not So Soft
On 7 Oct 2005, at 14:23, Sam Mayes wrote:> I went to user/new created an admin user it threw an error (below) > though it created the record. and all looks ok > I then created a regular user and it threw the same error (couldnt > find the created.rhtml) view > > the views do exists Ive checked. > > Sam > > -------------------------------------------- > Errno::ENOENT in User#new > No such file or directory - app/views/user/admin_created.rhtml > /app/controllers/user_controller.rb:128:in `new''Sam, Look for these lines in the ''new'' method and change them [ render :file => ''app/views/user/admin_created.rhtml'' ] to [ render :file => "/user/admin_created", :use_full_path => true ] and [ render :file => ''app/views/user/created.rhtml'' ] to [ render :file => ''/user/created'', :use_full_path => true ] Then it works, at least with Locomotive 0.30. Attn: Bruce, 1. Why use HTTP Auth, instead of the ''normal'' login form in HTML ? 2. I might be doing something wrong, but it seems the security model breaks down completely on only [ /user ] as it lists all the users and e-mails without being logged in. Kind regards, Mats ---- "TextMate, coding with an incredible sense of joy and ease" - www.macromates.com -
Thanks for that Mats, I second the question of why do httpauth as well as a form? this is exactly what i need besides the httpauth. i could see maybe using one or the other but not both. Sam On 10/8/05, Mats Persson <mats-uGq4Pdis5ybkYMGBc/C6ZA@public.gmane.org> wrote:> > On 7 Oct 2005, at 14:23, Sam Mayes wrote: > > I went to user/new created an admin user it threw an error (below) > > though it created the record. and all looks ok > > I then created a regular user and it threw the same error (couldnt > > find the created.rhtml) view > > > > the views do exists Ive checked. > > > > Sam > > > > -------------------------------------------- > > Errno::ENOENT in User#new > > No such file or directory - app/views/user/admin_created.rhtml > > /app/controllers/user_controller.rb:128:in `new'' > > Sam, > > Look for these lines in the ''new'' method and change them > > [ render :file => ''app/views/user/admin_created.rhtml'' ] to > [ render :file => "/user/admin_created", :use_full_path => true ] > > and > > [ render :file => ''app/views/user/created.rhtml'' ] to [ render :file > => ''/user/created'', :use_full_path => true ] > > Then it works, at least with Locomotive 0.30. > > > Attn: Bruce, > > 1. Why use HTTP Auth, instead of the ''normal'' login form in HTML ? > > 2. I might be doing something wrong, but it seems the security > model breaks down completely on only [ /user ] as it lists all the > users and e-mails without being logged in. > > > Kind regards, > > Mats > > ---- > "TextMate, coding with an incredible sense of joy and ease" > - www.macromates.com - > > >
Michael Schuerig wrote:>The best way would probably be to use the recently introduced plugin mechanism[*]. > >Yes, I will wait for this to stabilize. It sounds to me as if ModelSecurity could easily go in a plugin. User should be separated from ModelSecurity. I might try to do a merge with ActiveRBAC, but if I do so I want to preserve a simpler interface - ActiveRBAC at present is too wordy. Thanks Bruce
Sam Mayes wrote:>I second the question of why do httpauth as well as a form > >HTTP authentication is actually defined by a standard, while login forms are ad-hoc. Browsers all accomodate HTTP authentication. Some of them do a better job of saving login/password information with HTTP authentication than with a login form. If the password is saved, the browser need not present the login panel to the user at all, and thus the user interface goes more smoothly. Try doing that with a form. HTTP authentication also works with command-line tools like "wget", which would have a hard time logging in via a form. Since it''s so well-defined, you can also make HTTP authentication work well for a visually impaired user. Why then do a form too? When you send the HTTP authentication directive to the browser, it''s sent as a header with a web page. That page doesn''t become visible until the user cancels out of the login panel. You can either give the user a lame explanation of what happened in that page, or blank, or you can give him a login form and allow him to complete the action. Thanks Bruce
Thanks for the explanation Bruce, it makes more sense now especially after all the testing Ive done lately. I dont know if I would merge with activerbac, unless you decide to add roles groups and perms. I think there is a good need for an extensive system like activerbac, and a simpler auth system with just users and admins especially if this would be a plugin. combine this with technoweenies quick adminforms interface and you can roll stuff out very fast. Sam On 10/12/05, Bruce Perens <bruce-Dp076HI/R8PQT0dZR+AlfA@public.gmane.org> wrote:> > Sam Mayes wrote: > > >I second the question of why do httpauth as well as a form > > > > > HTTP authentication is actually defined by a standard, while login forms > are ad-hoc. Browsers all accomodate HTTP authentication. Some of them do > a better job of saving login/password information with HTTP > authentication than with a login form. If the password is saved, the > browser need not present the login panel to the user at all, and thus > the user interface goes more smoothly. Try doing that with a form. HTTP > authentication also works with command-line tools like "wget", which > would have a hard time logging in via a form. Since it''s so > well-defined, you can also make HTTP authentication work well for a > visually impaired user. > > Why then do a form too? When you send the HTTP authentication directive > to the browser, it''s sent as a header with a web page. That page doesn''t > become visible until the user cancels out of the login panel. You can > either give the user a lame explanation of what happened in that page, > or blank, or you can give him a login form and allow him to complete the > action. > > Thanks > > Bruce >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Julian ''Julik'' Tarkhanov
2005-Oct-12 14:01 UTC
Re: Need testers for ModelSecurity tutorial
On 8-okt-2005, at 21:14, Mats Persson wrote:> > 1. Why use HTTP Auth, instead of the ''normal'' login form in HTML ?Personally I think HTTP Auth is advisable because of 3 things: 1. Automated clients all know how to deal with HTTP auth in some way 2. Authenticated links can be saved and passed around 3. You don''t have to maintain a "session trail" to bounce the user to the page he wanted to see before being asked for credentials 4. Every user of the Web has some experience with his standard browser''s authentication form. OTOH he has to recognize it in your custom design with sessio-based auth (it goes very fast but still takes his time). -- Julian "Julik" Tarkhanov
Julian ''Julik'' Tarkhanov wrote:> On 8-okt-2005, at 21:14, Mats Persson wrote: >> 1. Why use HTTP Auth, instead of the ''normal'' login form in HTML ?As I understand it ModelSecurity provides HTTP auth for both the admin interface and ''protected'' public pages. If so ...> Personally I think HTTP Auth is advisable because of 3 things: > 1. Automated clients all know how to deal with HTTP auth in some wayTrue.> 2. Authenticated links can be saved and passed aroundIt''s a bad idea to promote this; your average user considers URLs public, but once you embed a username and password in them, they''re very definitely not. Also, depending on your session lifetimes and/or making other provisions, it''s possible to create ''pre-authed'' links without using HTTP auth.> 3. You don''t have to maintain a "session trail" to bounce the user to > the page he wanted to see before being asked for credentialsTrue.> 4. Every user of the Web has some experience with his standard > browser''s authentication form.I''d dispute this. I can''t think of any web sites (as opposed to web *interfaces*) that use HTTP auth. Not banking sites, not Amazon/ Ebay/Hotmail/Google type sites. Where would the average web user encounter HTTP auth these days? Chris.
Chris Andrews wrote:>>2. Authenticated links can be saved and passed around >> >> > >It''s a bad idea to promote this; your average user considers URLs >public, but once you embed a username and password in them, they''re very >definitely not. >We''re not doing that. The HTTP authentication information is in the header, not the URL. It''s unique to your session. Passing around the URL doesn''t reveal your login information. However, you will notice that the browser is currently sending your password as cleartext. Shifting from plain to digest authentication will resolve that issue.>>3. You don''t have to maintain a "session trail" to bounce the user to >>the page he wanted to see before being asked for credentials >> >> > >True. > >Uh-oh. I do currently maintain a session trail to get to the reqested page after authentication. While the login panel appears, the browser is at /user/login . I wonder if this would confuse web caches regarding the private status of pages requiring authentication. Um. I bet it would. I suppose I should instead spoof the destination URL while presenting the login panel, and then stop spoofing it once authentication completes. This would get rid of one round-trip, so it''s useful. I also don''t do anything explicit about cache control. But I could set cache-control to "private" from "require_condition".>>4. Every user of the Web has some experience with his standard >>browser''s authentication form. >> >> > >I''d dispute this. I can''t think of any web sites (as opposed to web >*interfaces*) that use HTTP auth. Not banking sites, not Amazon/ >Ebay/Hotmail/Google type sites. > >Where would the average web user encounter HTTP auth these days? > >This may be so, but it indicates a lack of sympathy for the visually-impaired user among the creators of dynamic web sites. Also, can you fully use your site with javascript off? The answer these days is often "no". That stuff is a blind man''s misery. I''ve not tried an auditory browser. I wonder if I can get one set up in Debian. People should try navigating their sites by ear. It would make them more sensitive to the issue. Thanks Bruce _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Bruce Perens wrote:> Chris Andrews wrote: > >>>2. Authenticated links can be saved and passed around >>> >>> >> >>It''s a bad idea to promote this; your average user considers URLs >>public, but once you embed a username and password in them, they''re very >>definitely not. >> > We''re not doing that. The HTTP authentication information is in the > header, not the URL. It''s unique to your session. Passing around the URL > doesn''t reveal your login information. > > However, you will notice that the browser is currently sending your > password as cleartext. Shifting from plain to digest authentication will > resolve that issue.Indeed, and you''re right that there''s no problem with your system as is. However, I (and I believe Julik) were referring to urls with the credentials embedded. Wasn''t there a big hoohah in the RSS community about this, when people started putting these "authenticated links" into public aggregators? I was just pointing out that encouraging passing around these links isn''t a great idea. Chris.
Julian ''Julik'' Tarkhanov
2005-Oct-12 22:58 UTC
Re: [OT]ModelSecurity and HTTP authentication
On 12-okt-2005, at 21:40, Chris Andrews wrote:> > However, I (and I believe Julik) were referring to urls with the > credentials embedded. Wasn''t there a big hoohah in the RSS community > about this, when people started putting these "authenticated links" > into > public aggregators? I was just pointing out that encouraging passing > around these links isn''t a great idea.If course there is and it will be, but I think that people who _can_ and _do_ use credentials embedded in the URL have the right to use it further. It is a hack that you shouldn''t deprive people from (of course I am not talking about banking systems and the like). As to RSS, you can just filter who is pulling in your feed and state explicitly that shared credentials are going to be banned. You always have to prune people who do not comply with behavioral code. -- Julian "Julik" Tarkhanov