SEO

> > There is *NOTHING* wrong with the model in this case. It's the
> > specific implementation of the mdoel that is broken.
> > If you assign every user uid "0" in Unix, I beleive you'd
> get the same
> > problem as when you assign every user an admin on
> windows... Both are
> > equally stupid. There's just more software on windows that
> is designed
> > for such stupid environments, but it's not in the security
> model itself.
> > If it was in the actual security model, we'd have to do something.
>
> Actually, no. In UNIX is you are running as user 0, you can
> su to any other user ID, even if they don't exist. You can
> set it up so you can never go back, a trapdoor basically.

Ok. Didn't know that part about nonexistant ids.
As for su, you can su to a different user on windows as well. Either
using runas, or by replacing your process token. The second way requires
a specific user right to do it (which for example Local System always
has, which is why procucts like IIS can do it all the time), runas
doesn't.


> Under linux you can even give up all sorts of priveledges
> without changing your UID.

You can remove stuff from your token in Windows as well. Don't know many
that do, but you can (again, I *think* IIS is an example of this, but
I'm not sure).


> The difference with Windows appears to be that you can't
> willingly restrict your own priveledges without creating
> another user and switching to them.

You can, but it may be a bit harder than in *nix. It's just a whole lot
easier to switch to another user.


> For example, does the windows model allow you to say (without
> creating a new user): I irrevocably restrict my access to
> files owned by user X for this process *only*. Or to files
> under subdirectory Y. Or I irrevocably restrict my access to
> open new network sockets. Or irrevocably restrict my access
> to create new users.

Not entirely sure. You can get rid of privileges, and you can get rid of
group memberships. Don't think you can do it for a specific file,
because that's driven by the ACL on the file and not on the token. (You
can get rid of the group that had permissions on it which would give you
the same effect, but if someone granted your account direct permissions
on it, you'd still be able to access it).


> If this is possible then a patch might be accepted that would
> allow you to run as "admin" but only after giving up all the
> rights that aren't actually needed.


Hmm. I guess we could try the approach of dropping groups in pg_ctl
before we even call postmaster... Should be doable, if someone wants to
do the lifting. Tha way we could keep the admin check in the postmaster,
because we'd get rid of admin before we got there...


//Magnus

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Tue, Nov 15, 2005 at 08:43:06PM +0100, Magnus Hagander wrote:
> Ok. Didn't know that part about nonexistant ids.

Usernames are implementation details, if you ask to become user 38587,
the kernel doesn't check whether they exist. You just might not be able
to open any files anymore

> > For example, does the windows model allow you to say (without
> > creating a new user): I irrevocably restrict my access to
> > files owned by user X for this process *only*. Or to files
> > under subdirectory Y. Or I irrevocably restrict my access to
> > open new network sockets. Or irrevocably restrict my access
> > to create new users.
>
> Not entirely sure. You can get rid of privileges, and you can get rid of
> group memberships. Don't think you can do it for a specific file,
> because that's driven by the ACL on the file and not on the token. (You
> can get rid of the group that had permissions on it which would give you
> the same effect, but if someone granted your account direct permissions
> on it, you'd still be able to access it).

Ah, now we are making progress. If there was a way to give up file
access permissions so you could no longer write files to, say, the
Windows System directory, this would go a long way to solving the
issue. Currently, if the Postmaster runs as admin, anyone with access
to the database could use COPY to read and write any file the backend
can access.

> Hmm. I guess we could try the approach of dropping groups in pg_ctl
> before we even call postmaster... Should be doable, if someone wants to
> do the lifting. Tha way we could keep the admin check in the postmaster,
> because we'd get rid of admin before we got there...

Actually, it could possibly be acceptable to do it inside the
postmaster itself. It doesn't really matter where it's done, as long as
it permanently restricts the access of the postmaster from then on.

Quickly looking, I found a site [1] that refers to OpenProcessToken()
and AdjustTokenPrivileges() which appears to allow you to drop
permissions you have. There is also something called
CreateRestrictedToken() which can then to passed to
CreateProcessAsUser().

Maybe one of the Win32 hackers want to look into this to see what can
be done.

[1] http://www.winterdom.com/dev/security/tokens.html

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFDek6YIB7bNG8LQkwRAvS2AJ9K9p/pDs7Jfg2NMCXa2gcVuWIURACbBvaE
LPltir2GGfgyIg0kRXdpFJI=
=bllo
-----END PGP SIGNATURE-----