Re: To be a new DFly commiter
Justin C. Sherrill wrote: In fact, I propose a new rule of thumb: For any proposed feature where: 1: Matt doesn't object, and 2: No existing functionality is lost it should go in. I don't agree. Matt of course has a veto, but the community itself should also agree that this is a feature we want. I guess Matt even doesn't want to permanently watch what other people are doing to object stupid ideas. Looking at the LICENSE file, it is indeedy under a BSD license. Grzegorz, can you submit a unified diff? I guess we need some clever idea to get it working with bare libc as well, etc. Something like this is definitely *not* a work of a saturday afternoon. This is critical infrastructure and needs to be reviewed thoroughly. cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ signature.asc Description: OpenPGP digital signature
Re: To be a new DFly commiter
Dnia 17-03-2007, So o godzinie 00:05 +0100, Simon 'corecode' Schubert napisał(a): [EMAIL PROTECTED] wrote: c) add support for openwall tcb - the alternative to shadow (with pam module) which is more secure than pam_unix and pam_pwdb, because tools like 'passwd' or 'chage' don't neet SUID, instead it use SGID 'shadow'. Group 'auth' may be used to read-only access to all password hashes. I am not convinced that this improves security. Could you please detail your security considerations? My point is: current tools have been exposed to security audit for over 20 years now, so unless something else is conceptually more secure, chances are high that we should stick with the original system. I made a mistake in this point, SGID shadow can only read users list (can not read/write passwords). SGID auth can read passwords, but can not write it. Every user have its own shadow file whitch is owned by this user. Write to user's shadow file can only this user or root. There is not required SUID root for passwd and related tools. For more you can read on http://openwall.com/tcb/. Yes, I read the docs and I think this is a quite nice and simple scheme to restrict access and to get rid of a couple of setuid root binaries. We definitely should discuss this. I'm not talking about integrating the sources because I suspect they are GPL, but about the principle itself. Tcb is licensed under terms of BSDL. Short for everybody too lazy to read: master.passwd is being split into single per-user files. these are located in per-user dirs with mode $user:auth 710 and the files $user:auth 640. this way only root+user can change the files and therefore the password. only root+user+group auth can read/check the password. don't know about chsh(1) etc. cheers simon Czas wybrac dobra nazwe! www.nazwa.pl
Re: To be a new DFly commiter
Dnia 16-03-2007, Pt o godzinie 18:58 -0700, Matthew Dillon napisał(a): Well, hmm. Kinda out of the blue, and I don't want to discourage anyone who is this enthusiastic, but I have a few buts of my own. 1. a) chg default password_format do blowfish since there are known algoritm of collision for md5. I don't think this is a big issue. When I was doing BEST Internet we had a number of incidents where the master.passwd file on a user machine would get stolen. Even though only root can read it there were numerous holes in programs that at least allowed unauthorized read access to root-only files. This occured several times throughout BEST's history and we had to ask people to change their passwords on the effected machines. The person would then run a cracker on the file off-line. Crackers tended to simply guess passwords, though, not actually try to decrypt or fake them. I do not think the MD5 collision issue is really pertainant to the main problem. Also, who actually uses passwords in the password file any more these days? I don't know about all of you, but I do not run any services where REMOTE access to the machine is granted via a standard password. It is ssh or nothing. Brute-force algoritm with collision can take password 100 time faster than brute-force without brute-force. Atacker not must stole password file, attack can be made from local network too. We can don't change password_format and still use md5, but we can change it to blowfish, maybe this is not a big issue, but for fix it, we must change only one record in /etc/login.conf. This is very trivial. b) add support for openwall passwdqc (password checker) pam module (this was added to FreeBSD 5.0) c) add support for openwall tcb - the alternative to shadow (with pam module) which is more secure than pam_unix and pam_pwdb, because tools like 'passwd' or 'chage' don't neet SUID, instead it use SGID 'shadow'. Group 'auth' may be used to read-only access to all password hashes. I don't like the idea of changing the password file mechanics, and especially do not like the idea of storing anything in the user's home directory. In my considered opinion, not even the user should have any access to the encrypted form of his password (and I think this is one of the deficiencies of the .ssh/authorized_keys file mechanism that SSH uses). 2. a) Replace sendmail with postfix (with cyrus-sasl). It is faster and use cleaner config file. I personally believe that postfix is superior. I personally do not mind running GPL'd code. But I also would prefer to have as little GPL'd code in our managed code base as possible. What does this mean? I would dearly like to integrate portions of pkgsrc managed packages into our buildworld and installworld system, that is have the buildworld create a little package building jail and build and install selected packages, with appropriate defaults, as part of the base system build. Then we would not have to import or maintain the sources for at least the larger integrated pieces (such as sendmail/postfix, bind, etc). b) Add imap-uw as simple pop3 and imap4 daemon. I'd prefer this be maintained via pkgsrc. c) Add stunnel for SSL/TLS access to mail-related daemon. I don't have much background knowledge on stunnel. It sounds like another thing that should be maintained via pkgsrc. 3. Build alternative to pkgsrc packages system, which will be build on pacman from archlinux.org, and use tweaked PKGBUILD scripts. This packages system should be easier to maintain, and we will keep track on all our packages. For faster port packages to DFly, we can use makepkg with PKGBUILD (which is a shell script) or we can rewrite this scripts to Makefiles which will stop building package on error. I will rewrite pacman tool which will be use this same archive format, but for library to reading archives I'll use libarchive, and for fetching packages from net I'll use libfetch. I need name for this tool, because this should be different than pacman. I don't think a single person would be able to maintain an alternative. Simply keeping up to date with all the new versions of various things that occur every day would be difficult. -Matt Domena za 90 groszy! www.nazwa.pl Serwery za 1 zł! www.nazwa.pl
Re: To be a new DFly commiter
Grzegorz Błach wrote: Brute-force algoritm with collision can take password 100 time faster than brute-force without brute-force. How do you prove this claim? AFAIK collision attacks need to know the plain text. Trying to brute-force a password means not having it in plain text. Hence collisions do not play any role. Atacker not must stole password file, attack can be made from local network too. We can don't change password_format and still use md5, but we can change it to blowfish, maybe this is not a big issue, but for fix it, we must change only one record in /etc/login.conf. This is very trivial. Yes, I also don't see any reason why we *have* to stick to md5. However, I also don't see any reason why we should switch to blowfish. cheers simon PS: could you please trim excessive quotes when replying? thanks. -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ signature.asc Description: OpenPGP digital signature
Re: To be a new DFly commiter
Matthew Dillon wrote: I personally believe that postfix is superior. I personally do not mind running GPL'd code. But I also would prefer to have as little GPL'd code in our managed code base as possible. What does this mean? I would dearly like to integrate portions of pkgsrc managed packages into our buildworld and installworld system, that is have the buildworld create a little package building jail and build and install selected packages, with appropriate defaults, as part of the base system build. Then we would not have to import or maintain the sources for at least the larger integrated pieces (such as sendmail/postfix, bind, etc). If i can allow myself to comment Matt's opinion, i think that the two statements above are true and excellent. More generally, there are pieces of traditional BSD installations, such as sendmail, etc. which have better non BSD variants, so that an integrated mechanism to get rid of such base system tools ( i mean only selected few ones ) and import external packages. b) Add imap-uw as simple pop3 and imap4 daemon. I'd prefer this be maintained via pkgsrc. Yes, in particular when imap-uw is a notorious buggy, insecure and bad performing application. I don't think a single person would be able to maintain an alternative. Simply keeping up to date with all the new versions of various things that occur every day would be difficult. Another excellent statement! Maintaining a decent ports system is a task for hundred people. FreeBSD has aroud 200 people doing that, Debian, around 1000. One has to be totally unaware of realities to suggest tools from obscure Linux distributions, wether they are good or bad, when such distribution may collapse at any moment. Already the move to NetBSD pkgsrc has cost DFLY division by 3 of the number of available ports with respect to FreeBSD for an advantage that i have hard time to even discern. The NetBSD people have replaced the horrible mess which is the 4000 lines bsd.port.mk by a similar horrible mess except it is scattered over many 5 lines files. Like in many cases it is OpenBSD which is doing the good work, and in particular they have understood the obvious, that is a ports system must be centered about binary packages, not recompiling source. This is true for at least two reasons: - first, today users don't want to lose time compiling - second, it is *impossible* to guarantee reliability of a system based on source code, because two people may compile the same software on different background, and obtain different result. This is a fundamental issue that nobody will be able to solve.
Re: To be a new DFly commiter
On Sat, Mar 17, 2007 at 01:26:21PM +0100, Grzegorz B?ach wrote: Brute-force algoritm with collision can take password 100 time faster than brute-force without brute-force. Again, password hashes are *not* simple MD5 hashes. They are not even simple salted MD5 hashes. That doesn't mean that a collision is not possible against them, but at least not the stnadard versions everyone is talking about. Joerg
Re: To be a new DFly commiter
On Sat, 17 Mar 2007 15:30:11 +0100 Michel Talon [EMAIL PROTECTED] wrote: Already the move to NetBSD pkgsrc has cost DFLY division by 3 of the number of available ports with respect to FreeBSD for an advantage that i have hard time to even discern. The advantage is simple to see, as DragonFly and FreeBSD diverged more and more of the FreeBSD ports were failing to build, by now with the termination of FreeBSD-4.x support in the ports tree I suspect there would be a large number of ports failing. The dfports override mechanism was a pure hack that would not have been maintainable for long without effectively forking the FreeBSD ports. As you observed in the bit I snipped maintaining a ports system is no job for a small team so avoiding doing that by joining in with a cross platform system was definitely a good move IMHO. Like in many cases it is OpenBSD which is doing the good work, and in particular they have understood the obvious, that is a ports system must be centered about binary packages, not recompiling source. This is true for at least two reasons: - first, today users don't want to lose time compiling Even if 99.% of all users were to use only binary packages *someone* would have to compile sources and maintain patches. For this purpose pkgsrc seems to be well suited. Binary packages from pkgsrc are readily available for most if not all platforms supported by pkgsrc, and yet many pkgsrc users recompile from source, which seems to contradict your contention. To my mind a system that provides binary packages for those that want them and allows source building for those that want to is ideal, certainly a system that provided only binary packages would not please me. When we factor in the little detail that many packages have build options and if you don't like the ones chosen for the bulk builds (for example I use sane but I don't want the gimp around) you have to compile your own it becomes clear that there is at least one good reason for doing your own compiles. -- C:WIN | Directable Mirror Arrays The computer obeys and wins.| A better way to focus the sun You lose and Bill collects. |licences available see |http://www.sohara.org/
Re: To be a new DFly commiter
On Sat, Mar 17, 2007 at 03:30:11PM +0100, Michel Talon wrote: Another excellent statement! Maintaining a decent ports system is a task for hundred people. FreeBSD has aroud 200 people doing that, Debian, around 1000. To be fair, Debian *needs* the thousand people because the approach to packagement they use doesn't scale. One has to be totally unaware of realities to suggest tools from obscure Linux distributions, wether they are good or bad, when such distribution may collapse at any moment. Already the move to NetBSD pkgsrc has cost DFLY division by 3 of the number of available ports with respect to FreeBSD for an advantage that i have hard time to even discern. Package counting like comparing penis length. There are more important parameters... I've spoken with at least one member of FreeBSD's portmgr who cursed the current size of the tree, making it very hard to maintain or move forward. A friend also just reminded me that ports has over 8700 (!) Perl modules in the list, factoring that out reducing the divisor a lot. You don't know the advance? Check out a pkgsrc tree and try building random stuff on DragonFly and do the same with ports. Any other question needed? As the person responsible for 2/3 of that I decided to use the way of least resistence and the way more appealing for technical reasons. The NetBSD people have replaced the horrible mess which is the 4000 lines bsd.port.mk by a similar horrible mess except it is scattered over many 5 lines files. You have to start somewhere. Moving logic out of the make scripts is an on-going task, which is work if you don't want to break something. Or want to keep the breakage down to strange packages doing bad things. Like in many cases it is OpenBSD which is doing the good work, and in particular they have understood the obvious, that is a ports system must be centered about binary packages, not recompiling source. I simply refuse to comment that, but it is somewhat ironic... Joerg
Re: To be a new DFly commiter
On Fri, Mar 16, 2007 at 06:58:58PM -0700, Matthew Dillon wrote: What does this mean? I would dearly like to integrate portions of pkgsrc managed packages into our buildworld and installworld system, that is have the buildworld create a little package building jail and build and install selected packages, with appropriate defaults, as part of the base system build. Then we would not have to import or maintain the sources for at least the larger integrated pieces (such as sendmail/postfix, bind, etc). I have some not-yet-commited patches to make unprivileged building a lot more useful. I also plan to work on cross-compilation support for parts of the pkgsrc tree. Both will help a lot for tighter integration of binary packages into distributions. Joerg
Re: To be a new DFly commiter
Joerg Sonnenberger wrote: One has to be totally unaware of realities to suggest tools from obscure Linux distributions, wether they are good or bad, when such distribution may collapse at any moment. Already the move to NetBSD pkgsrc has cost DFLY division by 3 of the number of available ports with respect to FreeBSD for an advantage that i have hard time to even discern. Package counting like comparing penis length. There are more important parameters... I've spoken with at least one member of FreeBSD's portmgr who cursed the current size of the tree, making it very hard to maintain or move forward. A friend also just reminded me that ports has over 8700 (!) Perl modules in the list, factoring that out reducing the divisor a lot. rose% uname -a FreeBSD rose 6.2-RELEASE FreeBSD 6.2-RELEASE #1: Sat Feb 3 12:51:15 UTC 2007 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ROSE i386 rose% find . -depth 2 -maxdepth 2|grep p5|wc -l 2684 and this picks php5 stuff and perhaps other. The reality is that on FreeBSD i find everything i want in the ports, even more easily that in Ubuntu, while on several other BSD and Linux systems i don't, by a very large margin. This is not pissing contest, for me the wide abundance of ports in FreeBSD is by far the most important reason why i am using it. It is certainly not because the kernel is more stable or more performing that on a Linux system, which would not be true, it is because each time i want to use some software i find it. OpenBSD has an excellent packaging system recently revamped by Marc Espie, but it is severely lacking ports coverage. What FreeBSD and NetBSD lack is a good system for management of binary packages. Marc has very well understood that, and has made every effort so that updates work smoothly. To my knowledge OpenBSD is the only BSD which has a working update mechanism, fully integrated. I have written something experimental for FreeBSD: http://www.lpthe.jussieu.fr/~talon/pkgupgrade because i think there is no future for an OS without a binary packages management system,for the reasons that i have mentioned. Sorry, i don't buy Steve's arguments. It is not because One person wants to build sane without gimp support that All users have to endure the pain of building all their ports. The solution is simply that Steve uses an alternative mechanism, involving compilation, when he wants to install sane. If moreover the reason for such desire is to avoid bloat on the hard disk, then i call that an exercise in futility.
Re: To be a new DFly commiter
What FreeBSD and NetBSD lack is a good system for management of binary packages. Marc has very well understood that, and has made every effort so that updates work smoothly. To my knowledge OpenBSD is the only BSD which has a working update mechanism, fully integrated. I completely agree with you - I prefer binary packages. If nothing else, pkgmanager is getting close to taking away much of the pain of manual compilation and upgrading: http://www.scode.org/pkgmanager/ . And pkg_select has been updated to work with binary packages using the pkg_summary database. And I heard that pkg_chk can use the pkg_summary(5) database for binary updates also. By the way, OpenBSD's solution uses perl. Pkgsrc doesn't depend on perl as perl is not installed on some pkgsrc developers/users systems. Jeremy C. Reed
Re: To be a new DFly commiter
*My* *sole* opinion follows: * pkgsrc is here to stay, it works fine, you'd better contribute to (even smoother) pkgsrc integration * postfix license is too restrictive (IBM), same for stunnel (GPL), developers of *BSD systems would like to avoid licenses that are more restrictive than BSDL. -- Gergo Szakal [EMAIL PROTECTED] University Of Szeged, HU Faculty Of General Medicine /* Please do not CC me with replies, thank you. */
Re: To be a new DFly commiter
Dnia 16-03-2007, Pt o godzinie 17:45 +0100, Joerg Sonnenberger napisał(a): c) add support for openwall tcb - the alternative to shadow (with pam module) which is more secure than pam_unix and pam_pwdb, because tools like 'passwd' or 'chage' don't neet SUID, instead it use SGID 'shadow'. Group 'auth' may be used to read-only access to all password hashes. HAHA. This is a good one. It is more secure to not run tools which manipulate the password db as root? If I can control any of this tools to execute code with sgid shadow, I can just manipulate the root record anyway. Sorry to be harsh. Joerg When you do buffer-overflow in passwd you can exec any code with root priviledges, but with tcb you must change root password to run code with root priviledges, and administrator will see this faster. Serwery za 1 zł! www.nazwa.pl
Re: To be a new DFly commiter
Dnia 16-03-2007, Pt o godzinie 17:57 +0100, Gergo Szakal napisał(a): *My* *sole* opinion follows: * pkgsrc is here to stay, it works fine, you'd better contribute to (even smoother) pkgsrc integration * postfix license is too restrictive (IBM), same for stunnel (GPL), developers of *BSD systems would like to avoid licenses that are more restrictive than BSDL. I use DFly because it is better than linux for me (not because it has less restrictive license), and IMO postfix is better than sendmail, thus postfix should be used. Currently nobody should use mail server without sasl authentication. Postfix can be authenticated also with dovecot which is mainly pop3/imap4 server and is released partialy under MIT and LGPLv2.1 licenses. .com = 9,90, .pl = 29,90 www.nazwa.pl
Re: To be a new DFly commiter
On Fri, Mar 16, 2007 at 05:45:58PM +0100, Joerg Sonnenberger wrote: On Fri, Mar 16, 2007 at 05:17:43PM +0100, Grzegorz B?ach wrote: a) chg default password_format do blowfish since there are known algoritm of collision for md5. IMO the MD5 collision attacks for overrated and might not even apply in this area as this is multi-round procesising. c) add support for openwall tcb - the alternative to shadow (with pam module) which is more secure than pam_unix and pam_pwdb, because tools like 'passwd' or 'chage' don't neet SUID, instead it use SGID 'shadow'. Group 'auth' may be used to read-only access to all password hashes. HAHA. This is a good one. It is more secure to not run tools which manipulate the password db as root? If I can control any of this tools to execute code with sgid shadow, I can just manipulate the root record anyway. Sorry to be harsh. 2. a) Replace sendmail with postfix (with cyrus-sasl). It is faster and use cleaner config file. ...and cyrs-sasl is a complete mess. Please read the archive on this. b) Add imap-uw as simple pop3 and imap4 daemon.A c) Add stunnel for SSL/TLS access to mail-related daemon. Objected. Not essential, you can easily install them from pkgsrc or other means. Christ, man. I thought you guys wanted to encourage participation. Brett Joerg
Re: To be a new DFly commiter
Hey Grzegorz, first of all, welcome to DragonFly! Grzegorz Błach wrote: I use DragonFly about 2 year, currently I am ready to submit my tweaks and extensions to DFly system. Now for this list. We always should consider the positive and negative effects of change. I don't want to sound negative, so take everything with a grain of salt. 1. a) chg default password_format do blowfish since there are known algoritm of collision for md5. I guess that's not much of a problem and possibly also does no harm. However, I doubt that the collisions can be exploited. b) add support for openwall passwdqc (password checker) pam module (this was added to FreeBSD 5.0) is that some kind of cracklib? unrelated to this, i've always wanted some sort of generic password generator in base... c) add support for openwall tcb - the alternative to shadow (with pam module) which is more secure than pam_unix and pam_pwdb, because tools like 'passwd' or 'chage' don't neet SUID, instead it use SGID 'shadow'. Group 'auth' may be used to read-only access to all password hashes. I am not convinced that this improves security. Could you please detail your security considerations? My point is: current tools have been exposed to security audit for over 20 years now, so unless something else is conceptually more secure, chances are high that we should stick with the original system. 2. a) Replace sendmail with postfix (with cyrus-sasl). It is faster and use cleaner config file. We have support by Greg Shaprio, a sendmail developer. Unless postfix is equally well supported, I object replacing it. I am using postfix on all my systems myself, however. Pkgsrc can do an equally good job in fixing bugs etc. However, I would like to see a simple mail transport as complete replacement for sendmail. I have a concept in mind, but I didn't have enough time and muse to do it. Please refer to the archives for multiple sendmail vs postfix bikesheds. b) Add imap-uw as simple pop3 and imap4 daemon. I don't think this should be part of a BSD base distribution. Packages like these are easily installed by pkgsrc and on top of that are for sure subject of holy flamewars. c) Add stunnel for SSL/TLS access to mail-related daemon. In principle I would love to have some tool where I can spy into SSL/TLS connections (when they are being established). Not sure why you'd want to use stunnel, though. 3. Build alternative to pkgsrc packages system, which will be build on pacman from archlinux.org, and use tweaked PKGBUILD scripts. This packages system should be easier to maintain, and we will keep track on all our packages. For faster port packages to DFly, we can use makepkg with PKGBUILD (which is a shell script) or we can rewrite this scripts to Makefiles which will stop building package on error. I will rewrite pacman tool which will be use this same archive format, but for library to reading archives I'll use libarchive, and for fetching packages from net I'll use libfetch. I need name for this tool, because this should be different than pacman. This is a very ambitious effort and I hope that somebody will join you. Yet you have to be aware of the fact that DragonFly is supported very well through pkgsrc, and this kind of coverage needs to be reached. You will have to get used to the thought that for quite some time you will have to maintain your system in parallel to convince people that it is possible and better than pkgsrc. I hope I'll got write access to CVS for complete this steps. I think most of the changes are either simple enough to be submitted via mail first and the other ideas should be discussed thoroughly first. As soon as the flood of (good) patches from you becomes a pain for the committers, you will get the opportunity to directly commit. In the meantime, you might want to consider setting up and serving an alternative git or hg repository (better development model in my opinion anyways). Contact me for details on hg and git feeds. cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ signature.asc Description: OpenPGP digital signature
Re: Re: To be a new DFly commiter
On Fri, 16 Mar 2007 19:53:35 +0100, [EMAIL PROTECTED] / mail wrote: Grzegorz Błach napisał(a): Hi everyone, hi I use DragonFly about 2 year, currently I am ready to submit my tweaks and extensions to DFly system. There're: 1. a) chg default password_format do blowfish since there are known algoritm of collision for md5. i think it would be a good idea b) add support for openwall passwdqc (password checker) pam module (this was added to FreeBSD 5.0) c) add support for openwall tcb - the alternative to shadow (with pam module) which is more secure than pam_unix and pam_pwdb, because tools like 'passwd' or 'chage' don't neet SUID, instead it use SGID 'shadow'. Group 'auth' may be used to read-only access to all password hashes. 2. a) Replace sendmail with postfix (with cyrus-sasl). It is faster and use cleaner config file. yes it is, i hate sendmail ... b) Add imap-uw as simple pop3 and imap4 daemon. i prefer dovecot imap-uw is a simple daemon and IMO this should be in base system. If you need more advanced tool you can install dovecot from packages. c) Add stunnel for SSL/TLS access to mail-related daemon. i don't think it's necessary 3. Build alternative to pkgsrc packages system, which will be build on pacman from archlinux.org, and use tweaked PKGBUILD scripts. This packages system should be easier to maintain, and we will keep track on all our packages. For faster port packages to DFly, we can use makepkg with PKGBUILD (which is a shell script) or we can rewrite this scripts to Makefiles which will stop building package on error. I will rewrite pacman tool which will be use this same archive format, but for library to reading archives I'll use libarchive, and for fetching packages from net I'll use libfetch. I need name for this tool, because this should be different than pacman. pacman would be great choice for old machines to have updated packages when we don't have master machine I hope I'll got write access to CVS for complete this steps. WHO I AM? I am a 21 old student from Krakow in Poland. 3 year's ago I worked on my own Linux distribution, but I halt this project, because I had romance with FreeBSD, and this system IMHO is more self-integrated than Slackware Linux, which I used earlier. And I played with him. For my distribution I ported crypt-blowfish from openwall. And when i halted work on my distripution i put patch for Slackware 10 on http://www.openwall.com/crypt/. For FreeBSD i write coda (CD Digital-Audio Player), which is hosted on https://gna.org/projects/coda. And I ported fdisk from utils-linux package as lfdisk which is hosted on https://gna.org/projects/lfdisk. Czas wybrac dobra nazwe! www.nazwa.pl .com = 9,90, .pl = 29,90 www.nazwa.pl
Re: Re: To be a new DFly commiter
On Fri, 16 Mar 2007 19:43:27 +0100, Simon 'corecode' Schubert wrote: Hey Grzegorz, first of all, welcome to DragonFly! Grzegorz Błach wrote: I use DragonFly about 2 year, currently I am ready to submit my tweaks and extensions to DFly system. Now for this list. We always should consider the positive and negative effects of change. I don't want to sound negative, so take everything with a grain of salt. 1. a) chg default password_format do blowfish since there are known algoritm of collision for md5. I guess that's not much of a problem and possibly also does no harm. However, I doubt that the collisions can be exploited. b) add support for openwall passwdqc (password checker) pam module (this was added to FreeBSD 5.0) is that some kind of cracklib? unrelated to this, i've always wanted some sort of generic password generator in base... I never use cracklib. Passwdqc is a password generator and checker (even root must use secure password instead this is in many linux distros), and is a part of security enhanced systems like openbsd, openwall, alt linux, and additionaly is in debian, SUSE, and very recent version of redhat. c) add support for openwall tcb - the alternative to shadow (with pam module) which is more secure than pam_unix and pam_pwdb, because tools like 'passwd' or 'chage' don't neet SUID, instead it use SGID 'shadow'. Group 'auth' may be used to read-only access to all password hashes. I am not convinced that this improves security. Could you please detail your security considerations? My point is: current tools have been exposed to security audit for over 20 years now, so unless something else is conceptually more secure, chances are high that we should stick with the original system. I made a mistake in this point, SGID shadow can only read users list (can not read/write passwords). SGID auth can read passwords, but can not write it. Every user have its own shadow file whitch is owned by this user. Write to user's shadow file can only this user or root. There is not required SUID root for passwd and related tools. For more you can read on http://openwall.com/tcb/. 2. a) Replace sendmail with postfix (with cyrus-sasl). It is faster and use cleaner config file. We have support by Greg Shaprio, a sendmail developer. Unless postfix is equally well supported, I object replacing it. I am using postfix on all my systems myself, however. Pkgsrc can do an equally good job in fixing bugs etc. However, I would like to see a simple mail transport as complete replacement for sendmail. I have a concept in mind, but I didn't have enough time and muse to do it. Please refer to the archives for multiple sendmail vs postfix bikesheds. b) Add imap-uw as simple pop3 and imap4 daemon. I don't think this should be part of a BSD base distribution. Packages like these are easily installed by pkgsrc and on top of that are for sure subject of holy flamewars. c) Add stunnel for SSL/TLS access to mail-related daemon. In principle I would love to have some tool where I can spy into SSL/TLS connections (when they are being established). Not sure why you'd want to use stunnel, though. Ok stunnel is not necessary, I forgot that imap-uw support SSL/TLS natively. 3. Build alternative to pkgsrc packages system, which will be build on pacman from archlinux.org, and use tweaked PKGBUILD scripts. This packages system should be easier to maintain, and we will keep track on all our packages. For faster port packages to DFly, we can use makepkg with PKGBUILD (which is a shell script) or we can rewrite this scripts to Makefiles which will stop building package on error. I will rewrite pacman tool which will be use this same archive format, but for library to reading archives I'll use libarchive, and for fetching packages from net I'll use libfetch. I need name for this tool, because this should be different than pacman. This is a very ambitious effort and I hope that somebody will join you. Yet you have to be aware of the fact that DragonFly is supported very well through pkgsrc, and this kind of coverage needs to be reached. You will have to get used to the thought that for quite some time you will have to maintain your system in parallel to convince people that it is possible and better than pkgsrc. I don't like pkgsrc because this limitations: 1. Many packages in pkgsrc are obsolete, and there are no development version of almost all packages (i wan't to see new version of dbmail, xorg and enlightenment 0.17 in packages system). 2. Many packages in pkgsrc are configured with '--without-threading' option, because not all systems which pkgsrc work on support threading. I want omit this limitation. 3. Binary upgrade packages with pkg_add -u is difficult. Eg. it is possible to upgrade only selected packages. Pacman can upgrade selected packages and also whole installed
Re: To be a new DFly commiter
On Fri, Mar 16, 2007 at 06:07:07PM +0100, Grzegorz B?ach wrote: When you do buffer-overflow in passwd you can exec any code with root priviledges, but with tcb you must change root password to run code with root priviledges, and administrator will see this faster. Who said that I want to change the root password? I can easily just create a new user with uid 0, login remotely as that and change the entry back. Very little log pollution and that can be easily taken care of. Joerg
Re: To be a new DFly commiter
On Fri, 16 Mar 2007 18:31:20 +0100 Grzegorz Błach [EMAIL PROTECTED] wrote: I use DFly because it is better than linux for me (not because it has less restrictive license), Same here, I just dared to spoke for *BSD developers. My desktop machine is Windows, showing I do not care much about restrictive licenses. :-) -- Gergo Szakal [EMAIL PROTECTED] University Of Szeged, HU Faculty Of General Medicine /* Please do not CC me with replies, thank you. */
Re: To be a new DFly commiter
On Fri, 16 Mar 2007 20:47:47 +0100 [EMAIL PROTECTED] wrote: I don't like pkgsrc because this limitations: 1. Many packages in pkgsrc are obsolete, and there are no development version of almost all packages (i wan't to see new version of dbmail, xorg and enlightenment 0.17 in packages system). I am sure the pkgsrc developers will merge patches that update the necessary packages. Every time I had such a problem they updated the tree. 2. Many packages in pkgsrc are configured with '--without-threading' option, because not all systems which pkgsrc work on support threading. I want omit this limitation. AFAIK this can be overriden (platform-specificly) in the makefile. 3. Binary upgrade packages with pkg_add -u is difficult. Eg. it is possible to upgrade only selected packages. Pacman can upgrade selected packages and also whole installed packages. I think we should have tool to binary upgrade base system also. Well, I tried binary upgrades only once and it did not work for me, maybe I should try again. The binary upgrades are a must in my opinion for the installed packages and the base system. -- Gergo Szakal [EMAIL PROTECTED] University Of Szeged, HU Faculty Of General Medicine /* Please do not CC me with replies, thank you. */
Re: Re: To be a new DFly commiter
On Fri, 16 Mar 2007 20:58:37 +0100, Joerg Sonnenberger wrote: On Fri, Mar 16, 2007 at 06:07:07PM +0100, Grzegorz B?ach wrote: When you do buffer-overflow in passwd you can exec any code with root priviledges, but with tcb you must change root password to run code with root priviledges, and administrator will see this faster. Who said that I want to change the root password? I can easily just create a new user with uid 0, login remotely as that and change the entry back. Very little log pollution and that can be easily taken care of. Joerg To add new user with uid 0 you must edit /etc/passwd file, which is not SGID shadow. And I put a mistake in this, with SGID shadow you can only cds to /etc/tcb dir, for edit user shadow file you must run code as this user or root. Domena za 90 groszy! www.nazwa.pl
Re: Re: To be a new DFly commiter
Can you please fix your MUA to follow mailing list etiquettes with regard to line length? Thanks. On Fri, Mar 16, 2007 at 08:47:47PM +0100, [EMAIL PROTECTED] wrote: I don't like pkgsrc because this limitations: 1. Many packages in pkgsrc are obsolete, and there are no development version of almost all packages (i wan't to see new version of dbmail, xorg and enlightenment 0.17 in packages system). Not running behind every development version is a feature. Even the stable releases of many programs are bad enough... I don't know about enlightenment. Ask the maintainer for dbmail, he might or might not have a reason. Keep in mind that many of us use this software on our server, so we are somewhat reluctant to randomly update working code. Modular Xorg is work in progress. Don't know which newer versions you want to see as the supported parts are almost all up-to-date. 2. Many packages in pkgsrc are configured with '--without-threading' option, because not all systems which pkgsrc work on support threading. I want omit this limitation. I find only xerces-c, where it is disabled by default. The rest use whatever the packages does by default. I don't know what you base your opinion on, it certainly isn't because some of the platforms lack thread support (in which case pth would be used automatically). Joerg
Re: To be a new DFly commiter
[EMAIL PROTECTED] wrote: c) add support for openwall tcb - the alternative to shadow (with pam module) which is more secure than pam_unix and pam_pwdb, because tools like 'passwd' or 'chage' don't neet SUID, instead it use SGID 'shadow'. Group 'auth' may be used to read-only access to all password hashes. I am not convinced that this improves security. Could you please detail your security considerations? My point is: current tools have been exposed to security audit for over 20 years now, so unless something else is conceptually more secure, chances are high that we should stick with the original system. I made a mistake in this point, SGID shadow can only read users list (can not read/write passwords). SGID auth can read passwords, but can not write it. Every user have its own shadow file whitch is owned by this user. Write to user's shadow file can only this user or root. There is not required SUID root for passwd and related tools. For more you can read on http://openwall.com/tcb/. Yes, I read the docs and I think this is a quite nice and simple scheme to restrict access and to get rid of a couple of setuid root binaries. We definitely should discuss this. I'm not talking about integrating the sources because I suspect they are GPL, but about the principle itself. Short for everybody too lazy to read: master.passwd is being split into single per-user files. these are located in per-user dirs with mode $user:auth 710 and the files $user:auth 640. this way only root+user can change the files and therefore the password. only root+user+group auth can read/check the password. don't know about chsh(1) etc. cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ signature.asc Description: OpenPGP digital signature
Re: To be a new DFly commiter
Well, hmm. Kinda out of the blue, and I don't want to discourage anyone who is this enthusiastic, but I have a few buts of my own. 1. a) chg default password_format do blowfish since there are known algoritm of collision for md5. I don't think this is a big issue. When I was doing BEST Internet we had a number of incidents where the master.passwd file on a user machine would get stolen. Even though only root can read it there were numerous holes in programs that at least allowed unauthorized read access to root-only files. This occured several times throughout BEST's history and we had to ask people to change their passwords on the effected machines. The person would then run a cracker on the file off-line. Crackers tended to simply guess passwords, though, not actually try to decrypt or fake them. I do not think the MD5 collision issue is really pertainant to the main problem. Also, who actually uses passwords in the password file any more these days? I don't know about all of you, but I do not run any services where REMOTE access to the machine is granted via a standard password. It is ssh or nothing. b) add support for openwall passwdqc (password checker) pam module (this was added to FreeBSD 5.0) c) add support for openwall tcb - the alternative to shadow (with pam module) which is more secure than pam_unix and pam_pwdb, because tools like 'passwd' or 'chage' don't neet SUID, instead it use SGID 'shadow'. Group 'auth' may be used to read-only access to all password hashes. I don't like the idea of changing the password file mechanics, and especially do not like the idea of storing anything in the user's home directory. In my considered opinion, not even the user should have any access to the encrypted form of his password (and I think this is one of the deficiencies of the .ssh/authorized_keys file mechanism that SSH uses). 2. a) Replace sendmail with postfix (with cyrus-sasl). It is faster and use cleaner config file. I personally believe that postfix is superior. I personally do not mind running GPL'd code. But I also would prefer to have as little GPL'd code in our managed code base as possible. What does this mean? I would dearly like to integrate portions of pkgsrc managed packages into our buildworld and installworld system, that is have the buildworld create a little package building jail and build and install selected packages, with appropriate defaults, as part of the base system build. Then we would not have to import or maintain the sources for at least the larger integrated pieces (such as sendmail/postfix, bind, etc). b) Add imap-uw as simple pop3 and imap4 daemon. I'd prefer this be maintained via pkgsrc. c) Add stunnel for SSL/TLS access to mail-related daemon. I don't have much background knowledge on stunnel. It sounds like another thing that should be maintained via pkgsrc. 3. Build alternative to pkgsrc packages system, which will be build on pacman from archlinux.org, and use tweaked PKGBUILD scripts. This packages system should be easier to maintain, and we will keep track on all our packages. For faster port packages to DFly, we can use makepkg with PKGBUILD (which is a shell script) or we can rewrite this scripts to Makefiles which will stop building package on error. I will rewrite pacman tool which will be use this same archive format, but for library to reading archives I'll use libarchive, and for fetching packages from net I'll use libfetch. I need name for this tool, because this should be different than pacman. I don't think a single person would be able to maintain an alternative. Simply keeping up to date with all the new versions of various things that occur every day would be difficult. -Matt
Re: To be a new DFly commiter
On Fri, March 16, 2007 7:05 pm, Simon 'corecode' Schubert wrote: Short for everybody too lazy to read: master.passwd is being split into single per-user files. these are located in per-user dirs with mode $user:auth 710 and the files $user:auth 640. this way only root+user can change the files and therefore the password. only root+user+group auth can read/check the password. don't know about chsh(1) etc. It doesn't seem like a bad idea. In fact, I propose a new rule of thumb: For any proposed feature where: 1: Matt doesn't object, and 2: No existing functionality is lost it should go in. Looking at the LICENSE file, it is indeedy under a BSD license. Grzegorz, can you submit a unified diff?
