On Mon, 5 May 2003, Jacques A. Vidrine wrote: > On Mon, May 05, 2003 at 02:02:41AM -0700, Doug Barton wrote: > > I have to object to this change of direction. Both on POLA grounds, and on > > the grounds that because most people don't use kerberos, it shouldn't be > > the default. I also think that given the historical propensity of kerberos > > to be vulnerable to attack, it definitely shouldn't be included by > > default. > > Actually, I think we've now fixed POLA issues ... previously we > installed the Kerberos bits by default, but did not rebuild them when > the rest of the system was updated. I've always thought that the mistake here is supplying the kerberos bits by default in the install. > Other OSes that supply Kerberos directly come with those bits by > default. I'm completely uninterested in what other OSes do in this regard. We've been doing a fairly good job in -current of tightening up the default install. I see this as a big step in the wrong direction. > I do not think that whether or not `most people' use a part of the > system is the only (or most important) criteria in determining whether > or not to build or not build that part of the system by default. I disagree with you here on two counts. First, I've personally put a non-zero amount of work into removing, or providing options to remove parts of the base that are little used. I've focused what little time and attention I have for this on things like uucp that had lots of s[ug]id binaries, or otherwise provided a potential security hole. We've recently seen the removal of other little-used items like xten. So, I think my concern is very valid here. Doubly so when you consider the extremely dodgy security history of kerberos. > To what `historical propensity' are you referring? I intend this as > an honest question. I'm going to assume that as security officer you're aware of the extremely colorful history of kerberos's many vulnerabilities. :) > We include software in the base system that most definitely has a poor > security track record, but I don't think that Kerberos 5 gets any > distinction in this regard. I disagree that kerberos hasn't distinguished itself, but I don't think the fact that we ship other vulnerable things means that we should add one more, especially when doing so A) Does not add functionality for the majority of our users, and B) Increases the security exposure for the majority of our users. Also, I'm not impressed with the, "But this is kerb 5, not kerb 4" argument, since up till recently the limited deployed base of kerb 5 has not made it a very attractive target for hackers. I've stated my position pretty clearly now, so I'll let others take a turn. Doug -- This .signature sanitized for your protectionReceived on Mon May 05 2003 - 03:37:40 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:06 UTC