Re: [SLUG] Re: Need help in choosing distro (Rev Simon Rumble)
Kirti Pankhania wrote: That sounds interesting. With Knoppix, how does one save basic config info in hard drive? The distro gives you te option to place a config file on the HDD if you do any configuration. Also is it possible to configure the internet connection to run via Knoppix? Yes. Set it up using the Internet config tool provided with Knoppix. And, how does one enable deletion of or writing to windows files when necessary through Linux? Depends upon your security. If you Windows is not nt based just mount the directory. If it is then you can still mount the drive, but have to provide a password and username acceptable to nt. I have some programs and internet sites that seem to have piggybacked onto my system that are impossible to delete, even with the MSDOS prompt. Probably adware or similar. Google for free adware and spyware removers. eg Adaware, Spyblaster and Spybot search and destroy are useful. My daughter uses these three and between them she seems to get rid of everything. Hope that helps. Stay well and happy Heracles PS You know that you can install Knoppix on your HDD if you want don't you. Check their site. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Re: Preventing attacks
On Mon, Nov 08, 2004 at 01:31:51PM +1100, O Plameras wrote: Ken Foskey wrote: I am unsure how this would have prevented the attack on the kernel that was applied? Please explain. With the intruder having acquired unprivileged access to system, he/she could have been confined to limited sets of functions because that is one of the things that SELinux does. Because he/she is restricted in what can be done it will take a bit longer to figure out ( I assume ) how to escalate privileges to root. In Only if the set of privileges granted to the program didn't include access to the flawed function. It was ptrace(), so an allow only that which is really required policy would have probably blocked the access, there's no guarantee. the meantime the SysAdmin who does what he does will notice unusual activities within his system and so, the intruder could have been detected before doing damage to the Servers. Potentially. Depends on how many tripwires the attacker managed to hit. 2. Would 'kerberos' have prevented this sort of break-in ? The initial attack was by social engineering. One developers key was compromised due to their lack of security thought. With one weak link in the chain then it all comes down. Now, I posed the problem without really knowing the complete details of the circumstances because 'kerberos' is meant to be the strongest security protection against this sort of attacks. Where the hell did you pick that up from? This sort of attacks could be one of: 1) Sniff the entry of a password on a previously compromised host: hmm, no, Kerberos doesn't protect against r00ted boxen. 2) Exploitation of a kernel vulnerability to obtain escalated privileges: riiight. 3) Use of a stored authentication credential to gain access to a system account on another system: probably not, and Kerberos is a real pest in this situation. I gather that 'ssh' which I noticed is the cryptographic security procedure used at these Debian sites has not prevented the attacks. Hoo boy. I note here some differences between ssh and kerberos: 1. SSH needs local identity files whilst kerberos does not You mean known_hosts? No, kerberos just restricts you to a small set of hosts which you can access (without setting up cross-domain trust relationships). And after all, if an attacker has just sniffed your password, he'd be very, very unlucky not to get the hast you connected as well. 2. SSH does not impose time restrictions on a session whilst kerberos does (Prevents replay attacks) From memory, SSH uses some form of challenge/response to set things up, so a replay attack wouldn't be feasible. 3. In SSH the client decides what tools and application to run on the server I call 'horseshit'. Should have done it two days ago, but there you are. whilst in kerberos, the server may restrict the clients from running certain tools and applications (Ease and simplicity of management as to who and what to allow or disallow) You've never actually administered, or even smelt, a Kerberos system, have you? Ease and simplicity of management is not something I hear often in connection with Kerberos. This is my understanding of SSH and Kerberos so correct me if I'm wrong. You're wrong. - Matt signature.asc Description: Digital signature -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Re: Preventing attacks
On Mon, Nov 08, 2004 at 03:50:35PM +1100, O Plameras wrote: Tony Green wrote: They can be used together but kerberos on it's own provides no way to remotely (or locally) access the machine. Kerberos can because it comes with kerberized telnet, rsh, rlogin, rcp, etc. that lets us connect to another machine in the realm. But that's not Kerberos doing that, it's whatever application has been taken to with a bandsaw to make it do the Kerberos Dance. Of course I can ssh to machines that are members of kerberos realm. But why should I need ssh when I have kerberos ? The reason I'm running kerberos is it is a stronger cryptographic security tool than SSH. Please feel free to use your sexy Kerberized telnet service to connect to your server next time I'm nearby with dsniff. - Matt signature.asc Description: Digital signature -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] 3d graphics viewing/modelling
On Sun, 7 Nov 2004 22:12:49 +1100 Jamie Wilkinson [EMAIL PROTECTED] wrote: There's a library called gle, the GL Extrusion toolkit, if you just want to display the model via the OpenGL pipeline; if you want to get that model data out it's possible (through the tesselate callbacks, gle wraps GLU) but last I tried to do that, I found the X11 libraries lacking, so it wasn't actually possible :-) I reckon in the timespan of a codefest I could whip up such a program :-) Is that an offer? Erik -- +---+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ Linux, the UNIX defragmentation tool. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Security adding another 'user' to a web site.
Michael Lake wrote: 4. Other ways ? What's the easist way to allow the new user to use windows scp but not browse the filesystem. Reading up on chroot jails it seems that they are not trivial to setup. How about webmin-updown module, for instance? In general, webmin might allow you to give limited access to certain operations over the web and without giving away shell access at all. Another option might be to use a restricting ftp server over ssh. BTW - I've just learned about winscp - http://winscp.sourceforge.net/eng/, it's so much more friendly than window's command line. Cheers, --Amos -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Building kernels [Was: Maybe trying out gentoo again]
On Mon, 2004-11-08 at 10:40 +1100, Jeff Waugh wrote: quote who=O Plameras For example, it should have taken the break-in longer from the time the attempt was first tried to the time it succeeded. And so, SysAdmin would have longer window to realise there has been attempts on the servers ? It should have confined the first break-in to within a limited set of functionalities ? Note that the entire break-in started with a sniffed password, which SELinux could not help with in the slightest. It may have kept the intruder stuck with no where to go. I am still confused why SELlinux would have prevented the escalation to root? There was a method by which a common program could intrude on the kernel, does it stop you from executing code? Also note that the only reason the break-in was noticed was because of a modification to the system. There was no indication prior to that point. The time that the intruder had was not the issue here. So boxing them in longer may have discouraged them and they gave up, but assume that they were persistent. -- Ken Foskey -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Preventing attacks
Matthew Palmer wrote: On Mon, Nov 08, 2004 at 01:31:51PM +1100, O Plameras wrote: Ken Foskey wrote: I am unsure how this would have prevented the attack on the kernel that was applied? Please explain. With the intruder having acquired unprivileged access to system, he/she could have been confined to limited sets of functions because that is one of the things that SELinux does. Because he/she is restricted in what can be done it will take a bit longer to figure out ( I assume ) how to escalate privileges to root. In Only if the set of privileges granted to the program didn't include access to the flawed function. It was ptrace(), so an allow only that which is really required policy would have probably blocked the access, there's no guarantee. I cannot comment on this because I do not know what you are talking about. If you can be clearer. the meantime the SysAdmin who does what he does will notice unusual activities within his system and so, the intruder could have been detected before doing damage to the Servers. Potentially. Depends on how many tripwires the attacker managed to hit. Your're probably right. 2. Would 'kerberos' have prevented this sort of break-in ? The initial attack was by social engineering. One developers key was compromised due to their lack of security thought. With one weak link in the chain then it all comes down. Now, I posed the problem without really knowing the complete details of the circumstances because 'kerberos' is meant to be the strongest security protection against this sort of attacks. Where the hell did you pick that up from? This sort of attacks could be one of: I got it from people who should know. 1) Sniff the entry of a password on a previously compromised host: hmm, no, Kerberos doesn't protect against r00ted boxen. Can you elaborate how kerberos and r00ted boxen works and where the latter will be able to trick kerberos ? 2) Exploitation of a kernel vulnerability to obtain escalated privileges: riiight. I do not quite follow this. You probably did not read the circumstance surrounding the Debian Break-In. (http://www.wiggy.net/debian/explanation/) 3) Use of a stored authentication credential to gain access to a system account on another system: probably not, and Kerberos is a real pest in this situation. You are saying things about kerberos without knowing what kerberos is, what it is not, and what it can do. I gather that 'ssh' which I noticed is the cryptographic security procedure used at these Debian sites has not prevented the attacks. Hoo boy. I note here some differences between ssh and kerberos: 1. SSH needs local identity files whilst kerberos does not You mean known_hosts? No, kerberos just restricts you to a small set of hosts which you can access (without setting up cross-domain trust relationships). And after all, if an attacker has just sniffed your password, he'd be very, very unlucky not to get the hast you connected as well. Everything in ~/.ssh directory. 2. SSH does not impose time restrictions on a session whilst kerberos does (Prevents replay attacks) From memory, SSH uses some form of challenge/response to set things up, so a replay attack wouldn't be feasible. From this response, it appears you do not understand what is a 'replay attack'. If you can explain perhaps. Your not as clear as can be. 3. In SSH the client decides what tools and application to run on the server I call 'horseshit'. Should have done it two days ago, but there you are. What you have above is the real 'horseshit' because in SSH once a client connects there is no mechanism to restrict the user to a subset of commands or functions. Whereas with Kerberos, there is a mechanism to do this. whilst in kerberos, the server may restrict the clients from running certain tools and applications (Ease and simplicity of management as to who and what to allow or disallow) You've never actually administered, or even smelt, a Kerberos system, have you? Ease and simplicity of management is not something I hear often in connection with Kerberos. This is another example of 'saying without knowing'. In kerberos, the SysAdmin simply goes to the one Server (Master Server and make changes for a user for example) and that change will be implemented in each servers within the realm. In SSH the SysAdmin will have to connect to each Server the user is connecting to , to effect the changes. Imagine if you have a Farm of Servers consisting of 500 Servers. So, I suggest you send yourself back to the drawing board as far as Kerberos is concerned. This is my understanding of SSH and Kerberos so correct me if I'm wrong. You're wrong. As you can see you're the one who is wrong. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] SELinux stuff [Was: Building kernels]
quote who=Ken Foskey On Mon, 2004-11-08 at 10:40 +1100, Jeff Waugh wrote: Note that the entire break-in started with a sniffed password, which SELinux could not help with in the slightest. It may have kept the intruder stuck with no where to go. I am still confused why SELlinux would have prevented the escalation to root? There was a method by which a common program could intrude on the kernel, does it stop you from executing code? SELinux, when configured properly, would have made it inordinately hard for an unprivileged [1] user to escalate their privileges to the equivalent of root (because, with SELinux, you can make 'root' or uid 0 entirely useless). So that common program may not have the capabilities to intrude on the kernel as it might on other systems. - Jeff [1] and with SELinux, we're talking about *much* finer grain privileges and capabilities that Linux provides -- linux.conf.au 2005: Canberra, Australia http://lca2005.linux.org.au/ Push the envelope, or push the daisies. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Building kernels [Was: Maybe trying out gentoo again]
On Mon Nov 08, 2004 at 20:59:00 +1100, Ken Foskey wrote: On Mon, 2004-11-08 at 10:40 +1100, Jeff Waugh wrote: quote who=O Plameras For example, it should have taken the break-in longer from the time the attempt was first tried to the time it succeeded. And so, SysAdmin would have longer window to realise there has been attempts on the servers ? It should have confined the first break-in to within a limited set of functionalities ? Note that the entire break-in started with a sniffed password, which SELinux could not help with in the slightest. It may have kept the intruder stuck with no where to go. I am still confused why SELlinux would have prevented the escalation to root? There was a method by which a common program could intrude on the kernel, does it stop you from executing code? Not for sure, but the way this kind of thing should work, is stopping you from running certain system calls, for example, ptrace. Benno -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Building kernels [Was: Maybe trying out gentoo again]
could not help with in the slightest. It may have kept the intruder stuck with no where to go. I am still confused why SELlinux would have prevented the escalation to root? There was a method by which a common program could intrude on the kernel, does it stop you from executing code? It might not always stop it, but as SELinux is a MAC (Mandatory Access Control) system you only get access to what you're allowed to, so a user process wouldn't be able to execute ptracesystem calls in the first place, but thn again the user wouldn't be able to do anything like debug any processes on the system.. which depending on the services the machine presents may not make it useful anymore... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Preventing attacks
Matthew Palmer wrote: But that's not Kerberos doing that, it's whatever application has been taken to with a bandsaw to make it do the Kerberos Dance. The point here is having a connection ( established through kerberised telnet), and once that connection is established, the messages exchanged between the two computers are encrypted. You can prove this to yourself by running tcpdump or ethereal between two Linux boxes connected with ordinary telnet. Then run tcpdump or ethereal between two Linux boxes connected via kerberised telnet. Then discover for yourself that you won't have a clue what looks the messages are exchanged between these two computers. Please feel free to use your sexy Kerberized telnet service to connect to your server next time I'm nearby with dsniff. - I do now believe you do not know what Kerberos is, what it does, what it can do, and why people love it. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Preventing attacks
quote who=O Plameras The point here is having a connection ( established through kerberised telnet), and once that connection is established, the messages exchanged between the two computers are encrypted. This is absolutely true for ssh, and *optionally* true for many kerberised telnet implementations. It is not a property of kerberos itself *at all*. Kerberos provides AAA support only. I do now believe you do not know what Kerberos is, what it does, what it can do, and why people love it. Oscar, you're better off listening and learning that biting the hand that feeds you. - Jeff -- linux.conf.au 2005: Canberra, Australia http://lca2005.linux.org.au/ Well, you know us usability folks... We like to believe that the two aren't mutually exclusive. - Calum Benson on power and cleanliness -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] SELinux stuff [Was: Building kernels]
On Mon, 2004-11-08 at 21:10 +1100, Jeff Waugh wrote: SELinux, when configured properly, would have made it inordinately hard for an unprivileged [1] user to escalate their privileges to the equivalent of root (because, with SELinux, you can make 'root' or uid 0 entirely useless). So that common program may not have the capabilities to intrude on the kernel as it might on other systems. Still doesn't fix bugs :). Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Re: Re: Preventing attacks
[Don't Cc me, I'm the list FFS] On Mon, Nov 08, 2004 at 09:08:23PM +1100, O Plameras wrote: Matthew Palmer wrote: On Mon, Nov 08, 2004 at 01:31:51PM +1100, O Plameras wrote: Ken Foskey wrote: I am unsure how this would have prevented the attack on the kernel that was applied? Please explain. With the intruder having acquired unprivileged access to system, he/she could have been confined to limited sets of functions because that is one of the things that SELinux does. Because he/she is restricted in what can be done it will take a bit longer to figure out ( I assume ) how to escalate privileges to root. In Only if the set of privileges granted to the program didn't include access to the flawed function. It was ptrace(), so an allow only that which is really required policy would have probably blocked the access, there's no guarantee. I cannot comment on this because I do not know what you are talking about. If you can be clearer. SELinux works by by restricting access to what can be done by a program. If the exploit program couldn't run the flawed code, then no exploit would be possible. If SELinux allows access to the flawed code, then the flaw can still be exploited to obtain elevated privileges. 2. Would 'kerberos' have prevented this sort of break-in ? The initial attack was by social engineering. One developers key was compromised due to their lack of security thought. With one weak link in the chain then it all comes down. Now, I posed the problem without really knowing the complete details of the circumstances because 'kerberos' is meant to be the strongest security protection against this sort of attacks. Where the hell did you pick that up from? This sort of attacks could be one of: I got it from people who should know. Care to name names? Voices in Oscar's Head don't count, by the way. 1) Sniff the entry of a password on a previously compromised host: hmm, no, Kerberos doesn't protect against r00ted boxen. Can you elaborate how kerberos and r00ted boxen works and where the latter will be able to trick kerberos ? Does that sound like something from Eliza to anyone else? tricking Kerberos has nothing to do with it. If I've got a keylogger on your computer, logging every keystroke you type, whether you type the password into a Kerberised application or not, you're toast. Kerberos is nothing, and I do mean *nothing*, more than a heavily overengineered (though still probably the best-of-breed) untrusted-network authentication system. 2) Exploitation of a kernel vulnerability to obtain escalated privileges: riiight. I do not quite follow this. You probably did not read the circumstance surrounding the Debian Break-In. (http://www.wiggy.net/debian/explanation/) ptrace vulnerability -- ring any bells? And yes, I read the circumstances surrounding the Debian Break-in. Quite closely. 3) Use of a stored authentication credential to gain access to a system account on another system: probably not, and Kerberos is a real pest in this situation. You are saying things about kerberos without knowing what kerberos is, what it is not, and what it can do. I did the initial setup and 3 years of ongoing maintenance of a 400 user Kerberos realm. Whilst I will profess to not be an almighty god on the issue, I think it's fair to say I've got some degree of experience with it. I note here some differences between ssh and kerberos: 1. SSH needs local identity files whilst kerberos does not You mean known_hosts? No, kerberos just restricts you to a small set of hosts which you can access (without setting up cross-domain trust relationships). And after all, if an attacker has just sniffed your password, he'd be very, very unlucky not to get the hast you connected as well. Everything in ~/.ssh directory. Which is, in the basic case, just known_hosts. That keystroke logger got the login command as well as the password, you know. 2. SSH does not impose time restrictions on a session whilst kerberos does (Prevents replay attacks) From memory, SSH uses some form of challenge/response to set things up, so a replay attack wouldn't be feasible. From this response, it appears you do not understand what is a 'replay attack'. If you can explain perhaps. Your not as clear as can be. Replay attack: a means of doing unpleasant things by resending previously captured information in the hope it will continue to elicit the same response as the initial transmission of the captured information. 3. In SSH the client decides what tools and application to run on the server I call 'horseshit'. Should have done it two days ago, but there you are. What you have above is the real 'horseshit' because in SSH once a client connects there is no mechanism to restrict the user to a subset of commands or functions. Whereas with Kerberos, there is a
Re: [SLUG] SELinux stuff [Was: Building kernels]
quote who=Robert Collins On Mon, 2004-11-08 at 21:10 +1100, Jeff Waugh wrote: SELinux, when configured properly, would have made it inordinately hard for an unprivileged [1] user to escalate their privileges to the equivalent of root (because, with SELinux, you can make 'root' or uid 0 entirely useless). So that common program may not have the capabilities to intrude on the kernel as it might on other systems. Still doesn't fix bugs :). You're absolutely right. To do that, you must Rebuild Kernel to Secure Servers. - Jeff -- linux.conf.au 2005: Canberra, Australia http://lca2005.linux.org.au/ He's not an idiot. The doctor said so. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Preventing attacks
On Mon, 2004-11-08 at 15:59 +1100, Robert Collins wrote: kerberos does not provide remote access, only AAA. kerberised telnet is still plaintext, so anything such as sudo being run via it will allow password sniffing, which in combination with a session hijack provide a gaping hole into the system that ssh doesn't. This is not altogether correct, I did some research (and along with a lot of security notifications) and found: -- Using Kerberos telnet To use the telnet program without having to type your password, you need to use it with the '-a' option. Otherwise you will be prompted for your password when you try to connection. Do not type your password. Any password you type will not be encrypted and will go over the network in the clear. If you use the '-a' option and it fails to log you in, this is normally becuase your Kerberos ticket has expired and you need to run kinit again. If this still fails please contact [EMAIL PROTECTED] and let us know about the problem. telnet also supports the '-x' option to encrypt your session and protect it's privacy. -- If you SPECIFICALLY request it (and I assume telnetd that you have installed allows it) then you get full encryption. I am still unsure whether this is better encryption than ssh however. -- Ken Foskey -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Re: Re: Preventing attacks
On Mon, Nov 08, 2004 at 09:19:32PM +1100, O Plameras wrote: Matthew Palmer wrote: But that's not Kerberos doing that, it's whatever application has been taken to with a bandsaw to make it do the Kerberos Dance. The point here is having a connection ( established through kerberised telnet), and once that connection is established, the messages exchanged between the two computers are encrypted. Not necessarily. Only if both ends of the connection negotiated some sort of stream encryption after the authentication has taken place. Please feel free to use your sexy Kerberized telnet service to connect to your server next time I'm nearby with dsniff. I do now believe you do not know what Kerberos is, what it does, what it can do, and why people love it. I do know what Kerberos is, I know what it does, I certainly know what it can do. However, I have a bit of a hard time working out why people love it. - Matt signature.asc Description: Digital signature -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Preventing attacks
I do now believe you do not know what Kerberos is, what it does, what it can do, and why people love it. http://www.isi.edu/gost/brian/security/kerberos.html might be worth reading for anyone who a) wonders what all the fuss is about, b) may not totally understand what kerberos is...(despite saying lots about it...) and as far as I remember I don't think anyone has ever professed any great love for it, Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Re: Preventing attacks
On Mon, 2004-11-08 at 21:39 +1100, Matthew Palmer wrote: Care to name names? Voices in Oscar's Head don't count, by the way. Matt, I think this is a little over the top. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Re: Preventing attacks
Matthew Palmer wrote: The point here is having a connection ( established through kerberised telnet), and once that connection is established, the messages exchanged between the two computers are encrypted. Not necessarily. Only if both ends of the connection negotiated some sort of stream encryption after the authentication has taken place. This is certainly wrong. Once connection is established in the Kerberos Realm all communications and messages exchanges are encrypted in accordance with the rules as specified in Kerberos. I do know what Kerberos is, I know what it does, I certainly know what it can do. However, I have a bit of a hard time working out why people love it. You are just saying without elaborating. It is one thing to say for you someone is wrong but you have not been forthcoming why you are right; no logical explanation. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Preventing attacks
Ken Foskey wrote: On Mon, 2004-11-08 at 15:59 +1100, Robert Collins wrote: kerberos does not provide remote access, only AAA. kerberised telnet is still plaintext, so anything such as sudo being run via it will allow password sniffing, which in combination with a session hijack provide a gaping hole into the system that ssh doesn't. This is not altogether correct, I did some research (and along with a lot of security notifications) and found: -- Using Kerberos telnet To use the telnet program without having to type your password, you need to use it with the '-a' option. Otherwise you will be prompted for your password when you try to connection. Do not type your password. Any password you type will not be encrypted and will go over the network in the clear. If you use the '-a' option and it fails to log you in, this is normally becuase your Kerberos ticket has expired and you need to run kinit again. If this still fails please contact [EMAIL PROTECTED] and let us know about the problem. telnet also supports the '-x' option to encrypt your session and protect it's privacy. -- If you SPECIFICALLY request it (and I assume telnetd that you have installed allows it) then you get full encryption. I am still unsure whether this is better encryption than ssh however. The only way to know is set up two computers; run tcpdump or ethereal; and connect plain telnet. Then, set up two computers; set up kerberos; run tcpdump or ethereal; and connect kerberised telnet. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Preventing attacks
quote who=O Plameras The only way to know is set up two computers; run tcpdump or ethereal; and connect plain telnet. Then, set up two computers; set up kerberos; run tcpdump or ethereal; and connect kerberised telnet. Oscar, Ken and I have both explained that it's optional. You could test if you wanted to waste time setting up kerberos, but you could also infer the functionality of the software from the documentation (as Ken has done). - Jeff -- linux.conf.au 2005: Canberra, Australia http://lca2005.linux.org.au/ Markets are what you sell bubbly health drinks, fluorescent blow up furniture and mobile phone ring melodies to. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Re: Preventing attacks
On Mon, 2004-11-08 at 21:55 +1100, O Plameras wrote: Matthew Palmer wrote: The point here is having a connection ( established through kerberised telnet), and once that connection is established, the messages exchanged between the two computers are encrypted. Not necessarily. Only if both ends of the connection negotiated some sort of stream encryption after the authentication has taken place. This is certainly wrong. Once connection is established in the Kerberos Realm all communications and messages exchanges are encrypted in accordance with the rules as specified in Kerberos. Actually, you are wrong, according to my Kerberos the definitive guide book here. The exact things that are encrypted, and how, depend on which kerberos implementation and version you are using, but regardless of that, kerberos itself only specifies the encryption for the AS handshake to get a TGT, and the TGS handshake for getting a ticket for a specific service. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Preventing attacks
The only way to know is set up two computers; run tcpdump or ethereal; and connect plain telnet. Then, set up two computers; set up kerberos; run tcpdump or ethereal; and connect kerberised telnet. I'm waay to lazy to do anything like that so I'll go read the FAQ: in summary, some apps encrypt some don't , ktelnet from MIT does... but krandomapp may not and it isn't guaranteeded, as they say below Unfortunately, relatively few applications support Kerberos to this degree. From http://www.faqs.org/faqs/kerberos-faq/general/ Subject: 1.15. I use software package foo, and it claims it supports Kerberos. What does that mean? Unfortunately, supporting Kerberos can mean a number of things. The most basic level of Kerberos support is verifying a plaintext password against the Kerberos database. Depending on the application, this may or may not be secure. For example, since the Unix xlock application is designed to verify passwords and (hopefully) is only run from on your local workstation, verifying passwords against a Kerberos database is perfectly adequate. However, if you have a POP server that verifies the PASS command by checking the password against a Kerberos database, that is NOT secure, because the password will travel over the network in the clear. There are different levels of password verification, however. Unless a program that does plaintext password verification uses the acquired TGT to get a service ticket for a locally trusted service (that is, with the key in a keytab on local disk), then an attacker can spoof the client with a TGT encrypted in a known password. The next level of Kerberos support is a true Kerberized application that uses Kerberos tickets to verify identity and/or encrypt data. This is the way that Kerberos was designed to function, and it provides the highest level of security that Kerberos has to offer. Unfortunately, relatively few applications support Kerberos to this degree. If you use an application that claims to support Kerberos, you should find out exactly what this means and determine if that is appropriate for your environment. If you use Kerberos primarily as a single-signon system, then having a POP server that verifies plaintext passwords against a Kerberos database may be acceptable to you. All of the Unix replacement commands that come with the MIT Kerberos distributions (telnet, ftp, rlogin, rsh, etc), are true Kerberized applications. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Preventing attacks
Jeff Waugh wrote: Oscar, Ken and I have both explained that it's optional. You could test if you wanted to waste time setting up kerberos, but you could also infer the functionality of the software from the documentation (as Ken has done). I do not have to waste time testing this because I have a kerberos setup at this very moment and I have tested it. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Preventing attacks
O Plameras wrote: I do not have to waste time testing this because I have a kerberos setup at this very moment and I have tested it. lets just hope you haven't wasted time with an actually plaintext version of kerberos, when you could be keeping all those redhat 9 boxes of your with slightly old versions of ssh up to date :) dave -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Preventing attacks
Jeff Waugh wrote: Oscar, you're better off listening and learning that biting the hand that feeds you. A bit arrogant to say others should listen and learn from you and I should keep quiet and drop my point. I'm always learning, what about you ? -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Re: [Fwd: Re: Building kernels [Was: Maybe trying out gentoo again]]
On Fri, 05 Nov 2004 16:46:21 +1100, O Plameras wrote: But I'm not going to allow anyone abusing this list with impunity to tell tall stories without correcting it. List abuse is a issue for SLUG's managing committee or the financial member base to decide on. Free speech is fine, but any irrelevant argument I encourage you to keep to private emails rather than a public, archived, list with a subscriber base of over 700 people. Cheers, Chris -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Code Fest!
When: Saturday, November 27, 10:00am - 10:00pm Where: CSE/UNSW Kensington, Seminar Room Map / Transport: http://slug.org.au/events/cse.html We're holding a Debian RC Bug Squish and general Code Fest. The idea of of the day is to have a social, coding day, learn a few things, close some Debian RC Bugs or just hack the day away on what ever takes your fancy. For those with a punting itch or a taste for bloodsports, we'll be running a book on whether this boast http://lists.slug.org.au/archives/slug/2004/11/msg00231.html will be fulfilled. Get in early for ring side seats. There'll be a 22:00 til late kick-on at a nearby house with plenty of room and net access for those with a need for it. Food and drink will be organised throughout the day and dinner be held afterwards at a venue decided on by the participants. There's also ample on-site parking. See you there! -- Harp not on that string. -- William Shakespeare, Henry VI -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Preventing attacks
quote who=O Plameras Jeff Waugh wrote: Oscar, you're better off listening and learning that biting the hand that feeds you. A bit arrogant to say others should listen and learn from you and I should keep quiet and drop my point. Note that I haven't asked you to keep quiet, Oscar. But there seems to be a few people on the list who are concerned by the inaccurate comments you've made recently, and would like to help to address them, both for yourself and other members of the list. Your sometimes inappropriate pushback makes this process difficult, so you get some rough responses at times... No one's asking you to be quiet, they're asking you to be reasonable and *listen*. - Jeff -- linux.conf.au 2005: Canberra, Australia http://lca2005.linux.org.au/ They cosset us with trappings to shut us up. That way when we say 'sharecropper!' you can point to my free suit and say 'Shut up pop star.' - Courtney Love -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Preventing attacks
Jeff Waugh wrote: quote who=O Plameras Jeff Waugh wrote: Oscar, you're better off listening and learning that biting the hand that feeds you. A bit arrogant to say others should listen and learn from you and I should keep quiet and drop my point. Note that I haven't asked you to keep quiet, Oscar. But there seems to be a few people on the list who are concerned by the inaccurate comments you've made recently, and would like to help to address them, both for yourself and other members of the list. Your sometimes inappropriate pushback makes this process difficult, so you get some rough responses at times... No one's asking you to be quiet, they're asking you to be reasonable and *listen*. That is what you are insinuating that I shut up. In so far as inaccurate comments, I probably did a few but what about you ? -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Preventing attacks
quote who=O Plameras Note that I haven't asked you to keep quiet, Oscar. But there seems to be a few people on the list who are concerned by the inaccurate comments you've made recently, and would like to help to address them, both for yourself and other members of the list. Your sometimes inappropriate pushback makes this process difficult, so you get some rough responses at times... No one's asking you to be quiet, they're asking you to be reasonable and *listen*. That is what you are insinuating that I shut up. You'll see above that I've specifically noted that no one's asking you to shut up. I said it twice, just in case you missed it. In so far as inaccurate comments, I probably did a few but what about you ? Historically, Oscar, heaps - and I've learnt from them. However, no one's pointed out any deep seated misunderstanding that I've communicated on these threads. Again, it's this pushback from you that is concerning. This means you're not listening or learning from *anyone*. - Jeff -- linux.conf.au 2005: Canberra, Australia http://lca2005.linux.org.au/ It's not just a song! It's a document of my life! -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Preventing attacks
On Mon, Nov 08, 2004 at 07:16:01PM +1100, Someone wrote: 2. SSH does not impose time restrictions on a session whilst kerberos does (Prevents replay attacks) From memory, SSH uses some form of challenge/response to set things up, so a replay attack wouldn't be feasible. And it's fascinating stuff. Successful replay attempts are an extreme improbability with SSH, because before anything at all gets sent over the wire, a key exchange* occurs to establish a key for one of the faster (and just as secure) block cipher algorithms like DES or Blowfish (btw, DES and Blowfish are both very similar algorithms. In essence they're both Feistel ciphers. For some reason though, Blowfish is substantially faster in practice, even though at first glance its round function seems more complex). This key will be different on each connection attempt, and is dependent on the entropy pools on *both* ends of the connection. On Linux, entropy pools are quite good these days, and you don't get inferior random data if the kernel figures it can't guarantee randomness -- instead it tells you that the entropy pool is empty. If you don't believe me, try running md5sum /dev/urandom. It'll take a while but it will terminate. [*] a secure key exchange. The one that is traditionally taught in crypto courses is Diffie-Hellman. I don't know if Diffie-Hellman is still used though. The difficulty of breaking Diffie-Hellman is in solving the discrete logarithm problem (which is a pretty hard problem). The problem with Diffie-Hellman is that it's susceptible to man-in-the-middle attacks. SSH gets around this by storing the digital finger-print of servers you connect to. If the finger-print doesn't match when you re-connect, you know something's up (that's what those errors mean that require you to edit .ssh/known_hosts). Sorry, I may have taken this a little off-topic. I find the maths behind it fascinating. I hope I've helped in evaluating the real security of SSH though and haven't provided too much erroneous information. James. -- Now, there are no problems only opportunities. However, this seemed to be an insurmountable opportunity. - http://www.surfare.net/~toolman/temp/diagram.html -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Apache, CSS PHP
I have a CSS file which has to be named *.css so that Apache knows to send it as a text/css mime type but I want to do some PHP processing on before it goes out; unfortunately Apache appears not to know to pass it through the PHP handler as it not named *.php so the embedded PHP code doesn't get processed. I assume I have to do something with Action, AddHandler and SetHandler directives, but just what exactly. -- Howard. LANNet Computing Associates; Your Linux people http://www.lannetlinux.com -- When you just want a system that works, you choose Linux; when you want a system that just works, you choose Microsoft. -- Flatter government, not fatter government; Get rid of the Australian states. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Apache, CSS PHP
I don't know PHP that well but how about naming it .php and set the content-type to text/css from inside PHP? Or how about putting all your .css files under directory css/ (I think it's considered generally a good idea, like concentrating all your images under images/) and telling apache to set text/css for all files under this dir while still the .php suffix tells apache to pass the files through PHP? Just ideas I'd explore if I were you, nothing testted. Cheers, --Amos Howard Lowndes wrote: I have a CSS file which has to be named *.css so that Apache knows to send it as a text/css mime type but I want to do some PHP processing on before it goes out; unfortunately Apache appears not to know to pass it through the PHP handler as it not named *.php so the embedded PHP code doesn't get processed. I assume I have to do something with Action, AddHandler and SetHandler directives, but just what exactly. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Preventing attacks
On Mon, 2004-11-08 at 23:27 +1100, James Gregory wrote: faster (and just as secure) block cipher algorithms like DES or Blowfish Foes anyone know the ciphers that kerberos uses? I was going to ask the person that did cryptography in Uni recently :-) -- Ken Foskey -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Re: Debain stable; MySQL 4.1 backport?
On Mon, 08 Nov 2004 14:25:09 +1000, Jon Austin wrote: Does anyone know if such a beast exists? I need subquery support which is only present (I believe) in 4.1.. By this point in time, you might as well think about upgrading to sarge (the next debian stable). It will go stable soon, so it might be worth considering before going to the effort of compiling from source or using an unknown/trusted backport. Chris. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Security adding another 'user' to a web site.
[EMAIL PROTECTED] wrote: Michael Lake wrote: 4. Other ways ? What's the easist way to allow the new user to use windows scp but not browse the filesystem. Reading up on chroot jails it seems that they are not trivial to setup. How about webmin-updown module, for instance? In general, webmin might allow you to give limited access to certain operations over the web and without giving away shell access at all. Not keen on webmin as were exploits for it when I looked at it last year. Maybe I should look at it again. Another option might be to use a restricting ftp server over ssh. Not familiar with that at all. BTW - I've just learned about winscp - http://winscp.sourceforge.net/eng/, it's so much more friendly than window's command line. Yes that's what I have given to the user that uploads files. Before I used the virtual server the hosting co provided ftp. With the virt server I didnt put on any ftpd and its ssh or scp only for access. I sleep better at night now. Mike -- Michael Lake Chemistry, Materials Forensic Science, UTS Ph: 9514 1725 Fx: 9514 1460 -- UTS CRICOS Provider Code: 00099F DISCLAIMER: This email message and any accompanying attachments may contain confidential information. If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views the University of Technology Sydney. Before opening any attachments, please check them for viruses and defects. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Debain stable; MySQL 4.1 backport?
Chris Deigan wrote: On Mon, 08 Nov 2004 14:25:09 +1000, Jon Austin wrote: Does anyone know if such a beast exists? I need subquery support which is only present (I believe) in 4.1.. By this point in time, you might as well think about upgrading to sarge (the next debian stable). It will go stable soon, so it might be worth considering before going to the effort of compiling from source or using an unknown/trusted backport. What happens with a stable system when testing becomes stable? I have a server with MySQL 3-something and my testing laptop is MySQL 4.1 so I gather that soon, when I do an apt-get update, the stable system will report that that it will upgrade from 3 to 4. I know the mysql tables changed structure from 3 to 4. I presume it will do a conversion seamlessly? Mike -- Michael Lake Chemistry, Materials Forensic Science, UTS Ph: 9514 1725 Fx: 9514 1460 -- UTS CRICOS Provider Code: 00099F DISCLAIMER: This email message and any accompanying attachments may contain confidential information. If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views the University of Technology Sydney. Before opening any attachments, please check them for viruses and defects. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Debain stable; MySQL 4.1 backport?
FWIW, I just ended up using the binary distribution of 4.1 from MySQL. This was replacing a backdated port of 4.0 It used the existing configuration and data fine (from my limited testing). There is a 4.1 debain package in the experimental branch, but I did not have much joy. Regards, Jon On Tue, 09 Nov 2004 10:11:55 +1100, Michael Lake [EMAIL PROTECTED] wrote: Chris Deigan wrote: On Mon, 08 Nov 2004 14:25:09 +1000, Jon Austin wrote: Does anyone know if such a beast exists? I need subquery support which is only present (I believe) in 4.1.. By this point in time, you might as well think about upgrading to sarge (the next debian stable). It will go stable soon, so it might be worth considering before going to the effort of compiling from source or using an unknown/trusted backport. What happens with a stable system when testing becomes stable? I have a server with MySQL 3-something and my testing laptop is MySQL 4.1 so I gather that soon, when I do an apt-get update, the stable system will report that that it will upgrade from 3 to 4. I know the mysql tables changed structure from 3 to 4. I presume it will do a conversion seamlessly? Mike -- Michael Lake Chemistry, Materials Forensic Science, UTS Ph: 9514 1725 Fx: 9514 1460 -- UTS CRICOS Provider Code: 00099F DISCLAIMER: This email message and any accompanying attachments may contain confidential information. If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views the University of Technology Sydney. Before opening any attachments, please check them for viruses and defects. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Remote scp access
On Tue, Nov 09, 2004 at 10:07:20AM +1100, Michael Lake wrote: Michael Lake wrote: 4. Other ways ? What's the easist way to allow the new user to use windows scp but not browse the filesystem. Reading up on chroot jails it seems that they are not trivial to setup. I deleted the previous parts of this thread but this question got me interested; it is not hard to do this with scponly. http://www.sublimation.org/scponly/ I run it inside a separate chroot, although it has its own options to chroot itself. It's not that hard to setup. If you setup a ssh chroot following some vague instructions like http://www.gelato.unsw.edu.au/IA64wiki/DebianSSHChroot you can make each users shell scponly and feel just about as secure as you ever can having a publicly accessible box that allows uploading. -i [EMAIL PROTECTED] http://www.gelato.unsw.edu.au signature.asc Description: Digital signature -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Apache, CSS PHP
On Tue, 2004-11-09 at 10:37, Matthew Palmer wrote:
On Tue, Nov 09, 2004 at 02:30:16AM +1100, Howard Lowndes wrote:
I have a CSS file which has to be named *.css so that Apache knows to
send it as a text/css mime type but I want to do some PHP processing on
before it goes out; unfortunately Apache appears not to know to pass it
through the PHP handler as it not named *.php so the embedded PHP code
doesn't get processed.
I assume I have to do something with Action, AddHandler and SetHandler
directives, but just what exactly.
When I want to add PHP processing to a file type, I just add the file
extension to the AddType application/x-httpd-php line in my httpd.conf. You
could do a similar thing with your .css files, but there's a problem -- I
think, by default, any request that gets passed through PHP ends up with a
content-type of text/html no matter what. Basically, at the time you
delegate responsibility for a file to PHP, Apache says not my problem any
more and lets PHP specify the content type.
So, in your PHPified CSS files, you'll need to run something like
header('Content-Type: text/css'); to specify the content-type of the file.
By the time you do this to all of your CSS files, you're better off (as has
been explained already) putting your dynamic CSS stuff into a .php file,
referencing it in your LINK tags as such, and just telling the file to
announce to the world (via the aforementioned header) that it's a CSS file,
and proud!
I can see what you are saying here, and I have the line in my
head/head block that reads:
link rel=stylesheet type=text/css name=cssname.php/link
which is what I think you are saying but when the file name ends in .php
it seemingly ignores the type statement so I guess PHP must be sending
out different mime type headers, and it looks like I will have to do as
Amos suggests.
- Matt
__
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
--
Howard.
LANNet Computing Associates;
Your Linux people http://www.lannetlinux.com
--
When you just want a system that works, you choose Linux;
when you want a system that just works, you choose Microsoft.
--
Flatter government, not fatter government;
Get rid of the Australian states.
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Re: Remote scp access
Ian Wienand wrote: On Tue, Nov 09, 2004 at 10:07:20AM +1100, Michael Lake wrote: 4. Other ways ? What's the easist way to allow the new user to use windows scp but not browse the filesystem. Reading up on chroot jails it seems that they are not trivial to setup. I deleted the previous parts of this thread but this question got me interested; it is not hard to do this with scponly. http://www.sublimation.org/scponly/ I run it inside a separate chroot, although it has its own options to chroot itself. It's not that hard to setup. If you setup a ssh chroot following some vague instructions like http://www.gelato.unsw.edu.au/IA64wiki/DebianSSHChroot Thanks, I just had a look at scponly and it seems like it's just what I need. Also looked at the summary for chroot jail on debian at gelato. I think the scponly is easiest and simplest and I'll test that out first. Mike -- Michael Lake Chemistry, Materials Forensic Science, UTS Ph: 9514 1725 Fx: 9514 1460 -- UTS CRICOS Provider Code: 00099F DISCLAIMER: This email message and any accompanying attachments may contain confidential information. If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views the University of Technology Sydney. Before opening any attachments, please check them for viruses and defects. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] /etc/dhcpd.conf
Thanks, when I try that I get the message
No subnet declaration for start (0.0.0.0).
Please write a subnet declaration in your dhcpd.conf file for the
network segment to which interface start is attached.
exiting.
and when I try the network calculator it gives a netmask of
255.255.255.24 ...
My /etc/dhcp.conf currently looks like that below; everything else
commented out.
When I write a subnet declaration for 192.168.0.0 and for 192.168.0.1
(server -
presumably the network segment to which interface start is attached) I
get the
message that the two conflict.
Any ideas ?
Adam
[EMAIL PROTECTED]
subnet 192.168.0.0 netmask 255.255.255.252 {
option domain-name paradise.net.nz;
option broadcast-address 192.168.0.1;
option routers 192.168.0.1;
option subnet-mask 255.255.255.224;
range 192.168.0.1 192.168.0.2;
default-lease-time 21600;
max-lease-time 21600;
}
#subnet 192.168.0.1 netmask 255.255.255.24 {
# option domain-name paradise.net.nz;
# option broadcast-address 192.168.0.1;
# option routers 192.168.0.1;
# option subnet-mask 255.255.255.24;
# range 192.168.0.2 192.168.0.2;
# default-lease-time 21600;
# max-lease-time 21600;
#}
host tux
{ fixed-address tux.paradise.net.nz ; }
# The other subnet that shares this physical network
#subnet 192.168.0.1 netmask 255.255.255.224 {
John A. Smith wrote:
Adam,
Your subnet should be 192.168.0.0/255.255.255.252 for one client, with
range 192.168.0.1 192.168.0.2. Change the following lines
subnet 192.168.0.2 netmask 255.255.255.224 {
range 192.168.0.3 192.168.0.10;
Anyone feel free to correct me if wrong. . . This isn't my strong
suit. Also, here's a link to a network calculator
http://www.telusplanet.net/public/sparkman/netcalc.htm
-john smith
- Original Message -
Adam Bogacki wrote:
I can boot from eb*zdsk with CONFIG_PCI_DIRECT but can't find dhcpd,
probably because it is not correctly configured.
I am currently getting the error message
Address range 192.168.0.3 to 192.168.0.10 not on net
192.168.0.2/255.255.255.224!
exiting.
My current /etc/dhcpd.conf file is below. The server is 192.168.0.1 and
the client is 192.168.0.2 What am I missing here ?
Adam Bogacki.
[EMAIL PROTECTED]
option domain-name paradise.net.nz;
option domain-name-servers tux.paradise.net.nz;
option subnet-mask 255.255.255.224;
default-lease-time 21600;
max-lease-time 21600;
subnet 192.168.0.2 netmask 255.255.255.224 {
range 192.168.0.3 192.168.0.10;
# option broadcast-address 204.254.239.31;
# option routers prelude.fugue.com;
#}
# The other subnet that shares this physical network
#subnet 192.168.0.1 netmask 255.255.255.224 {
# range dynamic-bootp 204.254.239.10 204.254.239.20;
# option broadcast-address 204.254.239.31;
# option routers snarg.fugue.com;
#subnet 192.168.0.2 netmask 255.255.255.224 {
# range 192.5.5.26 192.5.5.30;
# option name-servers bb.home.vix.com, gw.home.vix.com;
option domain-name paradise.net.nz;
option routers 192.168.0.1;
option subnet-mask 255.255.255.224;
option broadcast-address 192.168.0.1;
range 192.168.0.3 192.168.0.10;
default-lease-time 600;
max-lease-time 7200;
#}
---
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click
_
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net
-=-=-=-=-=-=-=-=-=-=-=-
John A. Smith
Director of Administration
Breakthrough Urban Ministries
5243 N. Ashland Ave.
Chicago, IL 60640-2001
PH: 773.989.4382, x230
FAX: 773.989.7329
http://www.breakthroughministries.com
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Re: /etc/dhcpd.conf
On Tue, Nov 09, 2004 at 02:20:03PM +1300, Adam Bogacki wrote:
My /etc/dhcp.conf currently looks like that below; everything else
commented out.
When I write a subnet declaration for 192.168.0.0 and for 192.168.0.1
(server -
presumably the network segment to which interface start is attached) I
get the
message that the two conflict.
Any ideas ?
Adam
[EMAIL PROTECTED]
subnet 192.168.0.0 netmask 255.255.255.252 {
option domain-name paradise.net.nz;
option broadcast-address 192.168.0.1;
option routers 192.168.0.1;
option subnet-mask 255.255.255.224;
range 192.168.0.1 192.168.0.2;
default-lease-time 21600;
max-lease-time 21600;
}
#subnet 192.168.0.1 netmask 255.255.255.24 {
Whoa! The specification should be 'subnet network address netmask
mask'. First rule: network addresses always end in even numbers.
I think you need to redescribe your problem, because I'm getting a bit of a
mixed messsage from the random-quoted stuff at the bottom of your message.
- Matt
signature.asc
Description: Digital signature
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Remote scp access
On Tue, Nov 09, 2004 at 11:11:08AM +1100, Michael Lake wrote: Thanks, I just had a look at scponly and it seems like it's just what I need. Also looked at the summary for chroot jail on debian at gelato. I think the scponly is easiest and simplest and I'll test that out first. Just for completeness you might look at http://rssh.sourceforge.net/ and while you're at it, perhaps log everything as well: http://sftplogging.sourceforge.net/ Matt -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Re: [linux-elitists] heidelberg
Jeff Waugh wrote: quote who=Mike MacCana Jeff, I'm a little dissappointed: I was hoping to chat with a cool guy who does interesting stuff you about the similar major attributes of the distributions blah blah passive aggressive blah blah Actually I was being serious. And trying to be pleasant. Just cause the other guy wants to have an argument with you doesn't mean I do. If I was being aggressive, I'd be more of the active kind. Be nice. I am. :^) rather than get into a pissing contest about how many disks are required. Where pissing contest for you and Matt may mean ignore point, repeat. I pointed out a point of difference (which didn't seem to be understood). I understand your wanting to have the packages for a server install that's not minimal on the first disc, I have responded with the fact that not filling the first disc allows RH to add errata and drivers to the install program, which is useful. Some people want a lot of software on CD. That way they can carry it round with them (personally I think the world needs DVD burners). But when updates come out, they don't want their however many ISOS to suddenly become useless. Ubuntu doesn't do CD re-releases (so far), and if we did, it'd still be... one CD. *da-da*! :-) Great. My mate doesn't have a fast ADSL connection. Does it have a multi CD version I can download and pass to him? If so, do you think, three years down the track on the same stable release, it's be nice if he could use most of those CDs to do another install and still be relatively up to date, out of the box, with errata and updated drivers for all the storage devices he's likely to use? Mike -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: [linux-elitists] heidelberg
quote who=Mike MacCana Great. My mate doesn't have a fast ADSL connection. Does it have a multi CD version I can download and pass to him? The single CD is the full desktop install - other stuff you'll need on the average desktop is minimal at best. There's a new release every six months, and each release is supported for 18 months (at the minimum). - Jeff -- linux.conf.au 2005: Canberra, Australia http://lca2005.linux.org.au/ Building Kernel is a requirement for Securing Servers. - Oscar Plameras -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: [linux-elitists] heidelberg
This one time, at band camp, Jeff Waugh wrote: quote who=Jeff Waugh quote who=Mike MacCana Great. My mate doesn't have a fast ADSL connection. Does it have a multi CD version I can download and pass to him? The single CD is the full desktop install - other stuff you'll need on the average desktop is minimal at best. There's a new release every six months, and each release is supported for 18 months (at the minimum). Somehow Mike managed to mail the wrong mailing list... Don't worry, everyone else has already left. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Re: [SLUG-ANNOUNCE] Code Fest!
On Mon, Nov 08, 2004 at 10:11:40PM +1100, Craige McWhirter wrote: When: Saturday, November 27, 10:00am - 10:00pm Where: CSE/UNSW Kensington, Seminar Room Map / Transport: http://slug.org.au/events/cse.html We're holding a Debian RC Bug Squish and general Code Fest. The idea of of the day is to have a social, coding day, learn a few things, close some Debian RC Bugs or just hack the day away on what ever takes your fancy. For those with a punting itch or a taste for bloodsports, we'll be running a book on whether this boast http://lists.slug.org.au/archives/slug/2004/11/msg00231.html will be fulfilled. Get in early for ring side seats. There'll be a 22:00 til late kick-on at a nearby house with plenty of room and net access for those with a need for it. Food and drink will be organised throughout the day and dinner be held afterwards at a venue decided on by the participants. There's also ample on-site parking. Hi Craig, Hi Sluggers, Unfortunately I will be unable to make this worthy event on account of a) not being in Sydney on the day and b) it being my birthday (though that doesn't imply that I don't hack on such occasions). If any one wants to take a look at the small mountain of bugs logged against the various kernel packages then happiness will instantly become Debian users all over the world. You can find (most) of these by looking for bugs logged against [EMAIL PROTECTED] in the BTS. http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maintdata=debian-kernel%40lists.debian.orgarchive=no 2.4.27 and 2.6.8 are both slated for inclusion with Sarge, so please focus on them. 2.4.26 and 2.6.7 are _old_ and no longer maintained and should be removed from d.o before Sarge. Bugs against those kernels should either be closed or moved to 2.4.27 or 2.6.8 respectively. 2.6.9 is _new_ and at this stage there are no plans to include this in Sarge, however bugs in 2.6.9 usually effect 2.6.8 as well, so backports are welcome. In particular if people happen to have the particular hardware that a bug is logged against and are able to test out patches from the BTS or elsewhere this would be imensely useful. If you log any discoveries/fixes/whatever in the BTS, send them to [EMAIL PROTECTED] (BTS messages go to this list anyway), or for the somewhat bashful send them to me directly, I will try and make sure your contributions get included, and more importantly help more people to be able to use debian on more systems. Hooray! -- Horms [EMAIL PROTECTED] / [EMAIL PROTECTED] Debian Kernel Team Member, amongst other things -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Preventing attacks
Ken Foskey wrote: On Mon, 2004-11-08 at 23:27 +1100, James Gregory wrote: faster (and just as secure) block cipher algorithms like DES or Blowfish Foes anyone know the ciphers that kerberos uses? I was going to ask the person that did cryptography in Uni recently :-) i suppose its a good engough reason to break out the Applied Cryptography Book i havent even loked at in oh, 3 years. i had a look for the protocol data, the RFC is woeful but extreme, and complete ... http://www.faqs.org/rfcs/rfc1510.html http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html http://www.nata2.info/misc/Wireless/A_Real-World_Analysis_of_Kerberos_Password_Security-MIRROR.html Kerberos uses DES, but the encryption method can be negotiated in versions v4. DES is still used in a lot of operational cryptographic applications,and it is 'relatively' secure, in that it would hopefully take a p4 a few hours to brute force... more likely in minutes. Which is why DES has been phased out for at least 5 years, replaced by AES in secure applications. The major thing is, in Krb v5, you can specify the salt, the algorithm and a few other variables to make the TGS/KDC give out more secure keys if you have a need for it. it depends on your KDC, the machine you get your ticket from, so its not something easily modified unless you can replace a working Kerberos system. Suffice to say, Krb is relatively secure for a large scale network. more secure methods are available now, but they all have their inconvenient security-based provisions and features that will make client adoption difficult. there's always the addition of biometric data and variable challenge authentication methods, etc. but its still relying on making the process visibly painful as a reminder of the need for security, etc. Toliman -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Alpen-Antique recruitment (Australian job opportunities)
Dear Mr/Mrs, Alpen-Antique GmbH was founded in 1896 year and since that time our company successfully participated in antique items distribution all over the Central Europe. After opening our website our goods became subject of new customers? interest from all over the world, especially from Australia and New Zealand. We started new campaign selling our goods on-line, but we faced new difficulties connected with payment delivery delays to our account, because of international wire transfers usual 5 business days delay. A decision was made to hire sales representatives capable to receiving payments from the same area where are the customers located. At this moment we run sales representatives hiring campaign and are glad to propose you this position. You?re welcome to be our representative. Please visit our webpage www.alpenantique.com/partner.htm describing all aspects of this opportunity and if you?re interested - please send us an email to [EMAIL PROTECTED] and you will be sent an application form. If you have any additional questions - don?t hesitate to contact us at [EMAIL PROTECTED] and we?ll try to help you for sure. Best regards, Karl Schallmeiner, Alpen-Antique GmbH [EMAIL PROTECTED] -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Writing Mozilla extensions to handle a MIME type
Hi guys, If any of you have experience writing Mozilla extensions (XUL/JavaScript/XBL/XPCOM and all that), I'd be grateful for a bit of help -- I'm wondering if it's possible write an extension which can be registered as the main way to interpret a particular MIME type downloaded from a web server. An example scenario: say I have a new MIME type, text/x-rot13-html, (with an extension of .htmlr13 or something). What I'd like is to be able to write a Mozilla extension whose, say, JavaScript gets triggered when the browser detects that particular MIME type, and perhaps the JavaScript can un-rot13 the HTML and display it to the screen. It's very much similar to a classic Netscape plugin in that the extension is designed to work on particular MIME types, except that I really don't want to dive into writing native-code in C or C++, since it's orders of magnitude harder than it needs to be. Does anyone know if this is possible to do with a Mozilla extension? All the research I've done so far looks like I'll have to go the native-code route with a proper plugin, rather than a lightweight extension. -- % Andre Pang : trust.in.love.to.save -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Remote scp access
[EMAIL PROTECTED] wrote: On Tue, Nov 09, 2004 at 11:11:08AM +1100, Michael Lake wrote: Thanks, I just had a look at scponly and it seems like it's just what I need. Also looked at the summary for chroot jail on debian at gelato. I think the scponly is easiest and simplest and I'll test that out first. Just for completeness you might look at http://rssh.sourceforge.net/ I had a look at rssh. Apparently it does not handle WinSCP. To get a GUI win client for rssh the above site suggests using FileZilla which I have downloaded and will try. Also one problem with scponly is that to use the chroot features you have to make it suid and the authors warns of this. Mike -- Michael Lake Chemistry, Materials Forensic Science, UTS Ph: 9514 1725 Fx: 9514 1460 -- UTS CRICOS Provider Code: 00099F DISCLAIMER: This email message and any accompanying attachments may contain confidential information. If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views the University of Technology Sydney. Before opening any attachments, please check them for viruses and defects. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Preventing attacks
On Tue, Nov 09, 2004 at 03:31:50PM +1100, Toliman wrote: and it is 'relatively' secure, in that it would hopefully take a p4 a few hours to brute force... more likely in minutes. How long is 'a few hours'? I didn't think things were that dire. Are you talking about a straight brute force or some kind of known-plaintext attack or what? James. -- Now, there are no problems only opportunities. However, this seemed to be an insurmountable opportunity. - http://www.surfare.net/~toolman/temp/diagram.html -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Preventing attacks
i think a few hours is a stretch (on a p4 in any event) http://www.cryptography.com/resources/whitepapers/DES.html high end gear ... not really, but purpose built and using inadequacies in the standard to optimize the cryptanalysis routine regards, brett On Tuesday 09 November 2004 14:25, James Gregory wrote: On Tue, Nov 09, 2004 at 03:31:50PM +1100, Toliman wrote: and it is 'relatively' secure, in that it would hopefully take a p4 a few hours to brute force... more likely in minutes. How long is 'a few hours'? I didn't think things were that dire. Are you talking about a straight brute force or some kind of known-plaintext attack or what? James. -- Now, there are no problems only opportunities. However, this seemed to be an insurmountable opportunity. - http://www.surfare.net/~toolman/temp/diagram.html -- Brett Fenton NetRegistry Pty Ltd ___ http://www.netregistry.com.au/ Tel: +61 2 96996099 | Fax: +61 2 96996088 PO Box 270 Broadway | NSW 2007, Australia Your Total Internet Business Services Provider Trusted by 10,000s of Oz Businesses Since 1997 -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Preventing attacks
Ken Foskey wrote: On Mon, 2004-11-08 at 23:27 +1100, James Gregory wrote: faster (and just as secure) block cipher algorithms like DES or Blowfish Foes anyone know the ciphers that kerberos uses? I was going to ask the person that did cryptography in Uni recently :-) Triple DES, chances are. Mike -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Writing Mozilla extensions to handle a MIME type
André Pang wrote: If any of you have experience writing Mozilla extensions (XUL/JavaScript/XBL/XPCOM and all that), I'd be grateful for a bit of help -- Interestingly I was just reading this at lunchtime: http://extensions.roachfiend.com/howto.php What I wanted to do was to hook into the save-as and automatically replace all the blank spaces in a filename with say underscores. I get sick of having to replace the spaces manually before I save the pages. An extension for that would be small and useful to me. Mike -- Mike Lake Caver, Linux enthusiast and interested in anything technical. -- UTS CRICOS Provider Code: 00099F DISCLAIMER: This email message and any accompanying attachments may contain confidential information. If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views the University of Technology Sydney. Before opening any attachments, please check them for viruses and defects. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] OpenSkills social evening
There will be an OpenSkills social evening at the James Squire Brewhouse tomorrow (Wednesday 10th) evening at 20:00. http://www.malt-shovel.com.au/brewhouse.asp?Sydney=true People (and wireless Internet access) will be there quite a bit earlier as we'll be having some more formal meetings 20:00 (a ctte meeting and an SGM). Anyway, if you'd like to find out more about OpenSkills and perhaps have a look at the systems available for members, and ones in the works too, please come along. Please also come along if you just want to chat about making a living as a skilled individual in the IT industry. I hope to see you there. All the best, Bruce -- Make the most of your skills - with OpenSkills http://www.openskills.com signature.asc Description: This is a digitally signed message part -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Remote scp access
On Tue, Nov 09, 2004 at 04:13:11PM +1100, Michael Lake wrote: Also one problem with scponly is that to use the chroot features you have to make it suid and the authors warns of this. Which is why I installed it in a separate ssh chroot; but I have the luxury of having full access and carte-blanche control over what I do to the box. FWIW, I've even done some hacking on it and I didn't see anything that raised my alarm bells, and with a known, generally trusted user base (like people you work with) I'd be happy to run it suid. If you trust your users enough that you'd give them shell access if they asked, but are limiting them to scp more to protect themselves, you'd probably be fine running it with it's internal chroot too. If you're giving out a key to anyone who asks, wrap up ssh in an extra chroot to be sure. As has been mentioned far too often in the last few days, security is not a one-fits-all solution. -i signature.asc Description: Digital signature -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Re: Preventing attacks
On Tue, Nov 09, 2004 at 02:25:22PM +1100, James Gregory wrote: On Tue, Nov 09, 2004 at 03:31:50PM +1100, Toliman wrote: and it is 'relatively' secure, in that it would hopefully take a p4 a few hours to brute force... more likely in minutes. How long is 'a few hours'? I didn't think things were that dire. Are you talking about a straight brute force or some kind of known-plaintext attack or what? Isn't the kerberos ticket only valid for a few minutes anyway? So 1 hour, few hours ... doesn't matter at the moment. Matt -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
