Hi!
I just wanted to let you know that using Novell's AppArmor with TG is a
success and very easy. It restricts a lot of what your application can read /
write to the file system, also restricting what modules -- python or binary
modules -- can do.
I'm wrapping my applications with it to prevent some unauthorized access to
the filesystem and so far things have been great (including some occasional
problems because I forget to give access to something ;-)).
So, today, I -- we -- can count with different access restrictions for our
TurboGears applications:
- filesystem level through Novell's AppArmor (my case)
* includes loading libraries, Python modules, writing to logfiles,
reading templates, static files, third party modules, etc.
This grants me that no flaw in my code or CherryPy's or TG's code
would allow an attacker to access files outside of the specified
tree. It is a "physical" protection, since data in your database
isn't protected by this -- neither any other information obtained
via sockets or other connections established by your application.
The attacker will have access to anything the profile of the
application allows. If he gets to get to the system shell, then he'll
be restricted by system permissions (and other applications profiles,
of course).
- application level through turbogears.identity (generic)
* this is very flexible and easy to use / customize. Require some kind
of permission for each action and then create those permissions on the
database, later let the administrative user create groups of
permissions and assign those groups to common users of your
application. All should be easily done.
The "secret" here is making the application requires a different
permission for each different thing. You can have more than one
permission if you think it should be done (I usually grant access to
anything for the admin group and the admin permission besides the
required access permission for each action).
Delegating the responsability to the client is also interesting
because he is the one that knows how critical is some information or
process and you will only have the work to create the permissions on
the system and an "admin" user so that he can work with granting /
revoking access.
- database level through database permissions (GRANT/REVOKE) (not
available, highly desired)
* this is, IMHO, the most fragile part because the connection is made
with one "administrative" user that is restricted by identity. If the
connection was (re-)opened with the authenticated user or changed to
the user that authenticated himself it would be much better.
I dunno how to enforce that in TG's environment yet, specially because
of the connection pool (PostgreSQL's SET ROLE and RESET ROLE should be
used, but I dunno exactly where I should issue those yet) and the
auto-wrapped transactions.
When this is working, the user used to start TurboGears should have
minimum access -- probably just connecting to the database and doing
some basic authentication against tg_* tables or the system before
having his role changed...
If I get this to work, I'll post here how I did it. It is another
security layer that should reflect roles and groups created in the
application and handled with identity. So, for each table, you'd have
at least the same kind of permissions you created in your code then
you'd have to create groups and users that have those permissions
associated with them.
Why duplicating it here? Because you might want to access your data
from other applications, you might want to allow the user to have some
kind of BI tool to generate reports, etc. and those usually require
direct access to the database through some JDBC / ODBC connection and
won't work with your JSON or HTML output.
That said, I believe that we can achieve a "medium" security regarding access
to our data. The greatest flaws being the cleartext password in the
production configuration file and the lack of using different roles to access
the database.
Feel free to comment or enhance this post :-)
--
Jorge Godoy <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~----------~----~----~----~------~----~------~--~---
