Re: Re: RE: Re: Stop using SYS, SYSTEM?
Facetious, but correct. What you need is auditing. Not clipping userids. Achieves nothing. Cheers Nuno Souto [EMAIL PROTECTED] - Original Message - > What I was saying is that having a different username for each DBA helps you > identify the WHOM. Of course a hacker could always cut knock the DBA unconscious and prop up his head to fool an eye retina scan, à la James Bond, but by that argument any username or IP address or whatever else you use is meaningless. > -- -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Nuno Souto INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Re: RE: Re: Stop using SYS, SYSTEM?
> -Original Message- > Nuno Pinto do Souto > > I don't want to know that SYSTEM or SOUTON with a subset > of its rights stuffed up my database or exported my main accounts > and clients tables. What I want to know is WHY, WHEN, HOW and > by WHOM. What I was saying is that having a different username for each DBA helps you identify the WHOM. Of course a hacker could always cut knock the DBA unconscious and prop up his head to fool an eye retina scan, à la James Bond, but by that argument any username or IP address or whatever else you use is meaningless. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jacques Kilchoer INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Re: RE: Re: Stop using SYS, SYSTEM?
-Original Message- Sent: Thursday, November 13, 2003 10:49 PM To: Multiple recipients of list ORACLE-L >Stopping someone from using a given set of accounts achieves preciously >nothing in terms of security (or auditing) IF the functionality of those >accounts >is then replicated to other accounts. Not if someone (I.e. an 'operator') is only using a portion of the access (COMPLETE) that is given to sys and/or system. >Fact is a DBA needs to be able to exp/imp (debatable, but let's ignore >that). >And manage rights. And manage space. And manage allocations, >And monitor the system. And a myriad of other tasks immaterial to the >point I'm trying to make. But a user account for Joe DBA and another user account for Jane DBA, etc, etc will provide accountability and tracability, vs a 'public' account does not. Just my $0.02 -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Cupp Michael E Contr Det 1 AFRL/WSI INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Re: RE: Re: Stop using SYS, SYSTEM?
> Arup Nanda <[EMAIL PROTECTED]> wrote: > I'm not sure that's what the OP wanted. He wanted to know if stopping > use of > SYS and SYSTEM on a regular basis will be acceptable, not "disable" > them. It > sure is. > Besides, how does one disable the account? Lock it? SYSTEM can be > locked but > SYS can't be; hence the whole concept of disabling does not make > sense. I hear what you're saying, but define "acceptable". And how do you stop someone from using a given userid other than disabling it? How do you disable is of course dependent on what the software maker provides you. In the case of SYS, probably change passwords is the only way. In the case of SYSTEM I think it can be disabled, although I'm not sure of the impact of that on tools that may need it. I'd rather use the password method, that way all I need do to "enable" it is change the password again. > I feel the auditors merely wanted the OP to stop using SYS and SYSTEM > on a > regular basis in operations that require a DBA access - such as full > exports > and selecting from disctionary tables. IMHO this is a very valid > advisory > and not difficult to follow. Stopping someone from using a given set of accounts achieves preciously nothing in terms of security (or auditing) IF the functionality of those accounts is then replicated to other accounts. Fact is a DBA needs to be able to exp/imp (debatable, but let's ignore that). And manage rights. And manage space. And manage allocations, And monitor the system. And a myriad of other tasks immaterial to the point I'm trying to make. Those are conveniently provided for by Oracle on a default install using the SYSTEM account. This is what it is for, this is the work of a DBA, this is WHY that account has been given those access rights. SYS is debatable and Oracle may now want to discourage people from using it. Fair enough. But SYSTEM is the DBA account par excellence, the same that root is also a sysadmin account. Now you may take away the accounts, but you MUST provide the functionality (or a subset) SOMEHOW, or else the DBA (or the sysadmin) can NOT do his/her work. If you provide the function through another account, then EFFECTIVELY, all you have achievced is change the name of the account that does that function. Security wise, you are back exactly where you started! And all you have achieved is create a whole lot of risks for the next person that comes along and installs some software. The auditors should be defining a set of functions that must be audited and to what level, and the DBA (and Oracle!) should look at how to implement those. If they are executed by logonid A, B or MXYZPTLK is essentially just spurious information (other than of course knowing WHO has the password for that ID!). Does Oracle provide a facility to properly audit all this? IMHO, far from it. But it's getting better. I don't want to know that SYSTEM or SOUTON with a subset of its rights stuffed up my database or exported my main accounts and clients tables. What I want to know is WHY, WHEN, HOW and by WHOM. So that I can reconstruct the events, and hopefully prevent the problem from ever happening again. Changing the login names DBAs use doesn't cut it for this, other than look good in "auditor's reports". If there is one thing that the military are good at (!) is in defining precisely what security and auditing consists of. Have a look at a secure military installation and you'll find it's not about stopping people from using this or that, it's about KNOWING who did what, how and when. Cheers Nuno Souto [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Nuno Pinto do Souto INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: RE: Re: Stop using SYS, SYSTEM?
Nuno Pinto do Souto" <[EMAIL PROTECTED]> wrote: > And that's why I feel disabling SYS or SYSTEM purely on > "security" grounds makes no sense whatsoever I'm not sure that's what the OP wanted. He wanted to know if stopping use of SYS and SYSTEM on a regular basis will be acceptable, not "disable" them. It sure is. Besides, how does one disable the account? Lock it? SYSTEM can be locked but SYS can't be; hence the whole concept of disabling does not make sense. I feel the auditors merely wanted the OP to stop using SYS and SYSTEM on a regular basis in operations that require a DBA access - such as full exports and selecting from disctionary tables. IMHO this is a very valid advisory and not difficult to follow. Arup - Original Message - To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Thursday, November 13, 2003 12:49 AM > > Jacques Kilchoer <[EMAIL PROTECTED]> wrote: > > In my case I also enforce the "don't sign on as SYS/SYSTEM" rule. The > > reasons I do that: > > - The default tablespace for SYS is SYSTEM, and I don't like to > > change that. There are probably reasons why you wouldn't want to > > change that. But when I sign on to do my DBA work to try something I > > don't want to have to specify a tablespace name every time I create a > > test object like CREATE TABLE TEST (X NUMBER) STORAGE (INITIAL 1000M) > > It has nothing to do with the dba role itself and its security. > Oracle just happens to associate user SYS with the SYSTEM tablespace. > Fair enough that you may not want that association by default. > > > - If each DBA has a named account, it's easy to tell who's logged in > > to the database by saying > > SELECT USERNAME FROM V$SESSION ; > > otherwise I would have to figure out who could be logged on as SYSTEM > > to call them and ask them if it's OK to shutdown the database. > > That is a pure audit requirement: you want to know who is using > DBA access. Nothing to do with SYSTEM. If you remove SYS and SYSTEM, > there is nothing in USERNAME in V$SESSION that will tell you username > BLOGGSJ is using DBA rights. Other than your own prior knowledge that > is the case. In a way, you're worse off. > > > Telling all the DBAs "sign on as SYSTEM" would be (IMHO) like telling > > all the programmers "You can all sign on as user 'coder'" and all > > users "you can all sign on in the database as user > > 'data_entry_person'". > > Don't they always? > > Quite frankly, the problem as I see it is that I want to know WHO > "dropped the tablespace" and WHEN and from WHERE. > That whoever did it had DBA access rights is a given, I don't need it > clarified! > > It's the who, when and where that is the province of auditing. And have > nothing to do with SYS, SYSTEM or whatever, other than as information. > Using or not using SYS or SYSTEM adds nothing to this knowledge or > its implicit security. > > And that's why I feel disabling SYS or SYSTEM purely on "security" grounds > makes no sense whatsoever. Of course, one may want to reduce the > risk of accidents and therefore lock those out. Even then, debatable if that is > the best way of doing it: accidentaly "dropping the tablespace" produces > the same chaotic results regardless of what account one does it from. > > > Cheers > Nuno Souto > [EMAIL PROTECTED] > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Nuno Pinto do Souto > INET: [EMAIL PROTECTED] > > Fat City Network Services-- 858-538-5051 http://www.fatcity.com > San Diego, California-- Mailing list and web hosting services > - > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Arup Nanda INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: RE: Re: Stop using SYS, SYSTEM?
> Jacques Kilchoer <[EMAIL PROTECTED]> wrote: > In my case I also enforce the "don't sign on as SYS/SYSTEM" rule. The > reasons I do that: > - The default tablespace for SYS is SYSTEM, and I don't like to > change that. There are probably reasons why you wouldn't want to > change that. But when I sign on to do my DBA work to try something I > don't want to have to specify a tablespace name every time I create a > test object like CREATE TABLE TEST (X NUMBER) STORAGE (INITIAL 1000M) It has nothing to do with the dba role itself and its security. Oracle just happens to associate user SYS with the SYSTEM tablespace. Fair enough that you may not want that association by default. > - If each DBA has a named account, it's easy to tell who's logged in > to the database by saying > SELECT USERNAME FROM V$SESSION ; > otherwise I would have to figure out who could be logged on as SYSTEM > to call them and ask them if it's OK to shutdown the database. That is a pure audit requirement: you want to know who is using DBA access. Nothing to do with SYSTEM. If you remove SYS and SYSTEM, there is nothing in USERNAME in V$SESSION that will tell you username BLOGGSJ is using DBA rights. Other than your own prior knowledge that is the case. In a way, you're worse off. > Telling all the DBAs "sign on as SYSTEM" would be (IMHO) like telling > all the programmers "You can all sign on as user 'coder'" and all > users "you can all sign on in the database as user > 'data_entry_person'". Don't they always? Quite frankly, the problem as I see it is that I want to know WHO "dropped the tablespace" and WHEN and from WHERE. That whoever did it had DBA access rights is a given, I don't need it clarified! It's the who, when and where that is the province of auditing. And have nothing to do with SYS, SYSTEM or whatever, other than as information. Using or not using SYS or SYSTEM adds nothing to this knowledge or its implicit security. And that's why I feel disabling SYS or SYSTEM purely on "security" grounds makes no sense whatsoever. Of course, one may want to reduce the risk of accidents and therefore lock those out. Even then, debatable if that is the best way of doing it: accidentaly "dropping the tablespace" produces the same chaotic results regardless of what account one does it from. Cheers Nuno Souto [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Nuno Pinto do Souto INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Re: Stop using SYS, SYSTEM?
> -Original Message- > Nuno Pinto do Souto > > Fact is: an admin user MUST have access to an admin > privileged account. > Call it whatever you want, root or role, who cares. In my case I also enforce the "don't sign on as SYS/SYSTEM" rule. The reasons I do that: - The default tablespace for SYS is SYSTEM, and I don't like to change that. There are probably reasons why you wouldn't want to change that. But when I sign on to do my DBA work to try something I don't want to have to specify a tablespace name every time I create a test object like CREATE TABLE TEST (X NUMBER) STORAGE (INITIAL 1000M) - If each DBA has a named account, it's easy to tell who's logged in to the database by saying SELECT USERNAME FROM V$SESSION ; otherwise I would have to figure out who could be logged on as SYSTEM to call them and ask them if it's OK to shutdown the database. Telling all the DBAs "sign on as SYSTEM" would be (IMHO) like telling all the programmers "You can all sign on as user 'coder'" and all users "you can all sign on in the database as user 'data_entry_person'". -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jacques Kilchoer INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Re: Stop using SYS, SYSTEM?
> Arup Nanda <[EMAIL PROTECTED]> wrote: > > Whoa! That came out pretty strong :) Fed-up with these new-fangled security "experts" popping up all over the place. Pretty soon we'll have another marketing driven lot of bullshit going round. With the usual crap associated with it. Next "big thing", you know the sort... > "Oracle provides this via SYS and SYSTEM" > > No, it doesn't. It has the DBA role for that. SYSTEM, I can accept as > a DBA > user, but not SYS; it's not a user to be used as an access mechanism; > it's > purpose is to be a schema - a repository. Splitting hairs here. Point is: SYS and SYSTEM are used by DBAs all over the world. If Oracle has chosen to add AS SYSDBA to SYS as a way of reinforcing that it is only to be used for very special purposes, that only reinforces my point: used ONLY by DBAs. And very sparingly, whenever needed. That has nothing to do with security of the role itself. > Remember the > initial days of Oracle 9i? I even remember the initial days of V5, let alone 9i! > > Take a page from our friendly neighborhood unix sys admins. Most > systems > require direct connect to root user on the console only; Not quite the case. root is accessible from anywhere, unless it's been assigned to a single terminal. It's not, by default. Ask a Unix sysadmin to give up his/hers "sudo" or even "su" and watch the reaction. Nearly impossible to do any work. Fact is: an admin user MUST have access to an admin privileged account. Call it whatever you want, root or role, who cares. If this access is directly on the console, via "sudo", via script, via auditing, via bleeding whatever, is completely the realm of semantics and policy. If a company has a policy that says admins must be "controlled", then do it the same way ANY OTHER engineering technical task is controlled: use auditing. Trying to artificially make access harder for those that need it is absolutely counter-productive and achieves nothing. Other than the Charlie Brown wet pants syndrome: gives you a warm feeling and nobody cares. By definition, the DBA role has certain privileges of access that are far less restrictive than anybody else. If that is granted via SYS, SYSTEM or role is not the issue. The issue is: can it be audited so that it is accountable for, if that is the policy of the company? > follwoing a good practice and obstructing progress. A cowboy > mentality to > approach any such issue might be a little detrimental, I think. > I think the last person you can associate a "cowboy mentality" approach in relation to is me, and I resent that remark. Its not by accident I have a current top level security clearance with the Australian Defense Forces and they don't usually grant them to cowboys... I'm getting a bit fed-up with my name being intentionally or not associated with "examples": there is simply no call for that and it's very old hat. Cheers Nuno Souto [EMAIL PROTECTED] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Nuno Pinto do Souto INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
