As most of you would have noticed, we have now had 3 CVE-nominated security issues for SWAT in the past couple of years. At the same time, while I know many of our users use SWAT, we just don't have anybody to maintain it inside the Samba Team. Kai has made a valiant effort to at least apply the XSS and CSRF guidelines when folks make security reports, but by his own admission he isn't a web developer - none of us are! There are many other parts of Samba that have not been substantially maintained in years, but few have the level of security exposure that SWAT does (most are bits of library and utility code that we apply elsewhere, but which just quietly does it's own job). The issue isn't that we can't write secure code, but that writing secure Web code where we can't trust the authenticated actions of our user's browser is a very different modal to writing secure system code. Frankly it just isn't our area. Therefore, it was suggested on a private list that we just drop SWAT. I want to start a public discussion on that point, prompted by http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700729 which reminds us why we didn't apply the specific CSRF hardening we applied in 4.0.2 to SWAT in the first place. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org
On Sun, Feb 17, 2013 at 7:02 PM, Andrew Bartlett <abartlet at samba.org> wrote:> As most of you would have noticed, we have now had 3 CVE-nominated > security issues for SWAT in the past couple of years.Has "webmin" kept up to date with the latest structural changes in smb.conf? I'll admit that I've long preferred the "webmin" module structure over the dedicated add-on structures of "swat".
I'm just a data point of one. My Samba history is as a user since before 2.0. Shortly into the 2.0.x series I was asked by locals (a point and click lot) to setup Swat so they could manage Samba. I did so and they still f'ed the configuration. That was and remains my only experience with Swat. I won't miss it. On 02/17/2013 04:02 PM, Andrew Bartlett wrote:> As most of you would have noticed, we have now had 3 CVE-nominated > security issues for SWAT in the past couple of years. > > At the same time, while I know many of our users use SWAT, we just don't > have anybody to maintain it inside the Samba Team. Kai has made a > valiant effort to at least apply the XSS and CSRF guidelines when folks > make security reports, but by his own admission he isn't a web developer > - none of us are! > > There are many other parts of Samba that have not been substantially > maintained in years, but few have the level of security exposure that > SWAT does (most are bits of library and utility code that we apply > elsewhere, but which just quietly does it's own job). > > The issue isn't that we can't write secure code, but that writing secure > Web code where we can't trust the authenticated actions of our user's > browser is a very different modal to writing secure system code. > Frankly it just isn't our area. > > Therefore, it was suggested on a private list that we just drop SWAT. I > want to start a public discussion on that point, prompted by > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700729 which reminds us > why we didn't apply the specific CSRF hardening we applied in 4.0.2 to > SWAT in the first place. > > Thanks, > > Andrew Bartlett >
On 02/17/2013 6:02 PM, Andrew Bartlett wrote:> As most of you would have noticed, we have now had 3 CVE-nominated > security issues for SWAT in the past couple of years. > > At the same time, while I know many of our users use SWAT, we just don't > have anybody to maintain it inside the Samba Team. Kai has made a > valiant effort to at least apply the XSS and CSRF guidelines when folks > make security reports, but by his own admission he isn't a web developer > - none of us are! > > There are many other parts of Samba that have not been substantially > maintained in years, but few have the level of security exposure that > SWAT does (most are bits of library and utility code that we apply > elsewhere, but which just quietly does it's own job). > > The issue isn't that we can't write secure code, but that writing secure > Web code where we can't trust the authenticated actions of our user's > browser is a very different modal to writing secure system code. > Frankly it just isn't our area. > > Therefore, it was suggested on a private list that we just drop SWAT. I > want to start a public discussion on that point, prompted by > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700729 which reminds us > why we didn't apply the specific CSRF hardening we applied in 4.0.2 to > SWAT in the first place. > > Thanks, > > Andrew BartlettI have yet to make the jump to Samba4, so I have not seen the version of SWAT designed for it. For me, the primary benefit of SWAT in Samba3 was the ability to use the help link for any parameter to see what that parameter did, what the default was, and what its proper syntax was. For reference, I ran "man smb.conf". Viewing full screen, I pressed the "Page Down" key 34 times and was still in the 1st third of the alphabetical listing of parameters. It's no small wonder that I never used "man smb.conf" to configure Samba. SWAT was my friend. So, if Samba4 has anywhere near the number of parameters as Samba3, I would be greatly disappointed to see SWAT go away entirely. An html version of the samba-doc package that contained all parameters with links to their definitions/descriptions would be a welcome and suitable replacement. Thanks, Dale
Am 18.02.2013 01:02, schrieb Andrew Bartlett:> As most of you would have noticed, we have now had 3 CVE-nominated > security issues for SWAT in the past couple of years. > > At the same time, while I know many of our users use SWAT, we just don't > have anybody to maintain it inside the Samba Team. Kai has made a > valiant effort to at least apply the XSS and CSRF guidelines when folks > make security reports, but by his own admission he isn't a web developer > - none of us are! > > There are many other parts of Samba that have not been substantially > maintained in years, but few have the level of security exposure that > SWAT does (most are bits of library and utility code that we apply > elsewhere, but which just quietly does it's own job). > > The issue isn't that we can't write secure code, but that writing secure > Web code where we can't trust the authenticated actions of our user's > browser is a very different modal to writing secure system code. > Frankly it just isn't our area. > > Therefore, it was suggested on a private list that we just drop SWAT. I > want to start a public discussion on that point, prompted by > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700729 which reminds us > why we didn't apply the specific CSRF hardening we applied in 4.0.2 to > SWAT in the first place. > > Thanks, > > Andrew Bartlett >Hi Andrew , i am not up2date with current samba module in webmin, but however, what about remove swat, and help webmin people for coding stuff there, so samba people dont need to care about the webmin framework security, only i.e helping at integrate new or changed parameters in the samba webmin module. Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstra?e 15, 81669 M?nchen Sitz der Gesellschaft: M?nchen, Amtsgericht M?nchen: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich