Results 1 to 7 of 7

Thread: Guest account

  1. #1
    Join Date
    Aug 2009
    Posts
    17

    Unanswered: Guest account

    Hi, what is the risk of not deleting or blocking the guest account?

  2. #2
    Join Date
    Mar 2009
    Location
    Sydney, Australia
    Posts
    258
    Nothing actually.

    It depends on how well or how badly your security model is set up. In a good security model, where all users have permissions (roles, or groups in the old paradigm) explicitly granted; and users are explicitly added to the db (to grant access to the db), there is no problem. In fact many security conscious orgs delete guest (user) and public (group).

    In a medium security set up, where the above is not done, where users are not explicitly granted access to each db, then they are using guest (or the public group). They have whatever permissions are granted to guest: usually select and reference to non-confidential tables only. You can grant insert/update/delete to guest, but that is asking for trouble. Check what permissions have been granted to guest/public, that will tell you if it is being used.

    In a poor security model, what little security is set up, users may well be counting on guest, to access the db.

    If you are using newer login/roles only, and not the older user/groups, then guest and public are a relic of the older paradigm, and can be deleted without further examination.

    If you are cleaning up pas mistakes by predecessors. One way of andling your question is, just delete guest/public, and see who screams that they cannot access the db; then give them formal and chosen access as per your security model.
    Regards
    Derek Asirvadem (Formerly DerekA)
    Information Architect / Senior Sybase DBA
    Copyright 2009 Software Gems Pty Ltd

    I answer questions from the Original Poster only. If you have a genuine question, as the moderators have requested, start a new thread.

    http://www.softwaregems.com.au

  3. #3
    Join Date
    Aug 2009
    Posts
    17
    It has been hard to find information about how to audit security in Syabase; to know if the configuration is or nor secure.

    If the secure default login is guest, where can I look at to know how "big" is the access level of guest?

  4. #4
    Join Date
    Aug 2009
    Posts
    17
    Reading some papers found that guest account can inherit the access level configured to public, is it true?

  5. #5
    Join Date
    Mar 2009
    Location
    Sydney, Australia
    Posts
    258
    Auditing Security (In Sybase, MS, Oracle & DB2)
    It is not hard to do, you just have to know what security is; what a good security model is, so that you have a measure against which you can compare the security you are auditing. The RDBMS systems allow for various levels and forms of security; implementing security is the job of the DBA (anyone with sso_role). Just like and SQL code (a) it doesn't exist until you put it in and (b) it is only as good (quality) as the knowledge and experience level of the implementor. Nothing to do with the vendor.

    Personally, I find Sybase the easiest of all to Audit. I just walk in, run a couple of scripts and that tells me everything. "Digging in" is also easy: everything is located in catalogue tables (sys&#37, accessible via SQL.

    Whether the configuration is secure or not depends in part on the implementation of a good model; and what you are comparing against. Get someone professional to do it. I do an aduit of security as a small part of a full Technical Audit which is only a few days; what I am saying is, if you have the scripts, and you know the job (security model; what is and isn't acceptable at each level), a security audit is half a days work. Depending on your knowledge and experience level, it will take a substantially more than that.
    Reading some papers found that guest account can inherit the access level configured to public, is it true?
    There is an awful lot of rubbish and half-facts on the web. The manuals are more precise (not suggesting they are perfect or that you can learn what is a good model or a good database from them, they are merely poduct manuals). That is true but stated completely incorrectly.

    Old paradigm: Groups and users
    • public is a Group within the db (not the server)
    • guest is an User
    • normally you add Users to the database (that allows them to connect but not access tables)
    • when you add Users, you add them AS members of a Group.
    • it would be onerous, if you had to then Grant [select/reference/insert/update/delete] for each table for each User
    • therefore you Grant select/reference/insert/update/delete] for each table to selected Groups, once
    • adding the User to the Group gives them all the permissions of that Group (I would not call it inheritance)
    • an User can belong to only one Group
    • with many tables and many different sets of permissions, this soon becomes a limitation
    • granting permissions to both Groups and Users is a very silly thing to do, very messy, and hard to find/fix

    Therefore yes, guest user always has the permissions of the public group, because that is the group it belongs to (unless you change its group).

    Again, in a tight security model, both guest and public are disabled.
    In a very tight security model, where access to the system, the server, is heavily restricted by other means; and where therefore, anyone accessing the server is allowed to (eg) select/reference all tables, then guest and public can be retained, and public granted select/reference to whatever tables are not confidential to an user.

    New Paradigm: Roles
    • Roles replace Groups
    • Roles are server level, not db level, they operate across any db in the server
    • Users can have more than one Role assigned to them
    • that eliminates the limitations of the old paradigm, and eases the permissions administration
    • you still have to add Users to each db, to allow them to connect to it
    • but once, connected, they have (not inherit) whatever permissions have been granted to the multiple Roles they have
    • if you change the permissions of the Group/Role, they are changed immediately across the database/server (not inheritance)
    Regards
    Derek Asirvadem (Formerly DerekA)
    Information Architect / Senior Sybase DBA
    Copyright 2009 Software Gems Pty Ltd

    I answer questions from the Original Poster only. If you have a genuine question, as the moderators have requested, start a new thread.

    http://www.softwaregems.com.au

  6. #6
    Join Date
    Aug 2009
    Posts
    17
    Thanks Derek, was really ilustrative;

  7. #7
    Join Date
    Mar 2009
    Location
    Sydney, Australia
    Posts
    258
    My pleasure.
    Regards
    Derek Asirvadem (Formerly DerekA)
    Information Architect / Senior Sybase DBA
    Copyright 2009 Software Gems Pty Ltd

    I answer questions from the Original Poster only. If you have a genuine question, as the moderators have requested, start a new thread.

    http://www.softwaregems.com.au

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •