Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
Le Mon, Sep 01, 2008 at 02:50:29PM +0200, Wouter Verhelst a écrit : > > This education could be done in two steps: first, create a policy and > link to it from debian-devel-announce; second, make this required > reading for the NM procedure (similar to the 'DMUP' and 'SC/DFSG' > questions that NMs need to agree to in a signed mail). In the case of > Debian, I think it's fair to assume people do not want security > breaches, which may or may not be the case for other organizations. Hi all, I think that it is an excellent idea. Few years ago I had a passwordless SSH key on Alioth. I shamefully realised my mistake (and hereby deeply apologise to the admins), but now feel very scared about operations on the Debian network: am I doing other mistakes like this by ignorance? During the recent discussion about DSA and RSA keys I realised that things that were obvious to some are not obvious to me (for instance, that DSA keys should not be used. I only saw this recommendation in Debian. There is no such rule at my work place, where SSH authentification on our workstations is mandatory). I really agree with Wouter that a simple policy ruling how to not make beginners mistakes with one's SSH and GPG key, how to not get ones's own home Debian server hacked (1),… would be a great enhancement to Debian's security. For the reasons exposed above, I can not propose myself to write it ;) (1) I have always been wondering of the following: - a malicous person gets the list of all DDs, - identifies those who have a home Debian server, - selects those who are on a distant timezone or on vacation, - patiently waits that a DSA for a grave issue is issued, - gets control of some machines in the delay between DSA publication and cron installation of the security updates, - exploits this position to do really bad things afterwards. Have a nice day, -- Charles Plessy Debian Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Mon, Sep 01, 2008 at 02:50:29PM +0200, Wouter Verhelst wrote: > By setting the "GSSAPICleanupCredentials" option in sshd_config, the > credentials cache is destroyed upon logout (this can also be done > through the session component of libpam_krb5.so). ... but pam_krb5.so shouldn't be used for this, since that involves handing passwords to the remote server. :) > I'm not entirely sure whether destroying a credentials cache means the KDC > is also instructed to revoke the TGT and cannot check currently, but I > believe this is the case. It does not; that would be unnecessary communication with the KDC. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sun, Aug 31, 2008 at 11:19:45AM +0200, Peter Palfrader wrote: > On Sat, 30 Aug 2008, Steve Langasek wrote: > > Well, the underlying premise here is, of course, that certain routinely > > useful capabilities need to be taken out of the hands of the users because > > they won't use them responsibly[1]. > > > But we're already talking > > about hard policy changes to stop users from doing things they shouldn't do > > in the first place (== using passwords when logging in to Debian servers > > from their systems), so I don't think you should underestimate the capacity > > of developers to be cleverly stupid when security is concerned. > > I don't think that using the password per se on debian hosts is an evil > thing to do. I have to do it dozens of time almost every day for sudo. > And I don't think nopasswd entries in the sudoers file would be all that > much better. Or we could start shipping a pam pwdfile table for use > with sudo. Maybe we should do that anyway, regardless of what comes > from this discussion. > > Also I agree, if somebody willfully compromises security there's nothing > we, or anyone, can do. It doesn't necessarily have to be willfully. Security is mostly a social problem, not a technical one; you have to keep that in mind at all times. Even though the average Debian Developer is stronger on a technical level than the average computer user, that doesn't mean there aren't any bad apples; and it certainly doesn't mean all Debian Developers understand all the intricacies of security problems. What is sure, however, is that as you create more hoops you for people to jump through, people will try to find more and more workarounds for these hoops; and, therefore, that in many cases implementing a measure meant to increase security may, in fact, lower the security of your system as a whole rather than increase it, simply because people have other tradeoffs to make than you as a security-aware system administrator. While it may sound attractive to say "You're only allowed to access Debian.org from your home system after sending a GPG-encrypted mail to a particular system and waiting for a one-time-password that you will receive through an automated phone system"[1], it's clear that people will try to work around that system, because they don't know any better, or because there's an emergency, or whatnot. I personally do not share the belief that outlawing password-based login is going to improve security. If we're afraid of keyloggers, then we should also be afraid of using software that intercepts Kerberos TGTs, SSH keys, etc; if we're afraid of weak passwords, then we should also be afraid of weak SSL/SSH/... keys. On the other hand, outlawing password-based logins may initially make people who want to SSH debian systems from work jump through their home system in order to access their SSH key; but I suspect they'll eventually create an SSH key on their work machine, not realizing that their dark evil system administrator has access to their hard disk, allowing them to brute-force it. Additionally, you don't necessarily know what the state of the link between their work system and their home system is; the SSH daemon on the home system may be compromised, or may be limited to a weak encryption, or whatever. Allowing password-based deals with all these issues, because you only need to take care that what you are running is safe, and that _your own_ encryption is strong enough, as opposed to the encryption between the host you're talking to and the host the user is actually physically using. That does require you to enforce a "safe passwords only" policy, but this can be done through the likes of cracklib. I believe that beyond implementing checks at reasonable places, enforcing that only secure protocols are used (with 'secure' being defined as 'does not send important security credentials over the wire in such a way that they could be re-used for other services by an eavesdropper'), and, especially, educating users on things to do vs things not to do, there isn't much you can do. Speaking of secure protocols: someone should _really_ update db.debian.org so that slapd does /not/ accept password-based authentication over non-encrypted links[2]. This education could be done in two steps: first, create a policy and link to it from debian-devel-announce; second, make this required reading for the NM procedure (similar to the 'DMUP' and 'SC/DFSG' questions that NMs need to agree to in a signed mail). In the case of Debian, I think it's fair to assume people do not want security breaches, which may or may not be the case for other organizations. > > Having your inter-host file transfers sandboxed, such that you have to log > > in to the host on each end in order to get the files copied to the place you > > want them, would be a serious nuisance, and in particular, it would not > > allow for good use of rsync as a time- and bandwidth- sav
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sun, Aug 31, 2008 at 11:19:45AM +0200, Peter Palfrader wrote: >On Sat, 30 Aug 2008, Steve Langasek wrote: > >> Having your inter-host file transfers sandboxed, such that you have to log >> in to the host on each end in order to get the files copied to the place you >> want them, would be a serious nuisance, and in particular, it would not >> allow for good use of rsync as a time- and bandwidth- saving technique. >> Having to start a separate ssh agent for Debian systems would also not be >> user-friendly. > >How often do you do that, seriously? I can't think off-hand of the last >time I had to rsync large amounts of data as weasel between debian >hosts. I don't rule out that it happens, I would just like to know if >it's a daily routine. For reference, I do it multiple times daily from cron, to transfer files around for the daily CD builds. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "C++ ate my sanity" -- Jon Rabone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sat Aug 30 16:43, Steve Langasek wrote: > This is obviously an *incredibly* bad idea for anyone to do if they actually > care about the security of the Debian systems. But we're already talking > about hard policy changes to stop users from doing things they shouldn't do > in the first place (== using passwords when logging in to Debian servers > from their systems), so I don't think you should underestimate the capacity > of developers to be cleverly stupid when security is concerned. If the idea is to remove password access to stop credentials sniffed on one machine being used on another, how about some form of one time password system? The University of Cambridge computer laboratory has recently changed to only allowing OTP or key login to machines using a system written by Markus Kuhn, who has some claim to being a competent security researcher and hence who's system I would trust. This system is called OTPW, has PAM integration and is in Lenny. Markus wrote it to fix some security flaws in the design of other OTP systems such as OPIE. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sat, Aug 30, 2008 at 10:54:59PM -0700, Steve Langasek wrote: > On Sun, Aug 31, 2008 at 01:16:32AM +0200, Bastian Blank wrote: > > Negotiate auth does not provide confidentiality or integrity protection > > different to the normal use of kerberos. > Well, ok, but you're negotiating *authentication*. Why are confidentiality > and integrity protection required for that? If you use kerberized telnet you get that for free, the session key is part of the setup. > Firefox doesn't exactly have > HTTP basic auth support disabled by default, either... You need to supply a username and password for each basic auth, so you know what you are doing. Kerberos runs in the background, so the user can't see that it got authenticated. Bastian -- If some day we are defeated, well, war has its fortunes, good and bad. -- Commander Kor, "Errand of Mercy", stardate 3201.7 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sat, 30 Aug 2008, Steve Langasek wrote: > Well, the underlying premise here is, of course, that certain routinely > useful capabilities need to be taken out of the hands of the users because > they won't use them responsibly[1]. > But we're already talking > about hard policy changes to stop users from doing things they shouldn't do > in the first place (== using passwords when logging in to Debian servers > from their systems), so I don't think you should underestimate the capacity > of developers to be cleverly stupid when security is concerned. I don't think that using the password per se on debian hosts is an evil thing to do. I have to do it dozens of time almost every day for sudo. And I don't think nopasswd entries in the sudoers file would be all that much better. Or we could start shipping a pam pwdfile table for use with sudo. Maybe we should do that anyway, regardless of what comes from this discussion. Also I agree, if somebody willfully compromises security there's nothing we, or anyone, can do. > Having your inter-host file transfers sandboxed, such that you have to log > in to the host on each end in order to get the files copied to the place you > want them, would be a serious nuisance, and in particular, it would not > allow for good use of rsync as a time- and bandwidth- saving technique. > Having to start a separate ssh agent for Debian systems would also not be > user-friendly. How often do you do that, seriously? I can't think off-hand of the last time I had to rsync large amounts of data as weasel between debian hosts. I don't rule out that it happens, I would just like to know if it's a daily routine. > Kerberized ssh with ticket forwarding is one of the better ones in this > regard, because it doesn't require typing a password across the wire and the > delegated credentials have a limited lifetime. I fail to see how this is better than ssh agent forwarding. This might be because I never really did much with ticket forwarding but I always thougt the idea was to forward a TGT, so it again would give you access to all hosts, for much longer than you are logged in probably. > RSA auth forwarding is also good by this standard, because the credentials > are only available while the user's initial connection is active and there > are methods for requiring user confirmation for each instance of > authentication forwarding. Agree on the available only temporary. I don't think many people use the confirmation of each instance of agent use (not forwarded use, I don't think that's possible, is it?). I did that a while ago but it got so annoying since I ssh to hosts hundreds of times a day. > Anything that involves sending your password across the wire, or storing RSA > keys on the Debian host, is pretty obviously not good. Anything that involves sending a password over the wire that can be used to access shells on other machines should be avoided, agreed. > But if you don't find these arguments persuasive, then of the options > proposed, I think AFS is the best. (Or you could use Samba with Kerberos > sign+seal... :) The nice property of AFS is that it allows for a more decentralized setup, if I understand things correctly. I.e. you would not rely on a single server in a single location. > > 1. And more likely the user will fetch a full TGT on the source host > > when they want to copy stuff to another host since the default mode of > > login will probably stay ssh keys. > > Well, a way around that is to not give users kinit on the Debian hosts, > and/or implement ACLs on the KDC that prohibit issuing TGTs to Debian hosts. Not sure how feasable that would be, and what it would help if you can just forward a TGT to a debian host. -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sat, Aug 30, 2008 at 03:01:00PM -0700, Steve Langasek wrote: > On Sat, Aug 30, 2008 at 06:48:57PM +0200, Wouter Verhelst wrote: > > > + once we have a krb realm we could maybe also use it for other > > > stuff like all those web services that require logins. How > > > good is krb support in browsers these days? > > > Pretty good. Konqueror supports it out of the box, iceweasel only > > requires you to edit the 'network.negotiate-auth.trusted-uris' > > about:config variable, and then it works well, too. Dunno about other > > browsers. > > > (for some infathomable reason, the firefox developers consider Negotiate > > authentication to be unsafe with untrusted and/or non-SSL hosts. Dunno > > why that is, and never saw a compelling argument...) > > And what do the iceweasel developers think? Perhaps iceweasel could have > this enabled by default? (Or are there other negotiations besides Kerberos > that are enabled with this setting, which should be avoided?) I would say as Russ. Plus the fact that apparently, it currently doesn't work (see bug #496933). Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sun, Aug 31, 2008 at 01:16:32AM +0200, Bastian Blank wrote: > On Sat, Aug 30, 2008 at 06:48:57PM +0200, Wouter Verhelst wrote: > > (for some infathomable reason, the firefox developers consider Negotiate > > authentication to be unsafe with untrusted and/or non-SSL hosts. Dunno > > why that is, and never saw a compelling argument...) > Negotiate auth does not provide confidentiality or integrity protection > different to the normal use of kerberos. Well, ok, but you're negotiating *authentication*. Why are confidentiality and integrity protection required for that? Firefox doesn't exactly have HTTP basic auth support disabled by default, either... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sat, Aug 30, 2008 at 05:46:16PM +0200, Peter Palfrader wrote: > > > What other options did we forget? > > - Setup Kerberos, allow it as an additional ssh login variant > Circumvents the entire idea behind this exercise: Assuming an attacker > already has control over one host we want to make it as hard as possible > for them to jump to other hosts. Well, the underlying premise here is, of course, that certain routinely useful capabilities need to be taken out of the hands of the users because they won't use them responsibly[1]. But you haven't yet guarded against an even more irresponsible use of ssh capabilities: - create an ssh key - add the public key to LDAP as an authorized key - install unencrypted copies of the key on every Debian host you can access - add various levels of obfuscation to keep the mean admins from noticing and taking away your access (name the file ".cshrc" and add an IdentityFile option to .ssh/config, or make an alias for ssh, or make an alias called something /other/ than ssh...) - instant, password-free access from any Debian host to any other Debian host - ... for anyone who has managed to gain access to the account on *any* of the systems. Without them having to catch you logging in first. This is obviously an *incredibly* bad idea for anyone to do if they actually care about the security of the Debian systems. But we're already talking about hard policy changes to stop users from doing things they shouldn't do in the first place (== using passwords when logging in to Debian servers from their systems), so I don't think you should underestimate the capacity of developers to be cleverly stupid when security is concerned. So, given that I don't see a good way for you to prevent the above "strategy" (or other twisted workarounds that I haven't thought of) without also blocking lots more legitimate uses, I think it's important to ensure that doing things the "right" way isn't made so difficult that people resort to ad-hoc insecure methods to get things done. Having your inter-host file transfers sandboxed, such that you have to log in to the host on each end in order to get the files copied to the place you want them, would be a serious nuisance, and in particular, it would not allow for good use of rsync as a time- and bandwidth- saving technique. Having to start a separate ssh agent for Debian systems would also not be user-friendly. I think that choosing solutions with either of these features would result in a significant number of users doing less responsible things with their ssh keys in order to get work done. As a result, I don't think you're going to completely eliminate the risk of shell-hopping[2], and therefore the emphasis should be on mitigation, so that the methods people will prefer to use have the least window of exposure. Kerberized ssh with ticket forwarding is one of the better ones in this regard, because it doesn't require typing a password across the wire and the delegated credentials have a limited lifetime. RSA auth forwarding is also good by this standard, because the credentials are only available while the user's initial connection is active and there are methods for requiring user confirmation for each instance of authentication forwarding. Anything that involves sending your password across the wire, or storing RSA keys on the Debian host, is pretty obviously not good. But if you don't find these arguments persuasive, then of the options proposed, I think AFS is the best. (Or you could use Samba with Kerberos sign+seal... :) > 1. And more likely the user will fetch a full TGT on the source host > when they want to copy stuff to another host since the default mode of > login will probably stay ssh keys. Well, a way around that is to not give users kinit on the Debian hosts, and/or implement ACLs on the KDC that prohibit issuing TGTs to Debian hosts. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] [1] or that there is no responsible use for them [2] even if you go the route of requiring confirmation for each use of the ssh agent, your ssh client on the Debian host is not a privileged process, so if someone has compromised your account, they can hijack your connection once it's established... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sat, Aug 30, 2008 at 06:48:57PM +0200, Wouter Verhelst wrote: > (for some infathomable reason, the firefox developers consider Negotiate > authentication to be unsafe with untrusted and/or non-SSL hosts. Dunno > why that is, and never saw a compelling argument...) Negotiate auth does not provide confidentiality or integrity protection different to the normal use of kerberos. Bastian -- What kind of love is that? Not to be loved; never to have shown love. -- Commissioner Nancy Hedford, "Metamorphosis", stardate 3219.8 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sat, Aug 30, 2008 at 06:48:57PM +0200, Wouter Verhelst wrote: > > + once we have a krb realm we could maybe also use it for other > > stuff like all those web services that require logins. How > > good is krb support in browsers these days? > Pretty good. Konqueror supports it out of the box, iceweasel only > requires you to edit the 'network.negotiate-auth.trusted-uris' > about:config variable, and then it works well, too. Dunno about other > browsers. > (for some infathomable reason, the firefox developers consider Negotiate > authentication to be unsafe with untrusted and/or non-SSL hosts. Dunno > why that is, and never saw a compelling argument...) And what do the iceweasel developers think? Perhaps iceweasel could have this enabled by default? (Or are there other negotiations besides Kerberos that are enabled with this setting, which should be avoided?) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sat, Aug 30, 2008 at 02:32:08PM +0200, Peter Palfrader wrote: > - setup afs > > Using AFS would allow us to use a shared /afs/debian.org tree on all > our systems. AFS does all the magic crypto stuff so you don't have to > worry about Eve sniffing or Mallory tampering with packets. > > Setting up AFS is a big chunk of work. It would require us first to > setup a kerberos realm, to integrate it into ud-ldap so that new krb > principals are created with ud-ldap users, and that ud-ldap users can > set krb passwords, which probably should be different from their ldap > password. > > On the user side once logged in you'd have to get a kerberos ticket > using your krb password, then alog to get access to your > /afs/debian.org/transfer/$user or whatever. > > We will not put homedirs onto AFS (that would completely torpedo the > initial goal), it would simply provide a transfer area. > > pros: + AFS is cool That's never been a very good reason, IMO. But, hey, I won't deny it, either ;-) > + once we have a krb realm we could maybe also use it for other > stuff like all those web services that require logins. How > good is krb support in browsers these days? Pretty good. Konqueror supports it out of the box, iceweasel only requires you to edit the 'network.negotiate-auth.trusted-uris' about:config variable, and then it works well, too. Dunno about other browsers. (for some infathomable reason, the firefox developers consider Negotiate authentication to be unsafe with untrusted and/or non-SSL hosts. Dunno why that is, and never saw a compelling argument...) -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sat, 30 Aug 2008, Bastian Blank wrote: > > Or you use only resolvers that you have a trusted (i.e. ipsec) > > connection to and those need to have a complete axfr'ed zone. > > Then we can drop the whole ud-ldap thing and use centralized > authentication. Um. I don't see why that follows. I don't think it matters however. :) ipsec/stunnel etc aren't the solution. > > > > What other options did we forget? > > > > > > - Setup Kerberos, allow it as an additional ssh login variant > > > > Circumvents the entire idea behind this exercise: Assuming an attacker > > already has control over one host we want to make it as hard as possible > > for them to jump to other hosts. > > Nope. It is the same that ssh with key auth. Anything an attacker can > get is a short-term secret in form of a forwarded ticket. The service > ticket themself is useless for anything else then the direct connection > between the user and the server. But it allows them to get a shell on the target server. Even if only for a short term[1]. This means we lose. 1. And more likely the user will fetch a full TGT on the source host when they want to copy stuff to another host since the default mode of login will probably stay ssh keys. -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sat, Aug 30, 2008 at 05:46:16PM +0200, Peter Palfrader wrote: > On Sat, 30 Aug 2008, Bastian Blank wrote: > > On Sat, Aug 30, 2008 at 02:32:08PM +0200, Peter Palfrader wrote: > > > The crypto stuff could be alleviated by using ipsec between all our > > > servers. But that works even less well than you'd expect. > > The machines needs to check DNSSEC or the names can be spoofed which > > makes ipsec mood. > Or you use only resolvers that you have a trusted (i.e. ipsec) > connection to and those need to have a complete axfr'ed zone. Then we can drop the whole ud-ldap thing and use centralized authentication. > > > What other options did we forget? > > > > - Setup Kerberos, allow it as an additional ssh login variant > > Circumvents the entire idea behind this exercise: Assuming an attacker > already has control over one host we want to make it as hard as possible > for them to jump to other hosts. Nope. It is the same that ssh with key auth. Anything an attacker can get is a short-term secret in form of a forwarded ticket. The service ticket themself is useless for anything else then the direct connection between the user and the server. Bastian -- Too much of anything, even love, isn't necessarily a good thing. -- Kirk, "The Trouble with Tribbles", stardate 4525.6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
[Trimming lists] On Sat, 30 Aug 2008, Bastian Blank wrote: > On Sat, Aug 30, 2008 at 02:32:08PM +0200, Peter Palfrader wrote: > > - install sendfile/saft on all machines so you can do > > sendfile foo.tar.gz [EMAIL PROTECTED] > > > > The crypto stuff could be alleviated by using ipsec between all our > > servers. But that works even less well than you'd expect. > > The machines needs to check DNSSEC or the names can be spoofed which > makes ipsec mood. Or you use only resolvers that you have a trusted (i.e. ipsec) connection to and those need to have a complete axfr'ed zone. As hinted in the original email, I don't think ipsec (or stunnel) are useful solutions to help us make sendfile suck less. > > - setup afs > > > > pros: + AFS is cool > > Yeah. You can make read-only snapshots for backup purposes. Probably not useful for a transfer share. But if it ever grows beyond that that might be useful. > > - AFS suffers from the not-a-filesystem syndrome: file access > > control is not unix-like and will confuse users. > > Also other parts are not really POSIX-like. Hardlinks or so. Direct consequence of its permission model I'd assume. > > What other options did we forget? > > - Setup Kerberos, allow it as an additional ssh login variant Circumvents the entire idea behind this exercise: Assuming an attacker already has control over one host we want to make it as hard as possible for them to jump to other hosts. -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sat, Aug 30, 2008 at 03:16:01PM +0200, Bastian Blank wrote: On Sat, Aug 30, 2008 at 02:32:08PM +0200, Peter Palfrader wrote: + once we have a krb realm we could maybe also use it for other stuff like all those web services that require logins. How good is krb support in browsers these days? Firefox supports it in a whitelist approach. However I never tested it. I use Kerberos authentication for my OpenID server, and it works flawlessly with Iceweasel and mod_auth_kerb. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sat, Aug 30, 2008 at 02:32:08PM +0200, Peter Palfrader wrote: > - install sendfile/saft on all machines so you can do > sendfile foo.tar.gz [EMAIL PROTECTED] > > The crypto stuff could be alleviated by using ipsec between all our > servers. But that works even less well than you'd expect. The machines needs to check DNSSEC or the names can be spoofed which makes ipsec mood. > - setup afs > > pros: + AFS is cool Yeah. You can make read-only snapshots for backup purposes. > + once we have a krb realm we could maybe also use it for other > stuff like all those web services that require logins. How > good is krb support in browsers these days? Firefox supports it in a whitelist approach. However I never tested it. > cons: - integrating krb and afs into ud-ldap is a lot of work > - setting up afs will be a lot of work too > - little prior experience with afs > - AFS suffers from the not-a-filesystem syndrome: file access > control is not unix-like and will confuse users. Also other parts are not really POSIX-like. Hardlinks or so. > - might cause problems with existing firewalls. - The needed kernel module still uses rootkit-like behaviour. > What other options did we forget? - Setup Kerberos, allow it as an additional ssh login variant + Ticket forwarding However, only the insecure options allow automatic operation, so lets extend some options (yes, I think about the D-I images which are located in people): - Allow additional principals for automatic usage This can be combined with AFS and SSH-Kerberos Each user can create additional principals $USER/cron/[EMAIL PROTECTED], the keys are put into a keyfile so that a script can create a ticket and use that to do the operations. AFS: Just needs proper ACLs for this principal. SSH: Needs mapping in /etc/krb/krb5.conf or .k5login and there was something else. Bastian -- Extreme feminine beauty is always disturbing. -- Spock, "The Cloud Minders", stardate 5818.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
