Re: Unidentified subject!
Subject: Unidentified subject! why listprocessor does not reject these mails (mails without body)? An even more so, mails without a subject. I do not think we really need those ant more than bodyless mails, do we? Listmaster: is this feasible? -- --- | Juha Jykk, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wdm security
I would not trash wdm just yet. Let me take a look. If you're concerned, you might want to firewall that port using ipchains or iptables. No problem - I am currently behind an ipchains firewall, but it's about to change and I just wanted to know if something breaks if I ipchain/table the port off the network or if it's secure enough to remain - or even if it (the listener, not whole wdm) can be turned off without breaking anything. You take your time looking into it and I'll see what you come up with. Thanks. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
lcap CAP_SYS_MODULE CAP_SYS_RAWIO which will disable module loading entirely as well as access to /dev/mem (which can be just as dangerous as a kernel module and would bypass your signed module thing nicely). Which means: so long, X. I have a workstation and using X in, naturally, necessary (in fact, it is paramount since 3D rendering without Xfree4's opengl is horrible). Thus this option is out. How about compiling the kernel without module support in the first place? The problem of /dev/mem would remain, but if the kernel does not know about modules, is it a problem? -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
aargh... I am being asked to change to SuSE
(off topic) Anyone care to help me: I need some _strong_ points in favour of Debian, against SuSE. No crap, please. I need to presuade my superiors to turn from RH to Debian instead of SuSE as they would like to do. I need strong evidence in favour of Debian if I am to succeed in enforcing it. I do not know SuSE myself, so I cannot fight them (they do not know Debian, but they are the ones who decide - they do not need to) alone. I only care for security/administrability issues now. Thanks for enduring me. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
non-US security fixes URL
What might be the URL/apt-get sources.list line for security fixes of the non-US packages? -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-US security fixes URL
deb http://security.debian.org/debian-security potato/updates main contrib non- free deb http://security.debian.org/debian-non-US potato/non-US main contrib non-fre e deb http://security.debian.org potato/updates main contrib non-free Someone administering the www.debian.org security pages might want to add that non-US security fix URL to the pages. Currently it is not mentioned there. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
strange AIDE reports
I keep receiving strange reports from AIDE. The number of changed files increases monotonically daily and the affair started immediately after installation, so I doubt there has been a break-in - unless someone managed to spoof my DNS queries or hijack my connections to ftp.fi.debian.org. Aside from the understandable (are they, really?) changes in Ctimes of /dev/xconsole and /dev/tty*, I get the following (for example): File: /usr/bin/splay MD5: old = nuNALnPFG98QSxxAeJ2rZw== , new = hBi7I+KhEOWW5mfSciXJlg== SHA1: old = 3lpox5dX50hvj3p6z0nyZ/cshFg= , new = mFPQd21+i8fF2LQJVZLitJZFx2U= File: /usr/lib/Amaya/applis/bin/amaya MD5: old = IQwcW65xdJIoC3/pAh6P8A== , new = 2HG/njXLRrF1GTp7Rd3EVw== The software versions are (all are unstable/i386): Package: aide Version: 0.7-10 Package: splay Version: 0.9.5.1-3 Package: amaya Version: 5.1-1 Any ideas except a break-in? -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: strange AIDE reports
Any ideas except a break-in? Well - you say you're using unstable. Are you updating your system? There are a lot of changes in unstable. After a package replacement, binary files will of course have changed. Of course, but every time I run apt, I run aide --update, too, and move the aide.db.new to aide.db. Besides this started right after installation - before installing anything new. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: strange AIDE reports
Of course, but every time I run apt, I run aide --update, too, and move the aide.db.new to aide.db. Besides this started right after installation - before installing anything new. Silly to reply to myself, but I had a series of strange crashes: kswapd went defunct and after that pretty much nothing worked, as might be guessed, including 'shutdown -r now'. Did not have SysRQ build into kernel... So, I presumed that these might have something to do with my setting some drive parameters with hdparm (my drive insists on starting up in pio4 mode though both the chipset and the drive can do udma2 - seagate claims the drive can do udma4, but I now doubt it since IBM claims its ata100-drives can do only udma4 and this old drive certainly is not ata100). So, I reduced my drive setting to udma2. This stopped the crashes, but did not help aide: I run, sequentially: aide --init mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db aide --check and got: Changed files: changed:/usr/bin/ddd changed:/usr/sbin changed:/usr/lib changed:/usr/lib/netscape/477/communicator/communicator-smotif.real changed:/usr/lib/librecode.so.0.0.0 changed:/usr/lib/mozilla/components/libgkcontent.so changed:/usr/lib/mozilla/components/libmsgimap.so I guarantee, mozilla was not running, netscape was not running and lsof (right after aide --check) did not report librecode.so.0.0.0 as open. I would be worried if aide reported some sensitive files (ddd or /usr/sbin could be regarded sensitive) as changed, but these files seem totally random! After this, I reran 'aide --check' and got a segfault. Repeat as many times as I would, all get segfaulted... Aide broken? Aide version is sid's: 0.7-10. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
the slrn-0.9.6.2 -hole
Does anyone happen to know which versions are vulnerable besides the one DSA mentioned? I have a woody which would need slrn removed if woody's newest version (that is, 0.9.7.2-4) is vulnerable. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
central administration techniques
I was wondering if there are any secure methods of centrally managing the versions of certain files on Debian machines. I currently have a woody, two sids and several potatos which need to be kept up to date. The security patches are not much of a concern since they are quite infrequent (except for woody and sid where I do not discriminate between security, bug and other fixes) but certain configuration files change often, like the files /etc/ssh/ssh_known_hosts*. Every time a new host is added into the network, I need to add its host key into the others' known_hosts and copy the all default configuration files into the new host as well. There are quite a few of these that are easily forgotten. Forgetting to copy some files like /etc/printcap is soon noticed and fixed, no harm done, but files like /etc/pam.d/* are not. And results in decreased security! I am now considering different possibilities of doing these updates by simply saying update-debian-machines on one of the computers. It would require some shell scripts and asking the relevant passwords it would keep me waiting at my console. I do circumvent the login passwords with ssh/DSA auth, but resenting root logins over the net, I would still need to type sudo's passwords. Now, is there a package to do this or which could be easily converted to do this? Otherwise I will fall back to scripting. In that case, which is the safest option? Currently I am considering configuring sudo to enable the admin user to execute a single script (mods 0700) without a password or just chmod that script 4700. I am not certain about the first, but the latter would be as secure as my connection (ssh2) and my real password. The real password being broken would mean unlimited access to sudo (it is the admin, after all) so I am not worried by that part. Also, the ssh connection part worries me a little: I would basically be giving root access to all our machines to anyone who can steal/spoof/abuse my ssh private key. I can think of three scenarios to compromise the network: 1. To break into my admin console, so as to get my DSA private key (mod 0600) and break its passphrase. 2. To break into my admin machine (Getting on any machine would not do - the DSA key only exists on one, so the cracker would need to break into my admin console.) and steal my DSA key while it is being used. Ssh-agent keeps the key (or does it keep the passphrase? in this case it does not matter) in memory so this should be possible at least for root on a machine with /dev/mem. 3. Break into one of the other machines, use the suided script to trojan the system and propagate to the other machines that way. The last one might prove difficult: the admin user on non-admin-console machines does not have any DSA keys used for password-less authentication - so this basically means breaking into a single machine which I am not concerned of here. Breaking into a single machine should be about equally difficult for all machines, since I doubt my little scheme would be the weakest link in security. The only problem I can see is in 1. and 2. - could the DSA key be abused to automatically root all the machines? Ideas? -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: central administration techniques
3. Break into one of the other machines, use the suided script to ^ I can't answer your questions - I know too little. Just one remark: AFAIK, Linux doesn't support suided shell scripts. At least it didn't do that a few years ago when I tried to use a suided script. I haven't - use C-code. Does not matter. I can code buffer overflow -proof routines for this simple stuff. Or just code a suid binary which runs the script and does nothing else.. An additional security hole there, though: I basically would have TWO suided programs now though crashing a program which only runs another should be impossible (unless the init routines can be crashed). -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: central administration techniques
changes via cvs to a nfs mount, all the client machines download changes via a cron job. Whoooa... nfs? Security++... I could consider using some secure networked file system, though but I doubt cron would be a good idea. Or maybe it is. Anyone any concerns? Another thing that crossed my mind: a local apt-repository. I could put my config files in machine-specific .deb's and even wget all the fixes there plus clean the old ones. Then just run apt-get to install them... There is a slight concern, though: our network is a shared coaxial net... (10Base-2) -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question about something, but don't know if it exists...
anything else than just clear autentification. So is there a software which connets onto server (for example proxy) through SSL and then redirect data channels onto right ports as an clear connection outside (I cannot solve the situation on provider routers of course, but it has Do you have access to the router/switch/firewall at your end? You might want to consider your internal network not trusted since people are stealing passwords. The easiest solution that comes to my mind is IPSec: make your firewall (or what ever) an IPSec gateway and run everything inside your network over IPSec. No more stealing, I would think. There may be other options as well, but that would end all kinds of network sniffing inside your network. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question about something, but don't know if it exists...
mind is IPSec: make your firewall (or what ever) an IPSec gateway and run everything inside your network over IPSec. No more stealing, I would think. Hmmm... I am afraid it isn't possible, because there are W95 workstations. Or is there anything to support this which is reasonably simple and will rewrite windows sockets into that kind of Try some commercial IPSec implementation. F-Secure at least has one. Probably others as well. The standard is platform independent, so W95, WNT, W2k, linux, anything should work fine together. Avoid MS implementation, how ever, it used to be incompatible (surprise?). I do not know if it still is. There are even commercial IPSec-gateway switches available at least from Cisco - if you do not want to use linux as firewall/gateway/what ever. Just put everything under IPSec and that's it. Of course, there is a problem if your computers are not very fast - IPSec encrypts absolutely everything so it really takes some CPU. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: MTAs
I don't know much about exim's guts, but is there a point in starting it as mail if it's SUID root? -rwsr-xr-x1 root root 466308 sie 15 01:13 /usr/sbin/exim There is a small point of binding to port 25. Only root can do that. I have not looked at exim's code, but if run as a stand-alone daemon (i.e. not from inetd), I would guess it just opens the port as root and drops the priviledges right away. Someone who knows the code might want to confirm/rebuke this. On the other hand, if exim is run from inetd (as I do), does it still need to be suid root? Since inetd runs root anyway, there should be no need for exim to: the port is already bound when exim starts and exim will not be able to bind to it anyway. Just wondering if I should do some dpkg-statoverrides. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: MTAs
On the other hand, if exim is run from inetd (as I do), does it still need to be suid root? Since inetd runs root anyway, there should well this is not a problem. (x)inet works by using stdin/stdout rather than network ports. This is why you have to tell whatever service you are superserving its being run from (x)inet. Hence you do not need to have root privilages as no ports are being opened, even if they were there would be an error as the os says sorry port already claimed or words to that effect. Please quote only the relevant part of the message you reply to. I do not know which part of my message you replied to since you quoted it all. There was only one question, though and I left that double quoted. Assuming you replied to this part, what do you mean by it being no problem? Exim running as root is no problem? Of course it is if it is not necessary to run! Programs should never (or at least as infrequently as possible) have extra priviledges. And even though inetd may be invulnerable to some exploit, exim may still be. Running exim from inetd does not prevent exploits from being exploited. The only things I can see we gain from using inetd are 1) there is only one daemon running (less memory consumed) and 2) only inetd _needs_ setuid root. If the communication between exim and inetd works fine without exim being suid root, then it should be possible to remove the bit from exim. Now my original question was: does it (exim) still need to be suid root? And the question still remains and depends (solely?) on whether it still can communicate with inetd. Inetd runs exim with mail's priviledges so giving mail access to any necessary directories is enough for exim to function - unless there are issues with the permissions of /var/spool/mail/insert your favourite username here. Now another question: are there? -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
openssh version numbers...
Ok. I have the good old open ssh 2.3.0-something. Now http://openssh.org/security.html says it is not vulnerable to cookie deletion or source based access control vulnerabilities (only 2.5.x-2.9.x, excluding 2.9.9, are). This is fine as long as I try to get woody's open ssh, which is 2.9psomething. Where does this version number fall in openssh's version numbering scheme? Between 2.8.(what ever was the biggest number here) and 2.9.0 or where? The answer to whether it is vulnerable or not might be enough but I am so confused about open ssh's version numbers: why do they change the whole _format_ of their version numbers??? 2.9 is lacking one minor version specifier as compared to 2.9.9, which has two. TIA. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
lprng
Nessus claims all versions of lprng prior to 3.6.24 has some unnamed flaw which allows exploiting the daemon's priviledges. As a debian lprng runs as daemon, it is not as dangerous as nessus claims (root compromise), at least directly. How ever, I cannot find any references to any vulnerabilities in lprng, except one in January 2000 in security.debian.org! Since potato has lprng 3.6.12 it would be nice to know if there is a vulnerability or not. Anyone and ideas? I know nessus gives a lot of false positives, such as claiming my mail server is an open relay when testing it from the (firewalled) subnet which it really _IS_ a relay for. Nessus has no way of knowing outiside world cannot use it as a relay; or claiming an up-to-date potato sshd as vulnerable to the CRC32 attack compensator bug since its version number suggests it is vulnerable. Most false positives are easily dismissed by knowing your setup which nessus does not. There are a couple of concering cases, though: This case of lprng: nessus only says it detects an lprng daemon, but NOT that it cannot tell the version number and just states what I describe in the beginning. Another is Trin00. It has this far detected three machines with Trin00. In one of them it most certainly is false since it claims to have found Windows version of Trin00 on an IRIX host... The other two cases, on the other hand give no hint of being falses. Does anyone know how reliable nessus is in detecting Trin00? Does it only check that port X is open, thus we have Trin00 there or does it really send some commands to the supposed Trin00 client/daemon and verify its existence from the reply? If nessus is not realiable, how can I check for it? -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Applications using Linux capabilities
- xntp3 w/patch (just keeps CAP_SYS_TIME, drops uid 0) As far as I can recall, xntp3 was split into ntp and ntpdate somewhere around version 4. I do not see why there is any need for the older version. Besides there used to be a .deb for it. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: Unidentified subject!
Subject: Unidentified subject! why listprocessor does not reject these mails (mails without body)? An even more so, mails without a subject. I do not think we really need those ant more than bodyless mails, do we? Listmaster: is this feasible? -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
wdm security
I am a little concerned about XFree86+wdm keeping a bunch of processes listening on port 32768. (wdm is the windowmaker xdm replacement.) According to lsof -i TCP, there are a number of processes listening on the port. When using X, I accept the obvious port 6000 being open for inbound connections and I believe XFree is secure enough with it (I only allow local logged-in user from localhost to contact to my X server) but what is this wdm doing listening on 32768? nmap says it's an unknown port and /etc/services does not recognise it. IANA seems to recognise the port as filenet-tms 32768/tcp Filenet TMS filenet-tms 32768/udp Filenet TMS but I have no idea what Filenet TMS is. I am a little at a loss with this. Should I trash wdm or what? It's a little sad thing to do since it allows me to choose a window manager at login time, something xdm does not do (at least didn't last time I checked). For what it's worth, my wdm is Version: 1.20-5, from unstable. The newest seems to be 1.20-10, but I am in a habit of upgrading unstable stuff only if there is a problem/security issue. (Because things sometimes break, like alsa-utils was broken last week.) -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: wdm security
I would not trash wdm just yet. Let me take a look. If you're concerned, you might want to firewall that port using ipchains or iptables. No problem - I am currently behind an ipchains firewall, but it's about to change and I just wanted to know if something breaks if I ipchain/table the port off the network or if it's secure enough to remain - or even if it (the listener, not whole wdm) can be turned off without breaking anything. You take your time looking into it and I'll see what you come up with. Thanks. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
RE: wdm security
startx -- -nolisten tcp Obviously this would do the trick, but see below as to why it is not a good option. only as part of the perennially-discussed task-harden. Doesn't even effect remote xsessions, as you should be using ssh to tunnel your sessions anyway. There is no way of ssh tunneling remote x sessions, when my remote terminal is a dummy tektronic x terminal. When in switched internal network (that is, there is a firewall between the switch and the internet), the need to tunnel is minimal - unless my switch and firewall are compromised - if not non-existent. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: hi, any help ? about an evil mysterious crazy Open tcp port ?
how, can i see the tcp port 4350 that states to be opened useing nmap There is _the_ official document of registered ports at http://www.iana.org/assignments/port-numbers and it claims 4350 is Net Device - what ever that means. The entry is created by microsoft so we may assume it is some windows stuff. This does not preclude the possibility of a backdoor/trojan, though: a wise backdoor would listen on a port which would be open anyway thus concealing (partly) its presence. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: A question about Knark and modules
lcap CAP_SYS_MODULE CAP_SYS_RAWIO which will disable module loading entirely as well as access to /dev/mem (which can be just as dangerous as a kernel module and would bypass your signed module thing nicely). Which means: so long, X. I have a workstation and using X in, naturally, necessary (in fact, it is paramount since 3D rendering without Xfree4's opengl is horrible). Thus this option is out. How about compiling the kernel without module support in the first place? The problem of /dev/mem would remain, but if the kernel does not know about modules, is it a problem? -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
shared root account
I have a bit of a situation: I have a handful of linux machines (almost all with different distributions and kernels and software - one hell to keep secure) and all the machines have different roots. These guys want to keep their root passwords (or at least the root privileges) so they can update their X/KDE/whatever when/if they feel like it but on the other hand, they would like to see someone (me) keep their machines secure - something they themselves do not have time (we all know keeping up security is a fulltime job). Obviously to install patches etc I, also, need root privileges. This poses a problem if I am not to remember all those different root passwords and without making all the passwords the same! How can that _safely_ be accomplished? There are versions of su, sudo etc) that do not ask passwords, there are suid binaries but which is _THE_ way of accomplishing this? Presently there are only shared root passwords between the server admins but now we are trying to get the workstation security boosted up as well - being behind one firewall does not seem to be enough in an environment where a whole class B network is behind that one fw... -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: shared root account
(Put the public key in the .authorized_keys file for the root user) TUrn on RSA/DSA authentication and 'allow root login' One word of warning aboce would allow logging in using root password as well I distrust allowing root logins from anywhere but local console(s) or non-modem gettys i.e. from anywhere over the not-owned-by-me cable. Any other ideas? Or is it really safe to allow root logins to sshd? It is just an old rule of thumb that root must never log on over the wire but that may be old news from times of telnet - never had any need of root logins over the wire until perhaps now. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: shared root account
Nice little storm of a chain I managed to start here... Quite off the original topic, mainly, where I trust the users. Many good points have been noted and basically all of them have been argued both pro and con. I will do a little summary here: 1) Some people like sudo, some think it is not secure enough. In my situation, where I am not worried about legitimate users trying to get elevated privileges, this might just work. On the other hand, the point that sudo elevates ordinary users' passwords into root passwords obviously makes it easier for an illegitimate user to gain root - it suffices to gain any sudoer's password and then employing any of the methods mentioned here to gain root with sudo regardless of the permissions allowed to that users by sudo. Solution to that would be expiring passwords and installing some password sanity checker - that way at least the users' passwords ought to be fairly good and new, i.e. hard to crack. Of course if someone cracks user A, who is NOT a sudoer and attempts to sudo, we get log entries and even if A IS a sudoer, but the culprit has simply managed to spawn A's shell and is trying to sudo, we get log entries. No use of sudo's logging, as noted earlier, if the attacker really has the password of a sudoer: logs can be cleaned unless they are a) sent to another, secure, machine or b) they are written to a write-once medium (anyone logging onto paper or CD, for example? - grepping a paper ought to be ... fun?). 2) A few people like ssh RSA-auth. Good idea. But I may (will) need access to these machines in situations when there is no network, i.e. running manual fsck's after a power failure. No way of ssh'ing into the box at that time. I will need the root password anyway. 3) A few people would create additional uid=0 accounts. Since my situation is akin to one with multiple admins trusting each other (more exactly - it's _they_ who are trusting _me_, not the other way around), this might be a good idea. No one would have to get familiar with sudo (I know that would cause some resistance - it would be viewed as something they do not need to get accustomed to) and I would get my root. Of course, sudo would give me nice logs of what the others have done - which is quite important if I am to keep the boxes secure: not knowing what's been changed makes that pretty hard. This is my option number 2 anyway, if people resist learning to type 'sudo' instead of logging in as root or saying 'su'. 4) Someone also noted that having linux workstations in the first place is a bad idea due the X's flawed security but I do not seem to remember any way of popping up windows on someone else's display when X server is properly configured (i.e. only to accept connections from localhost with a proper MIT secret cookie (or other auth mechanism). As I said above, in my situation, sudo is very appealing: keeping root password to myself and letting the workstation users sudo (or vice versa). One question raises however: If I have multiple uid=0 accounts, will any of their passwords suffice as root password when entering single user mode? Obviously sudo will not do here, so I will need a root password, period. The other users will have to make do with either sudo or multiple uid=0 accounts. Multiple uid=0 accounts sounds better in that it does not elevate ordinary passwords into root passwords (of course, in practice people may keep them the same - can that be helped?) but on the other hand, sudo would log... I will have to see how much use of their root accounts these people really make. Although many of the replies did not answer my question at all, some of them had good points, thanks to those. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
aargh... I am being asked to change to SuSE
(off topic) Anyone care to help me: I need some _strong_ points in favour of Debian, against SuSE. No crap, please. I need to presuade my superiors to turn from RH to Debian instead of SuSE as they would like to do. I need strong evidence in favour of Debian if I am to succeed in enforcing it. I do not know SuSE myself, so I cannot fight them (they do not know Debian, but they are the ones who decide - they do not need to) alone. I only care for security/administrability issues now. Thanks for enduring me. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
non-US security fixes URL
What might be the URL/apt-get sources.list line for security fixes of the non-US packages? -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: non-US security fixes URL
deb http://security.debian.org/debian-security potato/updates main contrib non- free deb http://security.debian.org/debian-non-US potato/non-US main contrib non-fre e deb http://security.debian.org potato/updates main contrib non-free Someone administering the www.debian.org security pages might want to add that non-US security fix URL to the pages. Currently it is not mentioned there. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
strange AIDE reports
I keep receiving strange reports from AIDE. The number of changed files increases monotonically daily and the affair started immediately after installation, so I doubt there has been a break-in - unless someone managed to spoof my DNS queries or hijack my connections to ftp.fi.debian.org. Aside from the understandable (are they, really?) changes in Ctimes of /dev/xconsole and /dev/tty*, I get the following (for example): File: /usr/bin/splay MD5: old = nuNALnPFG98QSxxAeJ2rZw== , new = hBi7I+KhEOWW5mfSciXJlg== SHA1: old = 3lpox5dX50hvj3p6z0nyZ/cshFg= , new = mFPQd21+i8fF2LQJVZLitJZFx2U= File: /usr/lib/Amaya/applis/bin/amaya MD5: old = IQwcW65xdJIoC3/pAh6P8A== , new = 2HG/njXLRrF1GTp7Rd3EVw== The software versions are (all are unstable/i386): Package: aide Version: 0.7-10 Package: splay Version: 0.9.5.1-3 Package: amaya Version: 5.1-1 Any ideas except a break-in? -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: strange AIDE reports
Any ideas except a break-in? Well - you say you're using unstable. Are you updating your system? There are a lot of changes in unstable. After a package replacement, binary files will of course have changed. Of course, but every time I run apt, I run aide --update, too, and move the aide.db.new to aide.db. Besides this started right after installation - before installing anything new. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: strange AIDE reports
Of course, but every time I run apt, I run aide --update, too, and move the aide.db.new to aide.db. Besides this started right after installation - before installing anything new. Silly to reply to myself, but I had a series of strange crashes: kswapd went defunct and after that pretty much nothing worked, as might be guessed, including 'shutdown -r now'. Did not have SysRQ build into kernel... So, I presumed that these might have something to do with my setting some drive parameters with hdparm (my drive insists on starting up in pio4 mode though both the chipset and the drive can do udma2 - seagate claims the drive can do udma4, but I now doubt it since IBM claims its ata100-drives can do only udma4 and this old drive certainly is not ata100). So, I reduced my drive setting to udma2. This stopped the crashes, but did not help aide: I run, sequentially: aide --init mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db aide --check and got: Changed files: changed:/usr/bin/ddd changed:/usr/sbin changed:/usr/lib changed:/usr/lib/netscape/477/communicator/communicator-smotif.real changed:/usr/lib/librecode.so.0.0.0 changed:/usr/lib/mozilla/components/libgkcontent.so changed:/usr/lib/mozilla/components/libmsgimap.so I guarantee, mozilla was not running, netscape was not running and lsof (right after aide --check) did not report librecode.so.0.0.0 as open. I would be worried if aide reported some sensitive files (ddd or /usr/sbin could be regarded sensitive) as changed, but these files seem totally random! After this, I reran 'aide --check' and got a segfault. Repeat as many times as I would, all get segfaulted... Aide broken? Aide version is sid's: 0.7-10. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
the slrn-0.9.6.2 -hole
Does anyone happen to know which versions are vulnerable besides the one DSA mentioned? I have a woody which would need slrn removed if woody's newest version (that is, 0.9.7.2-4) is vulnerable. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
central administration techniques
I was wondering if there are any secure methods of centrally managing the versions of certain files on Debian machines. I currently have a woody, two sids and several potatos which need to be kept up to date. The security patches are not much of a concern since they are quite infrequent (except for woody and sid where I do not discriminate between security, bug and other fixes) but certain configuration files change often, like the files /etc/ssh/ssh_known_hosts*. Every time a new host is added into the network, I need to add its host key into the others' known_hosts and copy the all default configuration files into the new host as well. There are quite a few of these that are easily forgotten. Forgetting to copy some files like /etc/printcap is soon noticed and fixed, no harm done, but files like /etc/pam.d/* are not. And results in decreased security! I am now considering different possibilities of doing these updates by simply saying update-debian-machines on one of the computers. It would require some shell scripts and asking the relevant passwords it would keep me waiting at my console. I do circumvent the login passwords with ssh/DSA auth, but resenting root logins over the net, I would still need to type sudo's passwords. Now, is there a package to do this or which could be easily converted to do this? Otherwise I will fall back to scripting. In that case, which is the safest option? Currently I am considering configuring sudo to enable the admin user to execute a single script (mods 0700) without a password or just chmod that script 4700. I am not certain about the first, but the latter would be as secure as my connection (ssh2) and my real password. The real password being broken would mean unlimited access to sudo (it is the admin, after all) so I am not worried by that part. Also, the ssh connection part worries me a little: I would basically be giving root access to all our machines to anyone who can steal/spoof/abuse my ssh private key. I can think of three scenarios to compromise the network: 1. To break into my admin console, so as to get my DSA private key (mod 0600) and break its passphrase. 2. To break into my admin machine (Getting on any machine would not do - the DSA key only exists on one, so the cracker would need to break into my admin console.) and steal my DSA key while it is being used. Ssh-agent keeps the key (or does it keep the passphrase? in this case it does not matter) in memory so this should be possible at least for root on a machine with /dev/mem. 3. Break into one of the other machines, use the suided script to trojan the system and propagate to the other machines that way. The last one might prove difficult: the admin user on non-admin-console machines does not have any DSA keys used for password-less authentication - so this basically means breaking into a single machine which I am not concerned of here. Breaking into a single machine should be about equally difficult for all machines, since I doubt my little scheme would be the weakest link in security. The only problem I can see is in 1. and 2. - could the DSA key be abused to automatically root all the machines? Ideas? -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: central administration techniques
3. Break into one of the other machines, use the suided script to ^ I can't answer your questions - I know too little. Just one remark: AFAIK, Linux doesn't support suided shell scripts. At least it didn't do that a few years ago when I tried to use a suided script. I haven't - use C-code. Does not matter. I can code buffer overflow -proof routines for this simple stuff. Or just code a suid binary which runs the script and does nothing else.. An additional security hole there, though: I basically would have TWO suided programs now though crashing a program which only runs another should be impossible (unless the init routines can be crashed). -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: central administration techniques
changes via cvs to a nfs mount, all the client machines download changes via a cron job. Whoooa... nfs? Security++... I could consider using some secure networked file system, though but I doubt cron would be a good idea. Or maybe it is. Anyone any concerns? Another thing that crossed my mind: a local apt-repository. I could put my config files in machine-specific .deb's and even wget all the fixes there plus clean the old ones. Then just run apt-get to install them... There is a slight concern, though: our network is a shared coaxial net... (10Base-2) -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: question about something, but don't know if it exists...
anything else than just clear autentification. So is there a software which connets onto server (for example proxy) through SSL and then redirect data channels onto right ports as an clear connection outside (I cannot solve the situation on provider routers of course, but it has Do you have access to the router/switch/firewall at your end? You might want to consider your internal network not trusted since people are stealing passwords. The easiest solution that comes to my mind is IPSec: make your firewall (or what ever) an IPSec gateway and run everything inside your network over IPSec. No more stealing, I would think. There may be other options as well, but that would end all kinds of network sniffing inside your network. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: question about something, but don't know if it exists...
mind is IPSec: make your firewall (or what ever) an IPSec gateway and run everything inside your network over IPSec. No more stealing, I would think. Hmmm... I am afraid it isn't possible, because there are W95 workstations. Or is there anything to support this which is reasonably simple and will rewrite windows sockets into that kind of Try some commercial IPSec implementation. F-Secure at least has one. Probably others as well. The standard is platform independent, so W95, WNT, W2k, linux, anything should work fine together. Avoid MS implementation, how ever, it used to be incompatible (surprise?). I do not know if it still is. There are even commercial IPSec-gateway switches available at least from Cisco - if you do not want to use linux as firewall/gateway/what ever. Just put everything under IPSec and that's it. Of course, there is a problem if your computers are not very fast - IPSec encrypts absolutely everything so it really takes some CPU. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: MTAs
I don't know much about exim's guts, but is there a point in starting it as mail if it's SUID root? -rwsr-xr-x1 root root 466308 sie 15 01:13 /usr/sbin/exim There is a small point of binding to port 25. Only root can do that. I have not looked at exim's code, but if run as a stand-alone daemon (i.e. not from inetd), I would guess it just opens the port as root and drops the priviledges right away. Someone who knows the code might want to confirm/rebuke this. On the other hand, if exim is run from inetd (as I do), does it still need to be suid root? Since inetd runs root anyway, there should be no need for exim to: the port is already bound when exim starts and exim will not be able to bind to it anyway. Just wondering if I should do some dpkg-statoverrides. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
Re: MTAs
On the other hand, if exim is run from inetd (as I do), does it still need to be suid root? Since inetd runs root anyway, there should well this is not a problem. (x)inet works by using stdin/stdout rather than network ports. This is why you have to tell whatever service you are superserving its being run from (x)inet. Hence you do not need to have root privilages as no ports are being opened, even if they were there would be an error as the os says sorry port already claimed or words to that effect. Please quote only the relevant part of the message you reply to. I do not know which part of my message you replied to since you quoted it all. There was only one question, though and I left that double quoted. Assuming you replied to this part, what do you mean by it being no problem? Exim running as root is no problem? Of course it is if it is not necessary to run! Programs should never (or at least as infrequently as possible) have extra priviledges. And even though inetd may be invulnerable to some exploit, exim may still be. Running exim from inetd does not prevent exploits from being exploited. The only things I can see we gain from using inetd are 1) there is only one daemon running (less memory consumed) and 2) only inetd _needs_ setuid root. If the communication between exim and inetd works fine without exim being suid root, then it should be possible to remove the bit from exim. Now my original question was: does it (exim) still need to be suid root? And the question still remains and depends (solely?) on whether it still can communicate with inetd. Inetd runs exim with mail's priviledges so giving mail access to any necessary directories is enough for exim to function - unless there are issues with the permissions of /var/spool/mail/insert your favourite username here. Now another question: are there? -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
openssh version numbers...
Ok. I have the good old open ssh 2.3.0-something. Now http://openssh.org/security.html says it is not vulnerable to cookie deletion or source based access control vulnerabilities (only 2.5.x-2.9.x, excluding 2.9.9, are). This is fine as long as I try to get woody's open ssh, which is 2.9psomething. Where does this version number fall in openssh's version numbering scheme? Between 2.8.(what ever was the biggest number here) and 2.9.0 or where? The answer to whether it is vulnerable or not might be enough but I am so confused about open ssh's version numbers: why do they change the whole _format_ of their version numbers??? 2.9 is lacking one minor version specifier as compared to 2.9.9, which has two. TIA. -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
lprng
Nessus claims all versions of lprng prior to 3.6.24 has some unnamed flaw which allows exploiting the daemon's priviledges. As a debian lprng runs as daemon, it is not as dangerous as nessus claims (root compromise), at least directly. How ever, I cannot find any references to any vulnerabilities in lprng, except one in January 2000 in security.debian.org! Since potato has lprng 3.6.12 it would be nice to know if there is a vulnerability or not. Anyone and ideas? I know nessus gives a lot of false positives, such as claiming my mail server is an open relay when testing it from the (firewalled) subnet which it really _IS_ a relay for. Nessus has no way of knowing outiside world cannot use it as a relay; or claiming an up-to-date potato sshd as vulnerable to the CRC32 attack compensator bug since its version number suggests it is vulnerable. Most false positives are easily dismissed by knowing your setup which nessus does not. There are a couple of concering cases, though: This case of lprng: nessus only says it detects an lprng daemon, but NOT that it cannot tell the version number and just states what I describe in the beginning. Another is Trin00. It has this far detected three machines with Trin00. In one of them it most certainly is false since it claims to have found Windows version of Trin00 on an IRIX host... The other two cases, on the other hand give no hint of being falses. Does anyone know how reliable nessus is in detecting Trin00? Does it only check that port X is open, thus we have Trin00 there or does it really send some commands to the supposed Trin00 client/daemon and verify its existence from the reply? If nessus is not realiable, how can I check for it? -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | ---
/usr/lib/libkssl.so.2.0.2
I am wondering... what would be the correct md5sum of the above file? In three machines I get twice the value 4b68a1146dfd0e326c4396e339abc750 and once the value cd59e38dfd54eca39a99094fd85a1af0. This seems quite suspicious to me, especially since I JUST INSTALLED the kdelibs3-packages to all three machines, using ftp.fi.debian.org-mirror. How is this possible? -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- pgpsOXwBLhlEz.pgp Description: PGP signature
Re: /usr/lib/libkssl.so.2.0.2
Are these machines all the same architechture and running the same release? Naturally, yes. All run debian/woody and I even scp'ed the .deb around and installed the package with dpkg by hand - still I get different md5sums! 4b68a1146dfd0e326c4396e339abc750 /usr/lib/libkssl.so.2.0.2 It's 3-1 for 4b... then. :) -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- pgpDwRPo0d5XI.pgp Description: PGP signature
sshd, pam and expired passwords
It seems I have managed to hit the ages-old problem of not being able to enforce changing of expired passwords when logging in via ssh. This problem existed years ago in potato but I cannot seem to find any mention of its existence or non-existence in woody. What is the situation at the moment? Is there a way to enforce changing of expired passwords via ssh which uses PAM to authenticate itself? If it is possible, which I very much require to reduce my workload and the frustration of the users, wich configuration items are relevant in sshd_config, /etc/pam.d/(passwd|login|sshd)? Are there any other relevant configuration items? -- --- | Juha Jäykkä, [EMAIL PROTECTED], Assistant | | Laboratory of Theoretical Physics | | Department of Physics, University of Turku| | home: http://www.utu.fi/~juolja/ | --- pgpqGp34i15wK.pgp Description: PGP signature
DSA-1571 and GSSAPI
Hi all! I was wondering how bad this actually is and it looks extremely horrible. In practice, all data transmitter over the wire for the last two years and be snooped upon (if someone has captured it - and the paranoid must assume someone has). Trusting on the security of ssh, we have, for example, used ssh to transmit data from server to server, including such sensitive information as Heimdal database master key... Am I correct in assuming this key has been compromised? And along with it all the Heimdal passwords... However, ever since we started using Heimdal, we have used GSSAPI authentication by default, which, to my understanding, does not rely on SSH host or user keys, but bases all its crypto on Kerberos. Does this mean data transmitted over GSSAPI-authenticated links is still secure? (Not that it matters much - there is no way of making sure the default (GSSAPI) was *always* used when transmitting sensitive data. By the way, if (since?) all the data ever transmitted over any ssh link secured by a weak key is compromised, it means that every single GPG passphrase (or any other password) ever transmitted over any of these links is also compromised. Just count how many times you've used GPG over one of the weak links... Cheers (looks like a cheerful weekend to come indeed)... Juha -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-1571 and GSSAPI
yet confirmed whether that includes using it for the generation of random session keys, but that would be the conservative assumption. Given that, Has this been investigated further by you or anyone else? Or should I bother the heimdal guys about this? -Juha -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- signature.asc Description: This is a digitally signed message part.
