I have been working on a model security implementation for Rails. Each
attribute of your models can be protected with a security test.
In the declaration of your model, you include ModelSecurity, and then
you can can specify security tests for the various model attributes
similarly to the way that validators are specified:
require ''model_security.rb''
class User < ActiveRecord::Base
include ModelSecurity
let_read :activated, :cypher, :salt, :if => :logging_in?
let_write :id, :if :=> new_record?
...
This protects the attributes "activated", "cypher" and
"salt", and makes
them available for reading only if the method "logging_in?" returns
true
for the active record in question. The record ID can only be written if
the standard Rails method "new_record?" returns true, and thus a
record
can not be subverted to over-write a record with another ID.
Un-permitted read or write accesses result in an immediate exception -
it doesn''t want until you attempt to save the record as with
validators.
A complex security system can be constructed in just a few lines.
I have modified the generic editing-form methods used by scaffolds, such
as text_field, to heed the above security permissions. If there isn''t
permission to write the field, they render text instead of a form field.
They also render properly if a field is writable but not readable, or
not accessable at all. The modified form methods will not generate a
security violation on their own.
There is a method similar to the security specifications that hints to
the scaffold views what fields should be displayed:
let_display :activted, :if => :admin?
This is called on the active record''s class, rather than an instance as
in let_read and let_write, and is used to determine what fields should
get table columns before a scaffold view starts to iterate displaying
active records. This makes scaffolds somewhat smarter, as they can be
informed of what data is useful or permitted for display in a particular
context. Of course, this method can be made to function for your custom
views as well as scaffolds.
Since permissions are often coupled to logins, I have created a User
class that is loosely derived from the Salted Hash login generator. It
secures its own data using the above methods, and provides some generic
security tests for use in models, such as :admin? and :me? . :me?
returns true if the User object it''s invoked upon corresponds to the
currently-logged-in user. It also provides some before-filters for use
in controllers: require_admin will redirect to a login box until an
administrator logs in, and then will allow the requested action to
complete. require_login is similar, but it just wants a login, rather
than an administrator login. The login facility is extended to use Basic
HTTP authentication as well as the forms and tokens provided with Salted
Hash.
Using the facilities I am building, you can provide two levels of a
security defense in depth, by securing your controllers, and then your
models. You can add a third layer by securing the database. Model
security violations should not be exposed by properly secured
controllers, but they are there in case of the inevitable bug. It
strikes me that multiple layers of security might conflict with our
maxim to not repeat ourselves. I''d be interested in hearing opinions on
that.
I have also generalized the store_location method used in the Salted
Hash login generator to handle all sorts of modal pages, this lives in
the module "Modal".
This code isn''t ready for you to use, it''s just started to
work. But you
can look at it. I would greatly appreciate suggestions. It''s at
http://perens.com/FreeSoftware/Rails/ModelSecurity_0.01.tar.gz . Rubydoc
documentation is included.
This work is sponsored by Sourcelabs, who graciously support me to spend
half of my work hours doing whatever I wish for the Open Source community.
Many Thanks
Bruce Perens
In article <42EF404D.6000100-Dp076HI/R8PQT0dZR+AlfA@public.gmane.org>, bruce- Dp076HI/R8PQT0dZR+AlfA-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org says...> This code isn''t ready for you to use, it''s just started to work. But you > can look at it. I would greatly appreciate suggestions. It''s at > http://perens.com/FreeSoftware/Rails/ModelSecurity_0.01.tar.gz . Rubydoc > documentation is included.Bruce, This sounds terrific, and we''re glad to have you contributing! What about changing require_admin to require_role (:admin), which would more easily genericize to RBAC as the module grows? I''m not sure if that''s the best syntax, but you get where I''m going... - Jay Levitt | Wellesley, MA | I feel calm. I feel ready. I can only Faster: jay at jay dot fm | conclude that''s because I don''t have a http://www.jay.fm | full grasp of the situation. - Mark Adler
On Aug 2, 2005, at 2:43 AM, Bruce Perens wrote:> I have been working on a model security implementation for Rails. Each > attribute of your models can be protected with a security test. > > <snip a ton of great stuff> > > This work is sponsored by Sourcelabs, who graciously support me to > spend > half of my work hours doing whatever I wish for the Open Source > community. > > Many Thanks > > Bruce PerensBruce- Great idea. Thanks for your hard work. I feel something like this is a must have for some more sensitive rails apps. And thats a great employer you have there that lets you spend half your time on open source. Thanks Bruce- -Ezra Zygmuntowicz Yakima Herald-Republic WebMaster 509-577-7732 ezra-gdxLOakOTQ9oetBuM9ipNAC/G2K4zDHf@public.gmane.org
I have been working on a model security implementation for Rails.
In the declaration of your model, you include the module ModelSecurity,
and then you can can specify security tests for the various model
attributes similarly to the way that validators are specified:
require ''model_security.rb''
class User < ActiveRecord::Base
include ModelSecurity
let_read :activated, :cypher, :salt, :if => :logging_in?
let_write :id, :if :=> new_record?
...
This protects the attributes "activated", "cypher" and
"salt", and makes
them available for reading only if the method "logging_in?" returns
true
for the active record in question. The record ID can only be written if
the standard Rails method "new_record?" returns true, and thus a
record
can not be subverted to over-write a record with another ID.
Un-permitted read or write accesses result in an immediate exception -
it doesn''t want until you attempt to save the record as with
validators.
A complex security system can be constructed in just a few lines.
I have modified the generic editing-form methods used by scaffolds, such
as text_field, to heed the above security permissions. If there isn''t
permission to write the field, they render text instead of a form field.
They also render properly if a field is writable but not readable, or
not accessable at all. The modified form methods will not generate a
security violation on their own.
There is a method similar to the security specifications that hints to
the scaffold views what fields should be displayed:
let_display :activted, :if => :admin?
This is called on the active record''s class, rather than an instance as
in let_read and let_write, and is used to determine what fields should
get table columns before a scaffold view starts to iterate displaying
active records. This makes scaffolds somewhat smarter, as they can be
informed of what data is useful or permitted for display in a particular
context. Of course, this method can be made to function for your custom
views as well as scaffolds.
Since permissions are often coupled to logins, I have created a User
class that is loosely derived from the Salted Hash login generator. It
secures its own data using the above methods, and provides some generic
security tests for use in models, such as :admin? and :me? . :me?
returns true if the User object it''s invoked upon corresponds to the
currently-logged-in user. It also provides some before-filters for use
in controllers: require_admin will redirect to a login box until an
administrator logs in, and then will allow the requested action to
complete. require_login is similar, but it just wants a login, rather
than an administrator login. The login facility is extended to use Basic
HTTP authentication as well as the forms and tokens provided with Salted
Hash.
Using the facilities I am building, you can provide two levels of a
security defense in depth, by securing your controllers, and then your
models. You can add a third layer by securing the database. Model
security violations should not be exposed by properly secured
controllers, but they are there in case of the inevitable bug. It
strikes me that multiple layers of security might conflict with our
maxim to not repeat ourselves. I''d be interested in hearing opinions on
that.
I have also generalized the store_location method used in the Salted
Hash login generator to handle all sorts of modal pages, this lives in
the module "Modal".
This code isn''t ready for you to use, it''s just started to
work. But you
can look at it. I would greatly appreciate suggestions. It''s at
http://perens.com/FreeSoftware/Rails/ModelSecurity_0.01.tar.gz . Rubydoc
documentation is included.
This work is sponsored by Sourcelabs, who graciously support me to spend
half of my work hours doing whatever I wish for the Open Source community.
Many Thanks
Bruce Perens
Nice idea! I''ll definitely take a look at the source. Joe On Aug 2, 2005, at 11:46 AM, root wrote:> I have been working on a model security implementation for Rails. > > In the declaration of your model, you include the module > ModelSecurity, > and then you can can specify security tests for the various model > attributes similarlBry to the way that validators are specified: > > require ''model_security.rb'' > > class User < ActiveRecord::Base > include ModelSecurity > > let_read :activated, :cypher, :salt, :if => :logging_in? > let_write :id, :if :=> new_record? > ... > > This protects the attributes "activated", "cypher" and "salt", and > makes > them available for reading only if the method "logging_in?" returns > true > for the active record in question. The record ID can only be > written if > the standard Rails method "new_record?" returns true, and thus a > record > can not be subverted to over-write a record with another ID. > Un-permitted read or write accesses result in an immediate exception - > it doesn''t want until you attempt to save the record as with > validators. > A complex security system can be constructed in just a few lines. > > I have modified the generic editing-form methods used by scaffolds, > such > as text_field, to heed the above security permissions. If there isn''t > permission to write the field, they render text instead of a form > field. > They also render properly if a field is writable but not readable, or > not accessable at all. The modified form methods will not generate a > security violation on their own. > > There is a method similar to the security specifications that hints to > the scaffold views what fields should be displayed: > > let_display :activted, :if => :admin? > > This is called on the active record''s class, rather than an > instance as > in let_read and let_write, and is used to determine what fields should > get table columns before a scaffold view starts to iterate displaying > active records. This makes scaffolds somewhat smarter, as they can be > informed of what data is useful or permitted for display in a > particular > context. Of course, this method can be made to function for your > custom > views as well as scaffolds. > > Since permissions are often coupled to logins, I have created a User > class that is loosely derived from the Salted Hash login generator. It > secures its own data using the above methods, and provides some > generic > security tests for use in models, such as :admin? and :me? . :me? > returns true if the User object it''s invoked upon corresponds to the > currently-logged-in user. It also provides some before-filters for use > in controllers: require_admin will redirect to a login box until an > administrator logs in, and then will allow the requested action to > complete. require_login is similar, but it just wants a login, rather > than an administrator login. The login facility is extended to use > Basic > HTTP authentication as well as the forms and tokens provided with > Salted > Hash. > > Using the facilities I am building, you can provide two levels of a > security defense in depth, by securing your controllers, and then your > models. You can add a third layer by securing the database. Model > security violations should not be exposed by properly secured > controllers, but they are there in case of the inevitable bug. It > strikes me that multiple layers of security might conflict with our > maxim to not repeat ourselves. I''d be interested in hearing > opinions on > that. > > I have also generalized the store_location method used in the Salted > Hash login generator to handle all sorts of modal pages, this lives in > the module "Modal". > > This code isn''t ready for you to use, it''s just started to work. > But you > can look at it. I would greatly appreciate suggestions. It''s at > http://perens.com/FreeSoftware/Rails/ModelSecurity_0.01.tar.gz . > Rubydoc > documentation is included. > > This work is sponsored by Sourcelabs, who graciously support me to > spend > half of my work hours doing whatever I wish for the Open Source > community. > > Many Thanks > > Bruce Perens > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
+100 points for Sourcelabs. If only my company would pay me for open source work... Colin On 02/08/05, Joseph Hosteny <jhosteny-ee4meeAH724@public.gmane.org> wrote:> Nice idea! I''ll definitely take a look at the source. > > Joe > > On Aug 2, 2005, at 11:46 AM, root wrote: > > > I have been working on a model security implementation for Rails. > > > > In the declaration of your model, you include the module > > ModelSecurity, > > and then you can can specify security tests for the various model > > attributes similarlBry to the way that validators are specified: > > > > require ''model_security.rb'' > > > > class User < ActiveRecord::Base > > include ModelSecurity > > > > let_read :activated, :cypher, :salt, :if => :logging_in? > > let_write :id, :if :=> new_record? > > ... > > > > This protects the attributes "activated", "cypher" and "salt", and > > makes > > them available for reading only if the method "logging_in?" returns > > true > > for the active record in question. The record ID can only be > > written if > > the standard Rails method "new_record?" returns true, and thus a > > record > > can not be subverted to over-write a record with another ID. > > Un-permitted read or write accesses result in an immediate exception - > > it doesn''t want until you attempt to save the record as with > > validators. > > A complex security system can be constructed in just a few lines. > > > > I have modified the generic editing-form methods used by scaffolds, > > such > > as text_field, to heed the above security permissions. If there isn''t > > permission to write the field, they render text instead of a form > > field. > > They also render properly if a field is writable but not readable, or > > not accessable at all. The modified form methods will not generate a > > security violation on their own. > > > > There is a method similar to the security specifications that hints to > > the scaffold views what fields should be displayed: > > > > let_display :activted, :if => :admin? > > > > This is called on the active record''s class, rather than an > > instance as > > in let_read and let_write, and is used to determine what fields should > > get table columns before a scaffold view starts to iterate displaying > > active records. This makes scaffolds somewhat smarter, as they can be > > informed of what data is useful or permitted for display in a > > particular > > context. Of course, this method can be made to function for your > > custom > > views as well as scaffolds. > > > > Since permissions are often coupled to logins, I have created a User > > class that is loosely derived from the Salted Hash login generator. It > > secures its own data using the above methods, and provides some > > generic > > security tests for use in models, such as :admin? and :me? . :me? > > returns true if the User object it''s invoked upon corresponds to the > > currently-logged-in user. It also provides some before-filters for use > > in controllers: require_admin will redirect to a login box until an > > administrator logs in, and then will allow the requested action to > > complete. require_login is similar, but it just wants a login, rather > > than an administrator login. The login facility is extended to use > > Basic > > HTTP authentication as well as the forms and tokens provided with > > Salted > > Hash. > > > > Using the facilities I am building, you can provide two levels of a > > security defense in depth, by securing your controllers, and then your > > models. You can add a third layer by securing the database. Model > > security violations should not be exposed by properly secured > > controllers, but they are there in case of the inevitable bug. It > > strikes me that multiple layers of security might conflict with our > > maxim to not repeat ourselves. I''d be interested in hearing > > opinions on > > that. > > > > I have also generalized the store_location method used in the Salted > > Hash login generator to handle all sorts of modal pages, this lives in > > the module "Modal". > > > > This code isn''t ready for you to use, it''s just started to work. > > But you > > can look at it. I would greatly appreciate suggestions. It''s at > > http://perens.com/FreeSoftware/Rails/ModelSecurity_0.01.tar.gz . > > Rubydoc > > documentation is included. > > > > This work is sponsored by Sourcelabs, who graciously support me to > > spend > > half of my work hours doing whatever I wish for the Open Source > > community. > > > > Many Thanks > > > > Bruce Perens > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On 8/2/05, root <root-OhX/I19j0g7NRSUZWZ7BaQC/G2K4zDHf@public.gmane.org> wrote:> I have been working on a model security implementation for Rails. >[JOKE ON] How trust a guy using a root account for writing mail ? [JOKE OFF]
Ezra Zygmuntowicz wrote:> thats a great employer you have there that lets you spend half your > time on open source.Actually, all of my time :-) Of late, the company half has of my time has been about helping Fortune 500 corporations establish an Open Source strategy. In /every one/ I visit, I hear about Rails. Every one. In a law-enforcement-related department of one of the world''s greatest cities, there is a hotbed of Open Source development where several small Rails projects have been carried out. At one of the world''s biggest investment banking companies, the manager laments that all of his engineers want to use Rails, and it''s not mature enough yet. At a tremendous food company, they''ve been looking into Rails and the engineers smile when I talk about it. It''s very impressive how far the buzz has spread. Thanks Bruce _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
There is now a require_role which takes any block as its condition and,
in the arguments, text to present in the login form.
Thanks
Bruce
Jay Levitt wrote:
>In article <42EF404D.6000100-Dp076HI/R8PQT0dZR+AlfA@public.gmane.org>,
bruce-
>Dp076HI/R8PQT0dZR+AlfA-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org says...
>
>
>>This code isn''t ready for you to use, it''s just
started to work. But you
>>can look at it. I would greatly appreciate suggestions. It''s at
>>http://perens.com/FreeSoftware/Rails/ModelSecurity_0.01.tar.gz . Rubydoc
>>documentation is included.
>>
>>
>
>Bruce,
>
>This sounds terrific, and we''re glad to have you contributing!
What
>about changing require_admin to require_role (:admin), which would more
>easily genericize to RBAC as the module grows? I''m not sure if
that''s
>the best syntax, but you get where I''m going...
>
>-
>Jay Levitt |
>Wellesley, MA | I feel calm. I feel ready. I can only
>Faster: jay at jay dot fm | conclude that''s because I
don''t have a
>http://www.jay.fm | full grasp of the situation. - Mark Adler
>
>_______________________________________________
>Rails mailing list
>Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
Hi Bruce, Have you been able to generate the new version with a role into an updated gem? Cheers On 10/13/05, Bruce Perens <bruce-Dp076HI/R8PQT0dZR+AlfA@public.gmane.org> wrote:> > There is now a require_role which takes any block as its condition and, > in the arguments, text to present in the login form. > > Thanks > > Bruce > > Jay Levitt wrote: > > >In article <42EF404D.6000100-Dp076HI/R8PQT0dZR+AlfA@public.gmane.org>, bruce- > >Dp076HI/R8PQT0dZR+AlfA-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org says... > > > > > >>This code isn''t ready for you to use, it''s just started to work. But you > >>can look at it. I would greatly appreciate suggestions. It''s at > >>http://perens.com/FreeSoftware/Rails/ModelSecurity_0.01.tar.gz . Rubydoc > >>documentation is included. > >> > >> > > > >Bruce, > > > >This sounds terrific, and we''re glad to have you contributing! What > >about changing require_admin to require_role (:admin), which would more > >easily genericize to RBAC as the module grows? I''m not sure if that''s > >the best syntax, but you get where I''m going... > > > >- > >Jay Levitt | > >Wellesley, MA | I feel calm. I feel ready. I can only > >Faster: jay at jay dot fm | conclude that''s because I don''t have a > >http://www.jay.fm | full grasp of the situation. - Mark Adler > > > >_______________________________________________ > >Rails mailing list > >Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > >http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Oops. It''s called /require_condition. /It''s in 0.0.8 . There
is a slight
API change coming: In the next release, the first argument becomes the
"realm" for HTTP authentication. That argument is currently only
displayed in the login form.
Thanks
Bruce
/
/Liquid wrote:
> Hi Bruce,
>
> Have you been able to generate the new version with a role into an
> updated gem?
>
> Cheers
>
> On 10/13/05, *Bruce Perens* <
bruce-Dp076HI/R8PQT0dZR+AlfA@public.gmane.org
> <mailto:bruce-Dp076HI/R8PQT0dZR+AlfA@public.gmane.org>> wrote:
>
> There is now a require_role which takes any block as its condition
> and,
> in the arguments, text to present in the login form.
>
> Thanks
>
> Bruce
>
_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails