Menu
▾
▴
#66 Unlimited file write access
open-accepted
9
2004-10-24
2004-10-24
No
App-fileservices does not perform any kind of security,
permission, or location verification before accepting a
file and writing it to the HD. It can receive files
with system names, and write them to anywhere in the
filesystem, if Keel is running as a "System User", with
appropriate privileges. This also allows one user to
overwrite the file contents of another user.
The solution for this is two fold;
1) app-fileservices can no longer accept the directory
name of where to write the file to. Instead, it should
accept a key to use as a lookup from a list of
directory names. Persistent object needs to be
designed/created.
2) App-fileservices needs to track the user and group
that uploads a file, so that appropriate access can be
granted to the stored file.
Note: This bug has the potential to replace SYSTEM FILES.
Since svc-fileupload 0.1.0
Logged In: YES
user_id=490856
As part of the solution to #2 (above), app--security will
need to be fixed and upgraded, so that users can grant
access for their files to other parties, and
change/add/delete which groups have access to the files.
Logged In: YES
user_id=736374
I have the following 3 suggestions to think about in the
redesign:
i) Allow the ability to write not only to a directory, but also
to sub-directories. This capability would allow
our current app to continue to work with the new service
ii) Include an algorithm to check directory and file names
for ".." and exclude those as invalid.
This is to prevent hacks such as
passing "../../../autoexec.bat" to by-pass the restrictions
that we are trying to add. Using getCannonicalName (or
something like that) we could compare the full qualified file
name to a fully qualified list of allowable write locations to
produce a fairly straightforward implementation of this.
iii) Regarding the permissions, you may want to weigh the
idea of adding groups and permissions to the app-file-svcs vs
the idea of making changes keel to restrict app-file_svcs so
that it can only be called by another model. The idea would
be a pattern where a person implements access rights at the
application level, and the file-services is always accessed by
a front-controller that implements and enforces the particular
security, if any, based on business rules. Keel could also
come with a default front controller that allows open-access,
but that front controller could be replaced a "custom" one
that implements whatever business logic is desired.
Glad to hear that app-file-svcs lives!
-Phil
Logged In: YES
user_id=490856
I am thinking of implementing the following approaches;
1), A peristent with DIrectory names. Client would pass
the Keys for directory that it wanted to write to.
Subdirectories would still be allowed.
2) File.getAbsolutePath(), File.getCanonicalPath(), etc
would be used to make sure SubDirectory did not go outside
allowed "tree"/path.
3) Mike Nash implemented Keel security a with a variation of
ACLs (Access Control Lists). One can define one or more
groups to have access to a User's or Group's files, with
various permissions allowed per group. Currently, this
feature can only be accessed via direct manipulation of the
Schemas. By fixing app-security, the standalones
applications will also have access to this feature.