[vchkpw] Re: courier-imap / sql files
Hi Anders Anders Brander writes: > Extra security? I've always hated the vpopmail model, "all users are one > user" It has advantages and disavantages. It means that vpopmail runs under a dedicated user and group without (at the moment) any need for set-id. IMAP and POP servers do need setuid root if they are to work for system users and so I'd be more worried about them being compromised for root privilege than them being compromised so that somebody could turn himself into the vpopmail user and read other people's mail. I would go so far as to say that on a system where all users have vpopmail-owned mail and if the IMAP and POP3 servers were setuid vpopmail then you would have more security not less because only the mail system is exposed if somebody finds a hole (I'm not saying that somebody trashing mail is desirable but it's better than them trashing the whole system including mail).. > > Oh, unless you're using a PHP webmail > [snip] > > There could be many other reasons to give domainmail-admins > system-users. Admin'ing mailinglists for one. I've never played with it, but qmailadmin appears to support ezmlm mailing lists without needing system users. > Yep, or maybe the biggest feature. But hey, qmail is delivering to > systemusers isn't it? vdeliver doesn't even get run? As I understand things. But I have never looked too deeply into that. We don't have system users in the traditional sense. Clients have user accounts for FTP to their web sites but do not have shell access. Although we have a few admins as system users that's only so they can su root when necessary, their mail is handled through a virtual domain just like our customers. We don't have people who log into our servers to read mail in between playing nethack or whatever. > But theres much more to it than buffer overflows. How do we trust the > calling program, for one thing? You don't trust the calling program. You ensure that the directory these utilities are in is rx only to vpopmail:vchkpw. If somebody can su to those or insert a malicious program into ~vpopmail/bin and get it executed then you have more problems than a calling problem passing something weird. Those risks are present in the current model anyway, so adding these utilities does not make matters worse. If somebody can make a calling program maliciously call the database modify utility to wipe out arbitrary users they can do so under the current model too. The only thing these utilities would be doing in addition to what is currently done is providing a way of hiding the MySQL password. Essentially you would be extracting a few functions from libvpopmail, putting them into separate programs and adding the "get MySQL password" stuff to those additional programs. I don't see that this imposes an additional risk provided those additional programs are kept small and written well. Compared to having the password wired into libvpopmail.a, it is a significant improvement... I suppose we could always look how Courier does it to see if there's a better way, but that's cheating. -- Paul Allen Softflare Support
Re: [vchkpw] Re: courier-imap / sql files
Hi Paul and others, On Fri, 2003-09-12 at 14:32, Paul L. Allen wrote: > > IMHO it's the correct (tm) way to do things. It's not just a fiddle, > > it's the best solution. I would say that the setuid-thing is a fiddle. > I think which way you regard as a fiddle depends very much upon what you > do on your system. Yep indeed :) > > I think we confused eachother, we were talking about two different > > cases. > > I: When domain.tld is given a systemuser for their mail. > Ah, we don't do that. We probably could, since we have to give them > a system user to FTP their web site, but why bother when vpopmail lets > you get away with a single user? Extra security? I've always hated the vpopmail model, "all users are one user" > Oh, unless you're using a PHP webmail [snip] There could be many other reasons to give domainmail-admins system-users. Admin'ing mailinglists for one. > > You: When systemusers needed personal mail. > > - and now i can see the trouble ahead, but not that much trouble. > The trouble is that vpopmail can be used in so many different ways. Yep, or maybe the biggest feature. But hey, qmail is delivering to systemusers isn't it? vdeliver doesn't even get run? > > I was illustrating that it could quickly get hairy, when arguments have > > to be passing to/from these tools. > I think argument and value passing is reasonably well understood, > relatively easy to code and the methods of avoiding buffer overflows > known if not always widely applied. Provided the utilities are > restricted to reading and writing the database it should be easy to > ensure there are no known exploitable holes. But theres much more to it than buffer overflows. How do we trust the calling program, for one thing? > > Ohh boy i'm glad we are on a qmail-oriented list, elsewise we would have > > the great sendmail-flamefest now :) > Indeed. But it's a valid point. Given the number of systems running [snip] I didn't say that it wasn't a valid point! /Anders
[vchkpw] Re: courier-imap / sql files
Hi Anders Anders Brander writes: > IMHO it's the correct (tm) way to do things. It's not just a fiddle, > it's the best solution. I would say that the setuid-thing is a fiddle. I think which way you regard as a fiddle depends very much upon what you do on your system. > I think we confused eachother, we were talking about two different > cases. > I: When domain.tld is given a systemuser for their mail. Ah, we don't do that. We probably could, since we have to give them a system user to FTP their web site, but why bother when vpopmail lets you get away with a single user? Oh, unless you're using a PHP webmail interface, in which case you'd be forced into giving each domain a separate system user to prevent people reading mail for other domains. Hmmm, but unless you have an equivalent of suexec for PHP then you'd have to leave directories writeable by the httpd user so that people can delete mail, which means that a malicious user could delete mail for other domains (the malicious user would have to guess at filenames and it would take many guesses to stand a chance of hitting one, but it's your CPU cycles he's burning not his). I know you asked me to leave PHP insecurity out of this, but I'm guessing that the reason you have a system user for each domain is a fiddle to work around PHP insecurity in the first place. > You: When systemusers needed personal mail. > - and now i can see the trouble ahead, but not that much trouble. The trouble is that vpopmail can be used in so many different ways. > OT: We use the billing-model too :) But we also have skilled users, the > kind that just sends you the conf-file, the kind that writes their own > zone data. The kind that never calls, and when they do - you KNOW that > they have a very good reason to do so. Our users are almost all technically incompetent. We expect them to call and blame us for what turns out to be their own problem. We charge them for that. > I was illustrating that it could quickly get hairy, when arguments have > to be passing to/from these tools. I think argument and value passing is reasonably well understood, relatively easy to code and the methods of avoiding buffer overflows known if not always widely applied. Provided the utilities are restricted to reading and writing the database it should be easy to ensure there are no known exploitable holes. > Ohh boy i'm glad we are on a qmail-oriented list, elsewise we would have > the great sendmail-flamefest now :) Indeed. But it's a valid point. Given the number of systems running sendmail which has had many exploits, a few very small pieces of well-audited setgid code pose far less of a risk. Particularly when sendmail is setuid root and the code I'm proposing would be setgid to a group used for no other purpose. Sendmail has bullets in 5 of the chambers and people play Russian Roulette with it all the time yet surprisingly few are killed. -- Paul Allen Softflare Support
Re: [vchkpw] Re: courier-imap / sql files
Hi, Phew, this mail is getting longer and longer... On Fri, 2003-09-12 at 04:23, Paul L. Allen wrote: > > > It could get rather unwieldy if you use MySQL for other things. > > Why? > Just a gut feeling that if you have many MySQL users for one purpose > and many more MySQL users who are there purely as a fiddle to allow > vpopmail to work then it could make life difficult to distinguish the > two. But I am easily confused. :) IMHO it's the correct (tm) way to do things. It's not just a fiddle, it's the best solution. I would say that the setuid-thing is a fiddle. > > It could easily be done with vadddomain, the user must pre-exist as it > > is now, vopmail just have to create the .mysqlpass-file or whatever it > > is called. Or am i missing something here? > Yes, you're missing me having to do two things instead of one. There > are ways of setting up vpopmail so that if I add a system user then they > automatically get mail. Yes, those solutions are non-standard hacks > using custom scripts but they exist. My work is finished after I do > useradd. Every time I have to do two things to add a user it not only > increases my workload it increases the chance that I do one but not the > other. As I think I may have said, I am easily confused. :) I think we confused eachother, we were talking about two different cases. I: When domain.tld is given a systemuser for their mail. You: When systemusers needed personal mail. - and now i can see the trouble ahead, but not that much trouble. [snip, user types] > different usage patterns. For instance, the quota stuff is essential > for a company wanting to offer a hotmail/yahoo/whatever service. For > us it gets in the way of us billing people extra for going over their > allotted usage. OT: We use the billing-model too :) But we also have skilled users, the kind that just sends you the conf-file, the kind that writes their own zone data. The kind that never calls, and when they do - you KNOW that they have a very good reason to do so. > > They could make ther own internal php-tools for example, > You let your users play with PHP? I hope you have something that > emulates suexec so you have some rudimentary protection against them > using it to explore the filesystem. Then again, in your environment > it may not matter. In ours PHP without an suexec equivalent would > be a disaster. PHP, without modifications, is a security nightmare for > any user who wishes to have a web interface create or modify files. > When you have to make directories world-writeable or writeable by > the UID of the HTTP server then you have a security nightmare. Let's leave PHP-(in)security out of this. > > setuid programs can be a very nice solution to many problems, but i > > think that we should consider the possibility of just using standard > > filelevel security. That's something that has been audited and proven > > for years. > Ummm, I don't trust ANYTHING. I remember when the third edition of the > Camel book came out reading of many attacks that had not been mentioned > in the 2nd edition because they had not been known then but had always > been present. How about the race hazard when executing shell > or perl scripts (these days largely eliminated)? How about the many > race hazards suexec is vulnerable to (I know of no exploits and the > checks it does are better than no checks at all)? As we both know, the > only way to secure your computer is to ensure it has no connections to > the outside world and you are the only one who has physical access - as > soon as you relax those constraints you are taking risks. The question > is: is this particular solution playing Russian Roulette with 5 out of the > 6 chambers loaded or only 1 of the 6 chambers loaded... Very well said about the roulette thing. > > It's a great idea to have several small tools to do tasks, my point was > > just that it's not enough to return 0 or 1 (or 57). > Again, I was illustrating how the simple case of password authentication > (without APOP) would go. The idea was to establish the general model > for doing this sort of thing with setgid cleanly. I was illustrating that it could quickly get hairy, when arguments have to be passing to/from these tools. > > Mainly the passing of arguments to/from these tools. If it were just > > TRUE/FALSE-returns i would be all for it - well, almost ;-). > I always envisaged that these tools would be passed arguments - you [snip] I think we already adressed this - and agreed... > Set-id code is not without known hazards and there may be unknown > hazards. I was addressing the question of whether there was any > way of doing things relatively securely with set-id code. I don't > think the risks are significantly higher than with qmail set-id code > and I think they are vastly lower than with sendmail's monolithic, > gigantic block of set-id code which has been exploited many times. Ohh boy i'm glad we are on a qmail-oriented list, elsewise
[vchkpw] Re: courier-imap / sql files
Anders Brander writes: > > It could get rather unwieldy if you use MySQL for other things. > > Why? Just a gut feeling that if you have many MySQL users for one purpose and many more MySQL users who are there purely as a fiddle to allow vpopmail to work then it could make life difficult to distinguish the two. But I am easily confused. :) > It could easily be done with vadddomain, the user must pre-exist as it > is now, vopmail just have to create the .mysqlpass-file or whatever it > is called. Or am i missing something here? Yes, you're missing me having to do two things instead of one. There are ways of setting up vpopmail so that if I add a system user then they automatically get mail. Yes, those solutions are non-standard hacks using custom scripts but they exist. My work is finished after I do useradd. Every time I have to do two things to add a user it not only increases my workload it increases the chance that I do one but not the other. As I think I may have said, I am easily confused. :) > Another possibility it will open, is the users who administer their mail > with shell-access (mailinglists, other things) could have access to > their vpopmail-databases and do with them as they like. You may have users like that. We have one user like that (me) and one user who thinks he is like that (my boss, who gets more pointy-haired with each passing day). This is one of the reasons vpopmail goes in so many different directions - it has to attempt to cover so many different usage patterns. For instance, the quota stuff is essential for a company wanting to offer a hotmail/yahoo/whatever service. For us it gets in the way of us billing people extra for going over their allotted usage. > They could make ther own internal php-tools for example, You let your users play with PHP? I hope you have something that emulates suexec so you have some rudimentary protection against them using it to explore the filesystem. Then again, in your environment it may not matter. In ours PHP without an suexec equivalent would be a disaster. PHP, without modifications, is a security nightmare for any user who wishes to have a web interface create or modify files. When you have to make directories world-writeable or writeable by the UID of the HTTP server then you have a security nightmare. > setuid programs can be a very nice solution to many problems, but i > think that we should consider the possibility of just using standard > filelevel security. That's something that has been audited and proven > for years. Ummm, I don't trust ANYTHING. I remember when the third edition of the Camel book came out reading of many attacks that had not been mentioned in the 2nd edition because they had not been known then but had always been present. How about the race hazard when executing shell or perl scripts (these days largely eliminated)? How about the many race hazards suexec is vulnerable to (I know of no exploits and the checks it does are better than no checks at all)? As we both know, the only way to secure your computer is to ensure it has no connections to the outside world and you are the only one who has physical access - as soon as you relax those constraints you are taking risks. The question is: is this particular solution playing Russian Roulette with 5 out of the 6 chambers loaded or only 1 of the 6 chambers loaded... > It's a great idea to have several small tools to do tasks, my point was > just that it's not enough to return 0 or 1 (or 57). Again, I was illustrating how the simple case of password authentication (without APOP) would go. The idea was to establish the general model for doing this sort of thing with setgid cleanly. > It may turn out to be the best solution - but i see lots of problems > with this solution. > Mainly the passing of arguments to/from these tools. If it were just > TRUE/FALSE-returns i would be all for it - well, almost ;-). I always envisaged that these tools would be passed arguments - you can't do authentication without a username and password. :) And that they would return at least one value. Obviously, any tool which reads userinfo has to return several values. But although it is possible to program such things insecurely and vulnerable to buffer overflox exploits, it is also possible to program them securely (unless Ken Thompson has hacked your C compiler, in which case you're screwed whatever you do). Provided these tools are kept SMALL then a code audit will catch any currently-known vulnerabilities like people allocating a fixed amount of static memory to hold a string which the user determines. And provided they're small, the chance that the C compiler introduces an as-yet unknown vulnerability is also small. Set-id code is not without known hazards and there may be unknown hazards. I was addressing the question of whether there was any way of doing things relatively securely with set-id code. I don't think the risks are significantly high
Re: [vchkpw] Re: courier-imap / sql files
Hi, On Fri, 2003-09-12 at 03:16, Paul L. Allen wrote: > > If you add a special group to every user you are back where you started. > I didn't say it was a good solution. I said it was a solution. Compared > to that, a lot of the alternatives look good. Agree, alternatives are better. > > I can't see what's wrong with a mysql user per system user. That would > > be really clean and effective. > It could get rather unwieldy if you use MySQL for other things. Why? > > If the admistrative tools is integrated into vpopmail, i fail to > > see any troble ahead (user/admin-vice). > I can see one. I set up a system user. Who wants e-mail. So then > I have to use another tool to add that user to vpopmail. It could easily be done with vadddomain, the user must pre-exist as it is now, vopmail just have to create the .mysqlpass-file or whatever it is called. Or am i missing something here? Another possibility it will open, is the users who administer their mail with shell-access (mailinglists, other things) could have access to their vpopmail-databases and do with them as they like. They could make ther own internal php-tools for example, their own weird scripting. I think maybe this could be a big "selling point". > > It would completely remove any use for any setuid/setgid-hacks. > That is the one advantage I see to it. Whether or not one views that > advantage as compelling is another matter. setuid programs can be a very nice solution to many problems, but i think that we should consider the possibility of just using standard filelevel security. That's something that has been audited and proven for years. > > > 3) A very small utility that is setgid vpsql. It does the following > > > when passed a username and password to verify. > > You will also need small tools to do all other sorts of operations, > > quota, valias and so on. > I did mention those at the end. And even said that I preferred several > small tools to one large one that use switches to decide what it did > because that would mean more code and a harder time auditing it. It's a great idea to have several small tools to do tasks, my point was just that it's not enough to return 0 or 1 (or 57). > > It's not as simple as that, think about APOP authentication... > I don't have need of APOP so I didn't think about it. I was trying > to establish the general principle for doing it setgid with minimal > risks. I think something (well, several somethings) along those lines > would be feasible without opening up vulnerabilities. None of us like > set-id and try to avoid it, but there are times when it is better than > the alternatives (if sufficient care is taken). Compared to the major > hunk of setuid code that is sendmail and which a lot of systems run, > this ought to be far less likely to be exploited. It's not the only > solution and it may turn out not to be the best solution, but at least > it's there for consideration (and possible improvement). It may turn out to be the best solution - but i see lots of problems with this solution. Mainly the passing of arguments to/from these tools. If it were just TRUE/FALSE-returns i would be all for it - well, almost ;-). /Anders
[vchkpw] Re: courier-imap / sql files
Anders Brander writes: > If you add a special group to every user you are back where you started. I didn't say it was a good solution. I said it was a solution. Compared to that, a lot of the alternatives look good. > I can't see what's wrong with a mysql user per system user. That would > be really clean and effective. It could get rather unwieldy if you use MySQL for other things. > If the admistrative tools is integrated into vpopmail, i fail to > see any troble ahead (user/admin-vice). I can see one. I set up a system user. Who wants e-mail. So then I have to use another tool to add that user to vpopmail. > It would completely remove any use for any setuid/setgid-hacks. That is the one advantage I see to it. Whether or not one views that advantage as compelling is another matter. > > 3) A very small utility that is setgid vpsql. It does the following > > when passed a username and password to verify. > > You will also need small tools to do all other sorts of operations, > quota, valias and so on. I did mention those at the end. And even said that I preferred several small tools to one large one that use switches to decide what it did because that would mean more code and a harder time auditing it. > > c) Connects to MySQL. > > - and forgets username and password. OK, I take your point. It no longer needs them at that juncture and it's barely possible there's something exploitable later. > It's not as simple as that, think about APOP authentication... I don't have need of APOP so I didn't think about it. I was trying to establish the general principle for doing it setgid with minimal risks. I think something (well, several somethings) along those lines would be feasible without opening up vulnerabilities. None of us like set-id and try to avoid it, but there are times when it is better than the alternatives (if sufficient care is taken). Compared to the major hunk of setuid code that is sendmail and which a lot of systems run, this ought to be far less likely to be exploited. It's not the only solution and it may turn out not to be the best solution, but at least it's there for consideration (and possible improvement). -- Paul Allen Softflare Support
Re: [vchkpw] Re: courier-imap / sql files
Hi, On Fri, 2003-09-12 at 01:17, Paul L. Allen wrote: > > This is an interesting point and I'd love to find a clean solution to > > this issue. > I don't think you'll find a clean solution which doesn't involve set-id. > All the others are messy to administer, like a MySQL username per system > user or adding a special group to every user (do all *nixes handle that > well these days?) If you add a special group to every user you are back where you started. I can't see what's wrong with a mysql user per system user. That would be really clean and effective. If the admistrative tools is integrated into vpopmail, i fail to see any troble ahead (user/admin-vice). It would completely remove any use for any setuid/setgid-hacks. It will also remove the possibility of users injecting sql into any data not belonging to them. One problem would be the table-layout, the vpopmail-table would be useless for example. > How about this: > > 1) An additional user and group, vpsql, used for absolutely no other > purpose (except perhaps as owner of vpopmail database). > > 2) MySQL username and password in a file readable only by vpsql user > and group, and writeable only by vpsql user (if that - most people > will probably edit it as root). > > 3) A very small utility that is setgid vpsql. It does the following > when passed a username and password to verify. You will also need small tools to do all other sorts of operations, quota, valias and so on. > a) Reads the information in the password file. > > b) Drops setgid so it can do nothing further with the password file. > > c) Connects to MySQL. - and forgets username and password. > e) Verifies mail username and password against database. > > f) Returns go or no-go. It's not as simple as that, think about APOP authentication... [snip]
[vchkpw] Re: courier-imap / sql files
Tom Collins writes: > This is an interesting point and I'd love to find a clean solution to > this issue. I don't think you'll find a clean solution which doesn't involve set-id. All the others are messy to administer, like a MySQL username per system user or adding a special group to every user (do all *nixes handle that well these days?) How about this: 1) An additional user and group, vpsql, used for absolutely no other purpose (except perhaps as owner of vpopmail database). 2) MySQL username and password in a file readable only by vpsql user and group, and writeable only by vpsql user (if that - most people will probably edit it as root). 3) A very small utility that is setgid vpsql. It does the following when passed a username and password to verify. a) Reads the information in the password file. b) Drops setgid so it can do nothing further with the password file. c) Connects to MySQL. e) Verifies mail username and password against database. f) Returns go or no-go. I expect at least one person will poke holes in that somewhere, but I think the general principle is correct. Assuming you can drop setgid reliably (and not have it resurrected by an exploit later) then it ought to be safe. It would need a very close code audit but there's not going to be much code there to audit. The overhead of an extra process invocation per authentication is undesirable but, I think, unavoidable. You could just build it all into vchkpw but then a code audit would be a lot harder. Admittedly, if you read the password file as the very first thing you do and drop setgid as the very second thing you do then the rest ought not to matter, but with a separate vpsql user/group/program there is far less code containing possible exploits if somebody does know a way of regaining setgid after dropping it. Extending the idea to do allow qmailadmin and the like to modify user details is a SMOP. My preference would be for several utilies each restricted to one task like authentication, get user info, write user info rather than one big one that takes switches telling it what to do. -- Paul Allen Softflare Support
