[opensuse-security] EAL 3 and 4 rated versions.
I recently discovered that there are security hardened version of SUSE that are certified/accredited to EAL 3 and even EAL 4. Does anyone have any experienced feedback on how restrictive these setups are? We are looking to implement a data retreival system that access disks over NFS and tape drives over SCSI, but does little else. Would like to know if I could still do these simple things. Regards, Mark Armstrong --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Hey Mark,
I recently discovered that there are security hardened version of SUSE that are certified/accredited to EAL 3 and even EAL 4.
Does anyone have any experienced feedback on how restrictive these setups are?
We are looking to implement a data retreival system that access disks over NFS and tape drives over SCSI, but does little else. Would like to know if I could still do these simple things.
Regards,
Mark Armstrong
I'm not sure if one can call the evaluated configuration a "hardened" system. There are some configuration files for pam and account management and some predefined config files for some packages, resulting in stricter file modes (using permissions.eal4) and some unnecessary stuff turned off. There is a package called certification-sles-eal4 that is available in the SLES9 update trees. It contains * the so-called security guide, a step-by-step documentation to deliver the fresh install to the evaluated configuration, * a script that does the same semi- or fully automatically, * a set of config files that are being overwritten by the script, and * a list of packages that are required or tolerated in the installation. Have a look at http://ftp.suse.com/pub/people/draht/misc/eal4/ . I have put the contents of that package in there for you to have a look at it. Be aware that the "Common Criteria EAL4+ Evaluated Configuration Guide for SUSE LINUX Enterprise Server on IBM Hardware" is copyrighted by atsec GmbH, Klaus Weidner. The script has been written by me and Klaus. Thanks, Roman. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Hi Roman I don't think I can use the specific hardware specified unless one of them is a relatively standard PC, which according to the documentation invalidates the certification. But the OS aspect seems to provide a set-up that is robust with all appropriate security features such as logging, audit, enhanced password protection etc. What is the normal mechanism of using the script etc. I'd have to sign up for SLES9 which one assumes can still be bought from SUSE. Then to use the EAL4 configuration, can I acquire a right to use through SUSE or ATSEC? Mark Roman Drahtmueller wrote:
Hey Mark,
I recently discovered that there are security hardened version of SUSE that are certified/accredited to EAL 3 and even EAL 4.
Does anyone have any experienced feedback on how restrictive these setups are?
We are looking to implement a data retreival system that access disks over NFS and tape drives over SCSI, but does little else. Would like to know if I could still do these simple things.
Regards,
Mark Armstrong
I'm not sure if one can call the evaluated configuration a "hardened" system. There are some configuration files for pam and account management and some predefined config files for some packages, resulting in stricter file modes (using permissions.eal4) and some unnecessary stuff turned off.
There is a package called certification-sles-eal4 that is available in the SLES9 update trees. It contains
* the so-called security guide, a step-by-step documentation to deliver the fresh install to the evaluated configuration, * a script that does the same semi- or fully automatically, * a set of config files that are being overwritten by the script, and * a list of packages that are required or tolerated in the installation.
Have a look at http://ftp.suse.com/pub/people/draht/misc/eal4/ . I have put the contents of that package in there for you to have a look at it.
Be aware that the "Common Criteria EAL4+ Evaluated Configuration Guide for SUSE LINUX Enterprise Server on IBM Hardware" is copyrighted by atsec GmbH, Klaus Weidner. The script has been written by me and Klaus.
Thanks, Roman.
-- _______________________________________________________________________ Mark Armstrong Email: msa@kaon.co.uk Chief Engineer Web: www.kaon.co.uk Office: +44 (0) 1483 885302 Fax: +44 (0) 1483 885301 Mobile: +44 (0) 7771 967588 Kaon Limited, 5 Wey Court, Mary Road, Guildford, Surrey, GU1 4QU, UK Disclaimer This communication is intended for the addressee(s) only, and is private and confidential. If you are not the intended recipient, any disclosure, copying, distribution or any other unauthorised dissemination is prohibited and unlawful. Please inform the sender immediately if you are not the intended addressee. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Mark Armstrong wrote:
I recently discovered that there are security hardened version of SUSE that are certified/accredited to EAL 3 and even EAL 4.
Does anyone have any experienced feedback on how restrictive these setups are?
We are looking to implement a data retreival system that access disks over NFS and tape drives over SCSI, but does little else. Would like to know if I could still do these simple things. What is it you are trying to achieve? Security, or compliance?
The SLES9 EAL3 and EAL4+ configurations are exceedingly strict; to be in compliance, you have to have the exact software and hardware configuration specified. However, it is not a particularly secure configuration. Because it specifies an exact configuration, and it is now quite old (early 2004) many advances are technically not permitted in a compliant configuration. To achieve a high level of server security, you should, first of all, keep it up to date by running the update tools frequently. The second thing to do is to close all unnecessary network ports. There are several tools for that, including netstat (which lists the open ports) and Nessus (which does a detailed vulnerability assessment of the applications you are hosting). You should also use the AppArmor tools to secure your applications. AppArmor also has a tool to scan your server for open network ports called aa-unconfined. This program lists open network ports, the programs listening to those ports, and the AppArmor profiles wrapped around those programs, if any. Your goal here is to use AppArmor to confine all of the programs with open network ports. If you do that, then all network attackers are forced to go through your AppArmor policies. This does not perfectly prevent all intrusions (no policy mechanism can) but it does strictly bound what damage the attacker can do. All of these steps (updates, netstat, Nessus, and AppArmor) will do lots to help your security, but nothing to help your compliance with regulations. The EAL certified configurations are rather the converse; it does little to help your security, other than by providing a lower bound that your security isn't absolutely horrid, but does a lot to provide CYA (Cover Your Assets :-) by being compliant. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Hi Crispin, All your points are very true, unfortunately I'm looking to put a server into an environment where risk assessment and use of certified products makes the bureaucracy happy. It is currently an area dominated by certified versions of Solaris, Windows and RHES that were thought to be the only certified OS flavours available. Having used SUSE for over 8 years I'd be a lot more comfortable with SLES doing the work for me. As for the strictness and hardware aspect, I'd be surprised if the RHES machines operating in the target environment are on the hardware they were certified for. This is a loophole in the beauracracy that I might be able to exploit. My problem is that I could argue until I was blue in the face the advantages of using the latest version of SUSE10 from a security perspective, then be told I can NOT connect the machine to their network. (This network will never be connected to the internet so live updates are a none starter) But say this EAL3 product fills the gap in my risk assessment to CYA and off I go. Also as a man who does not have the time to be a good system administrator, a good script from a reputable supplier that adds the features I need will make me a happy camper. Mark Crispin Cowan wrote:
Mark Armstrong wrote:
I recently discovered that there are security hardened version of SUSE that are certified/accredited to EAL 3 and even EAL 4.
Does anyone have any experienced feedback on how restrictive these setups are?
We are looking to implement a data retreival system that access disks over NFS and tape drives over SCSI, but does little else. Would like to know if I could still do these simple things.
What is it you are trying to achieve? Security, or compliance?
The SLES9 EAL3 and EAL4+ configurations are exceedingly strict; to be in compliance, you have to have the exact software and hardware configuration specified.
However, it is not a particularly secure configuration. Because it specifies an exact configuration, and it is now quite old (early 2004) many advances are technically not permitted in a compliant configuration.
To achieve a high level of server security, you should, first of all, keep it up to date by running the update tools frequently.
The second thing to do is to close all unnecessary network ports. There are several tools for that, including netstat (which lists the open ports) and Nessus (which does a detailed vulnerability assessment of the applications you are hosting).
You should also use the AppArmor tools to secure your applications. AppArmor also has a tool to scan your server for open network ports called aa-unconfined. This program lists open network ports, the programs listening to those ports, and the AppArmor profiles wrapped around those programs, if any.
Your goal here is to use AppArmor to confine all of the programs with open network ports. If you do that, then all network attackers are forced to go through your AppArmor policies. This does not perfectly prevent all intrusions (no policy mechanism can) but it does strictly bound what damage the attacker can do.
All of these steps (updates, netstat, Nessus, and AppArmor) will do lots to help your security, but nothing to help your compliance with regulations. The EAL certified configurations are rather the converse; it does little to help your security, other than by providing a lower bound that your security isn't absolutely horrid, but does a lot to provide CYA (Cover Your Assets :-) by being compliant.
Crispin
-- _______________________________________________________________________ Mark Armstrong Email: msa@kaon.co.uk Chief Engineer Web: www.kaon.co.uk Office: +44 (0) 1483 885302 Fax: +44 (0) 1483 885301 Mobile: +44 (0) 7771 967588 Kaon Limited, 5 Wey Court, Mary Road, Guildford, Surrey, GU1 4QU, UK Disclaimer This communication is intended for the addressee(s) only, and is private and confidential. If you are not the intended recipient, any disclosure, copying, distribution or any other unauthorised dissemination is prohibited and unlawful. Please inform the sender immediately if you are not the intended addressee. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello! Don't forget this aspect: A lot of statistics show that most internal intrusion comes from inside a lot of companies so don't say a network not connected to the internet is safe from internal intrusion. There are a lot of ways to bypass security mechanisms if systems are outdated. - From the SLES point of view there is a longer supported life time of products and updates will be available a longer time. Another aspect is the certification of hardware for SuSE - there are a lot of more drivers for difficult hardware than on other distributions with their way of thinking forbidding some kind of drivers - e.g. use of redmond kind wireless drivers od special Raid drivers. The best way to argue is to catch advantages and disadvantages for an argumentation (possibly having enough point for the supposed point of view). Don't think in your way try to get in the other persons point of view: Find ways to spare money for the entusiasts and bureaucrats e.g. price per license and compare RHES and SLES and their advantages and disadvantages and what they get of it (e.g. more productivity per $ as 10 licenses cost like 9 licenses of the other product ...). Good luck with argumentation! Regards Philippe Mark Armstrong schrieb:
Hi Crispin,
All your points are very true, unfortunately I'm looking to put a server into an environment where risk assessment and use of certified products makes the bureaucracy happy. It is currently an area dominated by certified versions of Solaris, Windows and RHES that were thought to be the only certified OS flavours available. Having used SUSE for over 8 years I'd be a lot more comfortable with SLES doing the work for me.
As for the strictness and hardware aspect, I'd be surprised if the RHES machines operating in the target environment are on the hardware they were certified for. This is a loophole in the beauracracy that I might be able to exploit. My problem is that I could argue until I was blue in the face the advantages of using the latest version of SUSE10 from a security perspective, then be told I can NOT connect the machine to their network. (This network will never be connected to the internet so live updates are a none starter)
But say this EAL3 product fills the gap in my risk assessment to CYA and off I go.
Also as a man who does not have the time to be a good system administrator, a good script from a reputable supplier that adds the features I need will make me a happy camper.
Mark
Crispin Cowan wrote:
Mark Armstrong wrote:
I recently discovered that there are security hardened version of SUSE that are certified/accredited to EAL 3 and even EAL 4.
Does anyone have any experienced feedback on how restrictive these setups are?
We are looking to implement a data retreival system that access disks over NFS and tape drives over SCSI, but does little else. Would like to know if I could still do these simple things.
What is it you are trying to achieve? Security, or compliance?
The SLES9 EAL3 and EAL4+ configurations are exceedingly strict; to be in compliance, you have to have the exact software and hardware configuration specified.
However, it is not a particularly secure configuration. Because it specifies an exact configuration, and it is now quite old (early 2004) many advances are technically not permitted in a compliant configuration.
To achieve a high level of server security, you should, first of all, keep it up to date by running the update tools frequently.
The second thing to do is to close all unnecessary network ports. There are several tools for that, including netstat (which lists the open ports) and Nessus (which does a detailed vulnerability assessment of the applications you are hosting).
You should also use the AppArmor tools to secure your applications. AppArmor also has a tool to scan your server for open network ports called aa-unconfined. This program lists open network ports, the programs listening to those ports, and the AppArmor profiles wrapped around those programs, if any.
Your goal here is to use AppArmor to confine all of the programs with open network ports. If you do that, then all network attackers are forced to go through your AppArmor policies. This does not perfectly prevent all intrusions (no policy mechanism can) but it does strictly bound what damage the attacker can do.
All of these steps (updates, netstat, Nessus, and AppArmor) will do lots to help your security, but nothing to help your compliance with regulations. The EAL certified configurations are rather the converse; it does little to help your security, other than by providing a lower bound that your security isn't absolutely horrid, but does a lot to provide CYA (Cover Your Assets :-) by being compliant.
Crispin
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQD1AwUBRk2RL0Ng1DRVIGjBAQLJSAb/Unw7l9tiPgKj2OKCiKEAHRISwK4UHPSP 6KUQHUDVlKBFTTxSXNhngxYZXGVchJCS41hkl1TZmlWy+5oN1sh4IUCFDbiBnFYV uwNjdGhjjhqpZf2LdWm1qAt7yqs666Ego8czbOJ/ys2PBBp/BZBNhAj3XdLKy4Ng gLmbh4hfzV2QAK3c4iROhtwaeyhV9FiqetUCWarO1AwG0eI9nQyUeBcjW5X4tB/q 8xx04lTyc2NpY7cQ37bA0wso8S2agRT0mFPlu6BsqMF+V0UToUp23YYTzps7kwJD CAvRRx5+FcQ= =MPdq -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
The inclusion of any security measures in the system I'm talking about are mainly to stop internal intrusion by people that do not have the right to see certain data. And one mustn't forget visitors. That is where password and logging aspects that are improved in the EAL configuration are important. If there is any mischief one wants a record of it. Ideally there would be up to date certified versions, but these things are costly and not used by many people. And judging by some comments in this thread, thought by some to not be worth the paper they are printed on once a short amount to time has gone by. :-) But, bureaucrats and decision makers that know next to nothing about computers need some badge to cover their assets with at times. In the mean time I'm still trying to figure out why SLES9 is 100Eur more expensive than SLES10. That's progress, at least I can still buy it and for that I'm grateful.. Mark Philippe Vogel wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello!
Don't forget this aspect:
A lot of statistics show that most internal intrusion comes from inside a lot of companies so don't say a network not connected to the internet is safe from internal intrusion. There are a lot of ways to bypass security mechanisms if systems are outdated.
- From the SLES point of view there is a longer supported life time of products and updates will be available a longer time.
Another aspect is the certification of hardware for SuSE - there are a lot of more drivers for difficult hardware than on other distributions with their way of thinking forbidding some kind of drivers - e.g. use of redmond kind wireless drivers od special Raid drivers.
The best way to argue is to catch advantages and disadvantages for an argumentation (possibly having enough point for the supposed point of view). Don't think in your way try to get in the other persons point of view: Find ways to spare money for the entusiasts and bureaucrats e.g. price per license and compare RHES and SLES and their advantages and disadvantages and what they get of it (e.g. more productivity per $ as 10 licenses cost like 9 licenses of the other product ...).
Good luck with argumentation!
Regards
Philippe
Mark Armstrong schrieb:
Hi Crispin,
All your points are very true, unfortunately I'm looking to put a server into an environment where risk assessment and use of certified products makes the bureaucracy happy. It is currently an area dominated by certified versions of Solaris, Windows and RHES that were thought to be the only certified OS flavours available. Having used SUSE for over 8 years I'd be a lot more comfortable with SLES doing the work for me.
As for the strictness and hardware aspect, I'd be surprised if the RHES machines operating in the target environment are on the hardware they were certified for. This is a loophole in the beauracracy that I might be able to exploit. My problem is that I could argue until I was blue in the face the advantages of using the latest version of SUSE10 from a security perspective, then be told I can NOT connect the machine to their network. (This network will never be connected to the internet so live updates are a none starter)
But say this EAL3 product fills the gap in my risk assessment to CYA and off I go.
Also as a man who does not have the time to be a good system administrator, a good script from a reputable supplier that adds the features I need will make me a happy camper.
Mark
Crispin Cowan wrote:
Mark Armstrong wrote:
I recently discovered that there are security hardened version of SUSE that are certified/accredited to EAL 3 and even EAL 4.
Does anyone have any experienced feedback on how restrictive these setups are?
We are looking to implement a data retreival system that access disks over NFS and tape drives over SCSI, but does little else. Would like to know if I could still do these simple things.
What is it you are trying to achieve? Security, or compliance?
The SLES9 EAL3 and EAL4+ configurations are exceedingly strict; to be in compliance, you have to have the exact software and hardware configuration specified.
However, it is not a particularly secure configuration. Because it specifies an exact configuration, and it is now quite old (early 2004) many advances are technically not permitted in a compliant configuration.
To achieve a high level of server security, you should, first of all, keep it up to date by running the update tools frequently.
The second thing to do is to close all unnecessary network ports. There are several tools for that, including netstat (which lists the open ports) and Nessus (which does a detailed vulnerability assessment of the applications you are hosting).
You should also use the AppArmor tools to secure your applications. AppArmor also has a tool to scan your server for open network ports called aa-unconfined. This program lists open network ports, the programs listening to those ports, and the AppArmor profiles wrapped around those programs, if any.
Your goal here is to use AppArmor to confine all of the programs with open network ports. If you do that, then all network attackers are forced to go through your AppArmor policies. This does not perfectly prevent all intrusions (no policy mechanism can) but it does strictly bound what damage the attacker can do.
All of these steps (updates, netstat, Nessus, and AppArmor) will do lots to help your security, but nothing to help your compliance with regulations. The EAL certified configurations are rather the converse; it does little to help your security, other than by providing a lower bound that your security isn't absolutely horrid, but does a lot to provide CYA (Cover Your Assets :-) by being compliant.
Crispin
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQD1AwUBRk2RL0Ng1DRVIGjBAQLJSAb/Unw7l9tiPgKj2OKCiKEAHRISwK4UHPSP 6KUQHUDVlKBFTTxSXNhngxYZXGVchJCS41hkl1TZmlWy+5oN1sh4IUCFDbiBnFYV uwNjdGhjjhqpZf2LdWm1qAt7yqs666Ego8czbOJ/ys2PBBp/BZBNhAj3XdLKy4Ng gLmbh4hfzV2QAK3c4iROhtwaeyhV9FiqetUCWarO1AwG0eI9nQyUeBcjW5X4tB/q 8xx04lTyc2NpY7cQ37bA0wso8S2agRT0mFPlu6BsqMF+V0UToUp23YYTzps7kwJD CAvRRx5+FcQ= =MPdq -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-- _______________________________________________________________________ Mark Armstrong Email: msa@kaon.co.uk Chief Engineer Web: www.kaon.co.uk Office: +44 (0) 1483 885302 Fax: +44 (0) 1483 885301 Mobile: +44 (0) 7771 967588 Kaon Limited, 5 Wey Court, Mary Road, Guildford, Surrey, GU1 4QU, UK Disclaimer This communication is intended for the addressee(s) only, and is private and confidential. If you are not the intended recipient, any disclosure, copying, distribution or any other unauthorised dissemination is prohibited and unlawful. Please inform the sender immediately if you are not the intended addressee. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
All your points are very true, unfortunately I'm looking to put a server into an environment where risk assessment and use of certified products makes
Mark Armstrong wrote: the
bureaucracy happy.
SLES 10 (SP1) is under re-evaluation at CAPP/EAL4+. See http://niap.bahialab.com/cc-scheme/in_evaluation.cfm It should complete before too long. Does that satisfy your requirement? Emily --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Emily Ratliff wrote:
Mark Armstrong wrote:
All your points are very true, unfortunately I'm looking to put a server into an environment where risk assessment and use of certified products makes the bureaucracy happy.
SLES 10 (SP1) is under re-evaluation at CAPP/EAL4+. See http://niap.bahialab.com/cc-scheme/in_evaluation.cfm It should complete before too long. Does that satisfy your requirement? And SLES9 has CAPP/EAL4+, and was the very first Linux distro to get EAL4+. Similarly, SUSE Linux was the first to get EAL3, and the first Linux distro to get Common Criteria certification of any kind.
SUSE has a deep history of pioneering Common Criteria certification for Linux. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
That is very interesting to know, thank you. I don't have to bring my system together until 1st quarter 2008 so SLES 10 is an option. Would that mean that if I used SLES 10 SP1 on an appropriate hardware platform it would be considered to meet the common criteria (assuming it passes re-eval), or is it slightly more complicated than that? Mark Emily Ratliff wrote:
Mark Armstrong wrote:
All your points are very true, unfortunately I'm looking to put a server into an environment where risk assessment and use of certified products makes the bureaucracy happy.
SLES 10 (SP1) is under re-evaluation at CAPP/EAL4+. See http://niap.bahialab.com/cc-scheme/in_evaluation.cfm It should complete before too long. Does that satisfy your requirement?
Emily --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-- _______________________________________________________________________ Mark Armstrong Email: msa@kaon.co.uk Chief Engineer Web: www.kaon.co.uk Office: +44 (0) 1483 885302 Fax: +44 (0) 1483 885301 Mobile: +44 (0) 7771 967588 Kaon Limited, 5 Wey Court, Mary Road, Guildford, Surrey, GU1 4QU, UK Disclaimer This communication is intended for the addressee(s) only, and is private and confidential. If you are not the intended recipient, any disclosure, copying, distribution or any other unauthorised dissemination is prohibited and unlawful. Please inform the sender immediately if you are not the intended addressee. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
To be considered certified, it would have to be in the certified configuration. Installing a new application with an open network port violates that certification. That is not really very useful. It is also not unique to SUSE, you have the same problem with all Common Criteria certified systems; they are only really certified in a specific configuration, which is probably not adequate to your needs. Which is why I am fairly cynical about the real security value of common criteria certification. Even among the set of people who are required to run certified systems, almost none of them actually run in the certified configuration. Crispin Mark Armstrong wrote:
That is very interesting to know, thank you.
I don't have to bring my system together until 1st quarter 2008 so SLES 10 is an option.
Would that mean that if I used SLES 10 SP1 on an appropriate hardware platform it would be considered to meet the common criteria (assuming it passes re-eval), or is it slightly more complicated than that?
Mark
Emily Ratliff wrote:
Mark Armstrong wrote:
All your points are very true, unfortunately I'm looking to put a server into an environment where risk assessment and use of certified products makes the bureaucracy happy.
SLES 10 (SP1) is under re-evaluation at CAPP/EAL4+. See http://niap.bahialab.com/cc-scheme/in_evaluation.cfm It should complete before too long. Does that satisfy your requirement?
Emily --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
-- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Crispin Cowan wrote:
To be considered certified, it would have to be in the certified configuration. Installing a new application with an open network port violates that certification.
This is only true if it opens a port < 1024 or runs as root. If it is started as a non-root user, then a port can be opened. That's why running a webserver on port 8080 does not violate the certified configuration. I'm not arguing against your main point, but it is not quite as bad as you state here. Emily --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
Emily Ratliff wrote:
Crispin Cowan wrote:
To be considered certified, it would have to be in the certified configuration. Installing a new application with an open network port violates that certification.
This is only true if it opens a port < 1024 or runs as root. If it is started as a non-root user, then a port can be opened. That's why running a webserver on port 8080 does not violate the certified configuration.
I'm not arguing against your main point, but it is not quite as bad as you state here. Thanks for clarifying. Its good to know that the certified configuration's restrictions make it less useless than I thought :-)
Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org
participants (5)
-
Crispin Cowan -
Emily Ratliff -
Mark Armstrong -
Philippe Vogel -
Roman Drahtmueller