| 1 |
Gavin wrote: |
| 2 |
----- |
| 3 |
Independent of whether or not multiple hardened versions/configurations |
| 4 |
will exist, won't we need dependency tracking between the key hardened |
| 5 |
components (kern, kern config, frameworks, policies, apps)? For |
| 6 |
example, a hardened app available through "emerge --patch |
| 7 |
security_risks" might require a hardened framework below it (e.g. rely |
| 8 |
on features of a hardened kern, or the application of rules in the |
| 9 |
firewall that potentially affect other hardened apps). Stop me if I'm |
| 10 |
getting lost in detail ;) |
| 11 |
----- |
| 12 |
|
| 13 |
This seems too complicated to me. I think that hardened packages should |
| 14 |
(as much as possible) be independent of other applications. Yes, I |
| 15 |
realise that all packages have dependencies, but they should, as much as |
| 16 |
possible be transparent to the user, as dependencies are currently in |
| 17 |
portage. If we look to get away from this, we runt he risk of ending up |
| 18 |
in 'portage hell', and users will not use the new system because it is |
| 19 |
too reminiscent of the problems people have with rpms. |
| 20 |
|
| 21 |
Gavin wrote: |
| 22 |
----- |
| 23 |
Use Scenario |
| 24 |
=========== |
| 25 |
1) Average user checks the Gentoo Risk Assessment Rating for app Foo and |
| 26 |
learns that Foo is rated "Very Unsafe" unless hardened. |
| 27 |
2) User reads about tradeoffs in using hardened Foo instead of soft Foo |
| 28 |
(unhardened and unhindered by security measures). |
| 29 |
3) Uses chooses hardened Foo. |
| 30 |
4) User knows little (nothing?) about hardened frameworks / kern layers. |
| 31 |
5) Before user can proceed, user needs to be informed about |
| 32 |
requirements/impact of upgrading/downgrading/changing to hardened Foo, |
| 33 |
including what changes are necessary in kern & framework (e.g. some base |
| 34 |
firewall package/policy). |
| 35 |
6) User upgrades kern [config], base framework(s) and policies, as |
| 36 |
needed. |
| 37 |
7) User emerges hardened Foo. |
| 38 |
----- |
| 39 |
|
| 40 |
Again, I think this has the potential to introduce confusion into the |
| 41 |
system. I agree that ratings are a great way to identify problem |
| 42 |
packages, but this is always going to be subjective to a point. |
| 43 |
|
| 44 |
What I would like to see is a (simplified) version of the |
| 45 |
package.mask/ACCEPT_KEYWORDS system which allows a user to define the |
| 46 |
safety level they want. This could be done by specifying a variable in |
| 47 |
make.conf (ex SECURITY_LEVEL) which defines at what level they want |
| 48 |
their system to work at. One level would need to be the default, and the |
| 49 |
current number of applications that are available to 'stable' users |
| 50 |
should be emerge-able under this level. Each level needs to have |
| 51 |
requirements that the packages must meet to be classified (e.g. |
| 52 |
chroot()ed, non-root exec etc). The user can then specify the level of |
| 53 |
security that they require, and the installation in the ebuild can be |
| 54 |
adjusted to provide this level of security. |
| 55 |
|
| 56 |
The problem with trying to classify the application by the number of |
| 57 |
bugs is not a guaranteed - by all means drop the rating of a package |
| 58 |
that has serious bugs which are not patched, but saying that package A |
| 59 |
is more secure because less bugs have been found in it than in package B |
| 60 |
is ridiculous. Yes, applications like Sendmail and BIND have a history |
| 61 |
of more bugs, than other products, but also, think about how mature the |
| 62 |
code is - it has been used by so many people for so long. And note how |
| 63 |
quickly the recent Sendmail bug had a patch released for the source. |
| 64 |
Yes, it had not been thoroughly tested, but it was out in a very short |
| 65 |
space of time. To me, this is a very comforting thought, as I have seen |
| 66 |
proof of the effectiveness of the patch system, whereas a newer |
| 67 |
application with less market penetration and no history (or a bad |
| 68 |
history) of response times to bugs, to me, has a bigger chance of |
| 69 |
causing problems, should a major bug be found. |
| 70 |
|
| 71 |
I know that people have different opinions of different software, but I |
| 72 |
believe that if a person knows what they are doing in the configuration |
| 73 |
of a certain piece of software, then they are probably going to end up |
| 74 |
with a more secure implementation than if they installed a (supposedly) |
| 75 |
more secure (i.e. less bugs known/history) application. As Aaron |
| 76 |
mentioned, Gentoo is about choice. The docs provide the options for they |
| 77 |
user, and then suggest a method for those who do not know which will |
| 78 |
suit them the best. This is where the subjectiveness of the bug history |
| 79 |
could best be put into practice, as the documentation author can clearly |
| 80 |
state their preference/recommendation and why they recommend that, |
| 81 |
without offending the more advanced users who want to do it 'their way'. |
| 82 |
|
| 83 |
|
| 84 |
Jerome Brown |
| 85 |
Systems Administrator |
| 86 |
Ashburton Trading Society |
| 87 |
97 Burnett Street |
| 88 |
PO Box 131 |
| 89 |
Ashburton |
| 90 |
Ph: +64 3 308-1306 |
| 91 |
Fax: +64 3 308-1308 |
| 92 |
Email: jerome@××××××.nz |
| 93 |
-------------------------------------------- |
| 94 |
"There is no 'patch' for stupidity" |
| 95 |
|
| 96 |
-- |
| 97 |
gentoo-hardened@g.o mailing list |
Archives