Re: virtual hosting
On Tue, 26 Mar 2002 15:49, Michal Novotny wrote: It is possible to make virtual web hosting (apache) in chroot jail? Yes. Just install complete copies of Debian in the chroot jails. There is a little problem with about 1500 domains/clients. How can I set it up (with perl/php/ssi/ssl/cgi/ftp/mysql etc.) ? I think it have to be all in the chrooted directory, so will it be apache/perl/mysql/libs for each domain? or could it be symlinked? Symlinks do not work across chroot jails by definition. I do not imagine about 1500 chroots... You would need to have a lot of memory and CPU power for that many chroot's. But I think if it can work then it will be so secure, isn't it? If it has root access for ANYTHING and it uses a stock kernel then running it chroot gives no extra protection. If you want chroot to actually give you any significant security benefits then you need a kernel patch such as grsecurity. Let's leave debian-security out of this now and keep it on debian-isp. -- If you send email to me or to a mailing list that I use which has 4 lines of legalistic junk at the end then you are specifically authorizing me to do whatever I wish with the message and all other messages from your domain, by posting the message you agree that your long legalistic sig is void. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How efficient is mounting /usr ro?
On Fri, 17 Oct 2003 07:08, Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: A read-only /usr is not a security measure. Depends on your definition og it-security. It reduces downtime, prevents some admin and software failures and therefore is a security measure. So is a tape backup a security measure? What about a UPS? Is ECC memory a security measure? I guess it's a security measure to buy rack mount servers from companies such as Dell rather than assembling your own white-box machines then. :-# Security is about protection from unauthorised access and keeping the system running in the face of attack. A read-only /usr does not help this in the regular case as anyone who has permissions to modify files under /usr also has permissions to remount it read-write. Any measure you take to prevent remounting /usr will probably also prevent file writes as well, so having it mounted read-only gains little. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How efficient is mounting /usr ro?
On Sat, 18 Oct 2003 07:07, Adam ENDRODI wrote: To stay on topic, I'm for keeping /usr and /usr/local read-only, because really nothing should update them except for a few programs under controlled circumstances (that's what makes the enforcment of this policy cheap). In addition, it might help you notice an intrusion. Unless you have a good auditing setup (none of the various auditing modules are available in Debian) then you probably won't notice an automated attack that is blocked by having a read-only file system. The attack may continue hitting you regularly until you remount it rw for an upgrade, at which time the attack will succeed. If you want security for such things then use SE Linux, systrace, RSBAC, or GRSEC. Don't waste time with ro mounts of /usr. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How efficient is mounting /usr ro?
On Sat, 18 Oct 2003 23:36, Goswin von Brederlow wrote: Michael Stone [EMAIL PROTECTED] writes: A quiescent filesystem isn't going to be corrupted in a system crash. You need to have metadata inconsistencies caused by filesystem activity before you can get corruption. Which you get from time to time due to programs opening files read-write when possible, mtime and atime updates etc. Opening a file read-write does not necessarily imply actually writing to it. Programs that open read-write when they don't need to are broken, and they are actively being tracked down and fixed. Such programs get logged in the kernel message log in SE Linux and it's easy to track them down and fix them. As for atime, the -onoatime mount option takes care of it. I mount lots of file systems with noatime just to improve performance. One machine that I inspected had no writes to it's root file system during normal operations after noatime was installed. Anyway perhaps we should get a new mailing list debian-security-de for the German meaning of security. Then the rest of us can discuss crypto, MAC, and other things that match the English meaning of the word. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How efficient is mounting /usr ro?
On Sun, 19 Oct 2003 03:44, Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: Anyway perhaps we should get a new mailing list debian-security-de for the German meaning of security. Then the rest of us can discuss crypto, MAC, and other things that match the English meaning of the word. Very funny. Personally I feel you are just short sighted, but if you like It's not a joke. This list was not created for discussions on how to avoid FSCK problems on servers that run all the time, debian-isp was created for that sort of thing. When an existing list doesn't fill a need then the best thing to do is to create a new list. If you get a debian-security-de list as I suggest then you can discuss things in German too, which should be a double benefit. me to shut p on this issues, I have no problem with that. However, how good is a box which cannot be hacked but can simply be DOSed? Name one DOS attack that is avoided by mounting /usr ro. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why do system users have valid shells
On Wed, 22 Oct 2003 19:27, Dariush Pietrzak wrote: 'su -s /bin/bash -c cmd user ' sounds like a very bs argument Do you understand the term 'breakage' ? Do you understand the term testing? How about the idea that changing something in the system may force to you to rewrite parts of code? Some of us have run fairly complete Linux machines for years with most of those accounts set to /bin/bash for their shell without any problems. I stopped doing that for two reasons, one is that upgrades of base-passwd whinged at me all the time, and the other is that I have little need for such measures now that I'm running SE Linux on all important machines. As most people who are interested in secure systems are not yet running SE Linux I think that there are some good benefits to be achieved by making the shells of those accounts be /bin/bash by default. As some people (such as myself) have run systems in such a manner for years without breakage I am quite confident that we can get these things right. We can start with bin, daemon, sys, and sync which are the least likely accounts to need a login shell. After those changes have been tested to everyone's satisfaction we can then move on to others. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why do system users have valid shells
On Wed, 22 Oct 2003 20:00, Dariush Pietrzak wrote: Do you understand the term 'breakage' ? Do you understand the term testing? Why should I? Because some of us have already performed extensive tests on this when it was raised previously. The idea of giving non-login accounts a shell of /bin/false is hardly new. The question was - what can go wrong. Well, the thing I mentioned can go wrong. It's not a bs argument, and not even very bs argument, since I'm not arguing about anything, just pointing to potential source of problems. And before we can go on with testing maybe we should think for a second what could go wrong? If you ask question 'What can go wrong', answer 'ooh, probably nothing' has rather low informational value. Which is why in my answer I told you that I had run it for a period of years on a number of machines and not found problems. Some of us have run fairly complete Linux machines for years with most of those accounts set to /bin/bash for their shell without any problems. I /bin/bash? It's a typo, right? Yes, meant to say /bin/false. whinged at me all the time, and the other is that I have little need for such measures now that I'm running SE Linux on all important machines. Good for you, I envy you, I ain't got enough time to setup and maintain SE Linux on my machines. Which is why you can benefit from using /bin/false for such accounts. without breakage I am quite confident that we can get these things right. That's the point 'we can get these things right'. Of course we can, and we should, but I don't think we can just flip the switch and forget about this. The best course of action would be to gather possible sources of problems first, then test the change, etc.. So we start by getting some developers to test it (which has already been done). Then we get a version of base-passwd to change some of the shells in unstable (as it's only in unstable initially and users get asked whether they want to update /etc/passwd it should not be a problem). After that if we have no problems it will migrate into testing. Running around saying oh no things might break does not help. Do the tests and you'll find that very little breaks even if you change all non-user accounts to have /bin/false as the shell. Last time I tested this extensively the only thing that broke was man. I think I submitted a bug report against man-db about it, it may be fixed now. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why do system users have valid shells
On Wed, 22 Oct 2003 21:37, I.R.van Dongen wrote: If the shells are changed, there are some really big consequences, but Such as? Please share your knowledge. :-) - manually compiled postgresql (user:postgres) expects the user it runs as to have a valid shell (I'm not sure about the debian package)- The Debian package used to have a number of bugs related to this. There was quite a big of work done on improving the situation, I am not sure if it's entirely fixed. Postgresql is known to be a program with seriously buggy scripts etc. I've filed several bug reports and sent in patches. It has improved a lot, I hope that the Debian package no longer has such issues. As for manual compilation, if you compile things manually then it's your responsibility to do whatever is necessary to make it work. Often manual compilation requires specifying locations of header files and libraries, using special -D options for compilation, and sometimes requires patching the source to deal with differences between the way other things work on a Debian system to the system that the upstream author coded for. People who choose to compile the program themself instead of using a .deb are best advised to start with apt-get source. If they choose to do otherwise then it's their issue. backports and 3th party debs might contain scripts that use the 'su -c' as mentioned above.- home made script, or scripts copyed out of manuals/ from webpages might expect valid shells. Such scripts may expect special directories under /var, /opt, or /usr/local. They may expect special file names under /etc, they may expect BSD or Solaris names for device nodes. We can't do everything that is necessary to get such things to work. I didn't research the impact yet, so there might be more/less problems. Research it first, then compare notes with all the other people who have already researched it. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why do system users have valid shells
On Wed, 22 Oct 2003 20:39, Joe Moore wrote: Russell Coker said: The idea of giving non-login accounts a shell of /bin/false is hardly new. Out of curiosity, what security benefit does a shell of /bin/false grant, that say, an encrypted password of NOLOGIN (or equivalently *) does not grant? There was a case of a buggy pam some time ago which let people login to accounts such as man and bin. Changing the shell would have prevented that problem (or limited the number of accounts that were vulnerable). In what circumstances would a process be started using the shell field of /etc/passwd without checking the password in either /etc/password and/or /etc/shadow? Buggy program that does authentication. How many of those circumstances rely on having UID0 access to set userids? Probably all of them. (and thus write access to /etc/passwd and/or the chsh command) That does not follow. If a program can be tricked into logging you in as the wrong account, that does not mean that it's actions can give any result other than that of an authorised user logging in to that account. As an example of this. When I initially patched the Debian login program for SE Linux I made a mistake in handling the user-name. It was possible to type in root and then the wrong password (IE you don't know the root password) and then type in the name and password for an account you are authorised for and login with the SE Linux privs assigned to the root account. This security hole did not grant the ability to read the entire contents of /etc/shadow (which /bin/login could potentially do if it was exploited). It did not grant any Unix access other than the authorised access (so without the root password you could not get UID 0 and your access was limited). All it did was grant a free choice among SE Linux security contexts that were permitted for shells spawned by /bin/login. A similar bug could once again be discovered in /bin/login (if you doubt then please audit the source ;). This is very similar to the discussion last week on read-only /usr mounts. Setting the shell to /bin/false does not change the security character of the system. It's different in a few ways. Normally programs do not write anything under /usr. So it's not a case of fool program into writing /usr/.../a instead of /usr/.../b. It's more like the recent change of making /usr/bin/crontab SGID instead of SUID. * A more important consideration is the location of bin's $HOME. What's wrong with the current location? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why do system users have valid shells
On Thu, 23 Oct 2003 04:02, Joe Moore wrote: There was a case of a buggy pam some time ago which let people login to accounts such as man and bin. Changing the shell would have prevented that problem (or limited the number of accounts that were vulnerable) So there was a bug in the PAM code so that it ignored an invalid /etc/passwd field. Why would the next bug not ignore some other /etc/passwd field (like the user's chosen shell)? You are correct, the next time a problem is discovered in PAM there could be two bugs not one. But it's more likely that bugs will be discovered one at a time. (and thus write access to /etc/passwd and/or the chsh command) That does not follow. If a program can be tricked into logging you in as the wrong account, that does not mean that it's actions can give any result other than that of an authorised user logging in to that account. It is as likely as some other bug in the privileged process. You really should read the source for /bin/login, or even better try patching it yourself some time. Then you would get a better idea of what the issues are. I realize this particular example is probably not intended to demonstrate the value of /bin/false as a shell, but it's hard to discuss a hypothetical bug... Which is why I gave an actual example of a PAM bug. A similar bug could once again be discovered in /bin/login (if you doubt then please audit the source ;). If a similar bug existed in /bin/login, it sounds like it would behave this way:A user tries username: bin with the wrong password. The user then types their username (bob) and password (1234), and are given a UID2 shell of /bin/sh. (thus a different UID than specified in the /etc/passwd file for bob, _and_ a different shell than specified for bob) Your claim is that by changing bin(UID 2)'s shell to /bin/false, this hypothetical bug is more difficult to exploit. Yes, the UID and the shell are stored in the same data structure, see getpwent(3). And that the analogous bug where bob's shell is respected (giving him a UID2 shell of /bin/csh) is unlikely. Yes. Read the code. * A more important consideration is the location of bin's $HOME. What's wrong with the current location? At the moment, nothing. Since write access to /bin pretty much 0wns the box. But a .rhosts file (+) in /bin might not be noticed for a while. A file in /var/empty (the home dir for sshd's privsep user) might be noticed. To create a file in /bin you need root access. Therefore to create /bin/.rhosts you need more access than such a file will grant. There is no point in such an attack. Why would someone create /bin/.rhosts when they can create /root/.rhosts? Does bin even own ANY files or have write access to ANY directories on a default install? From a quick look it seems that account bin gets no write access to anything on a Linux system. I guess what I'm saying is that there are just as many ways to get access to UID2 with bin:x:2:2:bin:/bin:/bin/false in the /etc/passwd. As there are with bin:x:2:2:bin:/bin:/bin/sh. Name some examples. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why do system users have valid shells
On Sat, 25 Oct 2003 02:40, Joe Moore wrote: So there was a bug in the PAM code so that it ignored an invalid /etc/passwd field. Why would the next bug not ignore some other /etc/passwd field (like the user's chosen shell)? You are correct, the next time a problem is discovered in PAM there could be two bugs not one. But it's more likely that bugs will be discovered one at a time. How is ignoring/misusing/corrupting the seventh field two bugs? Because the seventh field will not even be checked if the other checks are not passed. In the case of accounts such as man the shadow file does not have an entry that permits logging in, so the shell will not be checked for any login process unless there is some other bug. I realize this particular example is probably not intended to demonstrate the value of /bin/false as a shell, but it's hard to discuss a hypothetical bug... Which is why I gave an actual example of a PAM bug. Your actual example is poor. First, it revolves around an extension to the traditional Unix security model. PAM is an integral part of Debian, there is no option to not use it. Second, your example relies specifically on the root user having special security context privileges, and you do not specify if a similar security vulnerability existed with other login names. My example of a bug in my code used root as an example of exploiting it. In SE Linux the root identity can have very low privs, but the same result could be achieved by using the name of a priviledged identity in place of root. If the attacker of your buggy code had logged in as bin first (with the wrong password), what security context was granted? I'd assume that it was the default security context of that user (bin). Now, why should bin have a special privileged security context? In the example of a bug in my code the bin identity gets no special privs. In the example of the PAM bug bin could login directly with no password. If the attacker always gets the security context of the first login attempt, then all privileged users should have invalid login shells according to your logic. You're not suggesting we change root's shell to /bin/false, are you? You are misunderstanding. I gave the example of a bug in my code related to an SE Linux login to demonstrate how easy it is to make a mistake in such things. I gave the example of the PAM bug to show how it has already been a problem in the past. Your claim is that by changing bin(UID 2)'s shell to /bin/false, this hypothetical bug is more difficult to exploit. Yes, the UID and the shell are stored in the same data structure, see getpwent(3). Any attack or defect that overwrites/modifies that data structure is capable of targetting either of them. I don't know of an example of such an attack, do you? I do know of an example of an attack that used to work which a shell of /bin/false would solve. And that the analogous bug where bob's shell is respected (giving him a UID2 shell of /bin/csh) is unlikely. Yes. Read the code. I see no bugs in /bin/login where the userid is incorrectly assigned, nor where the shell is incorrectly interpreted. That does not mean that there are no bugs in /bin/login where one of these may be the case. This audit comes with NO WARRANTY. Read my message again. Your message does not cover the same issue at all. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why do system users have non-empty $HOME? (was Re: Why do system users have valid shells)
On Sat, 25 Oct 2003 02:46, Joe Moore wrote: To create a file in /bin you need root access. Therefore to create /bin/.rhosts you need more access than such a file will grant. There is no point in such an attack. Why would someone create /bin/.rhosts when they can create /root/.rhosts? There are many programs that use files in the target user's home directory for authentication. rsh and ssh are two common examples. Many of these programs would not be hindered by an invalid shell. That's why I originally said that the home directory is more important than what is in the seventh field of /etc/passwd. I should not have made my comment specific to UID2. Which goes back to my previous question, what do you think it should have as the home directory then? As to why someone would create /bin/.rhosts rather than /root/.rhosts, perhaps a sysadmin has mistakenly allowed sudo cp * /bin for a user who normally installs software? In which case they could install a trojan /bin/bash and get access to every account. Ok, that's a rather artificial example, but how about a buggy game that that can drop a .rhosts file in /usr/games? Again, a much more useful attack would be to replace a game with a trojan and to exploit every account that is used to run a game. Maybe one of the fortune-cookie type packages puts a binary in there which can be run at login time... Or a buggy manpage that drops a .rhosts file in /var/cache/man? That is something that could be usefully changed. Does bin even own ANY files or have write access to ANY directories on a default install? From a quick look it seems that account bin gets no write access to anything on a Linux system. If bin has no valid password, owns no files, runs no processes, and can write to no directories, then why does bin exist at all? Beats me. Compatability I guess. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: group video access hazards?
On Tue, 28 Oct 2003 18:12, Tom Goulet (UID0) wrote: I'm curious what a malicious user could do with access to the framebuffer device via the /dev/fb0 device file. Could a malicious user see anything other than what's on his or her virtual console or X session? A malicious user who logs in via ssh can see the virtual console of whoever is running X or a VT login. fbgrab is a good example program. Such a malicious user could also display arbitary data on the screen. This couldn't be used for a login: prompt (no keyboard access), but could be used to mislead the user as to what program they are really communicating with. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How efficient is mounting /usr ro?
On Tue, 25 Nov 2003 19:51, Chema [EMAIL PROTECTED] wrote: Making /usr read-only is not for that kind of security. It will keep your data safe from corruption (soft one, anyway: a disk crash will take anything with it ;-). Besides, you can get a better performance formating it with ext2, since you'll not need journaling. Why would you get better performance? If you mount noatime then there's no writes to a file system that is accessed in a read-only fashion and there should not be any performance issue. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How efficient is mounting /usr ro?
On Wed, 26 Nov 2003 07:45, Chema [EMAIL PROTECTED] wrote: RC Why would you get better performance? If you mount noatime then RC there's no writes to a file system that is accessed in a read-only RC fashion and there should not be any performance issue. Hum, ¿are you talking only about ext3? 'Couse I don't think the reading I am talking about any file system. When only reading from a file system there should not be any performance difference when comparing a RO mount vs a NOATIME mount. If there is a difference then it's a bug in the file system. performance of ext2 and reiserfs/jfs/whatever will be the same just by freezing the access time. Of course different file systems give different performance characteristics, I know this well, I wrote one of the two benchmarks used in the URL you cite. ext3 is just a somewhat dirty hack on ext2, and without journaling their performance would be probably the same. My point is that for read-only operations ext2 and the original ext3 should give the same performance. Incidentally if you want significantly better performance for such things then you want to run 2.6.0 or a Red Hat kernel so you get directory hashing on ext3. It appears from a casual code inspection that 2.6.0-test10 does not support directory hashing for ext2. So in 2.6.0-test10 ext3 should significantly outperform ext2 when there are large numbers of files in a directory. I'll have to do some benchmarks on this. Now, how much difference really makes noatime?? The difference it makes is that reading from the disk will never cause disk writes. If you access large numbers of files or if you have IO hardware that has a bottleneck of write bandwidth (EG a typical mail server) then NOATIME makes a significant difference. Also, access time is usually a piece of information I'll like to keep. In which case you need to mount RW and your entire arguement is bogus. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More hacked servers?
On Thu, 27 Nov 2003 04:51, Matt Zimmerman [EMAIL PROTECTED] wrote: Big money does not imply big security. Large corporations with lots of money to spend on security are compromised all the time. Obviously, they aren't as forthcoming about it as Debian due to monetary concerns, but even those incidents which are publicized are enough to demonstrate this. You are forgetting one important point. You have to NOTICE a hack before you can fix it. Big companies have a bad history of not even knowing that they are hacked if their web page is not defaced. One company I worked for had a machine where Apache would SEGV about 10,000 times per day. I expect that you could exploit the system to execute arbitary code, which could then gain access to the internal network. In spite of this my colleagues believed that their firewall did everything necessary to protect the internal network. The network was configured such that anyone who had access to the internal network effectively had root on all machines (there were so many ways of getting root it wasn't funny). AFAIK that network is still running in the same manner... -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How efficient is mounting /usr ro?
On Wed, 26 Nov 2003 14:24, Bernd Eckenfels [EMAIL PROTECTED] wrote: I am talking about any file system. When only reading from a file system there should not be any performance difference when comparing a RO mount vs a NOATIME mount. If there is a difference then it's a bug in the file system. I guess the thread was about non-journalling filesystems beeing faster, and less of a risk if used ro. Even for a non-journalling file system there should be no risk. If a file system is mounted and never written to then only a single disk block should change, the one with the dirty bit indicating that an fsck might be needed on a reboot. If that block is corrupted then you may need to use the backup superblock in the worst-case, but that would require a crash while mounting the file system. The difference it makes is that reading from the disk will never cause disk writes. If you access large numbers of files or if you have IO hardware that has a bottleneck of write bandwidth (EG a typical mail server) then NOATIME makes a significant difference. News Servers are even worth. And full-filesystem scans and some backup tools make the a-time less usefull anyway. There should be a way of reading a file without changing the ATIME that backup programs can use. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: getting started with SELinux
On Fri, 28 Nov 2003 22:03, Forrest L Norvell [EMAIL PROTECTED] wrote: /usr/bin/checkpolicy -o policy policy.conf /usr/bin/checkpolicy: loading policy configuration from policy.conf ERROR 'attribute file_type is not declared' at token ';' on line 867: # type device_t, file_type; /usr/bin/checkpolicy: error(s) encountered while parsing That should be declared at about line 200 in attrib.te. Try the following: cd /etc/selinux make clean make load 2. When I attempt to boot into my SELinux kernel (all packages, versions, and kernel configuration options at the end of this message), I get an error about being unable to find /usr/bin/load_policy, even with an initrd that uses the script provided by selinux-default-policy. Is there anything special I need to know about building the initrd? I imagine this may be Sounds like you have /usr on a separate file system. If you upgrade to sysvinit 2.85-7.se3 then it should work. un libselinux-devnone(no description available) ii libselinux1 1.2-1.1 SELinux shared libraries un libselinux1-dev none(no description available) un old-selinux-policynone(no description available) ii selinux 2003081307-8 Management utilities for selinux should be removed, it is for the old SE Linux. It should have been automatically removed because of conflicting with the new packages. CONFIG_SECURITY_DTE=y You don't want this. See the attached document (which will be in the next version of the kernel-patch-2.4-lsm package). -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page kernel-patch-2.4-lsm for Debian - This patch supplies the Linux Security Modules. It is needed for NSA Security Enhanced Linux (among other things). To apply automaticaly, set PATCH_THE_KERNEL=YES before first running of make-kpkg (from package: kernel-package) and make-kpkg clean to remove. When configuring your kernel do the following: (Under Networking Options, enable Network Packet Filtering. Under Security Options, enable Capabilities and enable both IP Networking and SELinux as built-in options.) This means having the following in your /usr/src/linux/.config: CONFIG_NETFILTER=y CONFIG_INET=y CONFIG_SECURITY=y CONFIG_SECURITY_NETWORK=y CONFIG_SECURITY_CAPABILITIES=y # CONFIG_SECURITY_ROOTPLUG is not set CONFIG_SECURITY_SELINUX=y This release of SE Linux depends on XATTR's. For the Ext3 file system use the following settings: CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_XATTR_SHARING=y CONFIG_EXT3_FS_SECURITY=y The options CONFIG_EXT3_FS_XATTR_USER and CONFIG_EXT3_FS_XATTR_TRUSTED are not required for SE Linux, but do not do any harm either. For the DEVPTS file system (required as the new SE Linux does not support devfs or the old-styly /dev/pty) the following options are needed: CONFIG_DEVPTS_FS=y CONFIG_DEVPTS_FS_XATTR=y CONFIG_DEVPTS_FS_SECURITY=y In the recent kernel patches MLS should be functional, but I have never tested it... Also note that the labeled networking code is experimental, and that SE Linux currently doesn't stack with the other security modules (so turn off OpenWall and LIDS if you plan to use SE Linux). The CONFIG_SECURITY_SELINUX_DEVELOP config option allows you to turn the SE capabilities on and off at run time, I recommend that you use it when first trying SE Linux (otherwise policy mistakes may prevent your machine from booting). The CONFIG_SECURITY_SELINUX_BOOTPARAM config option allows you to entirely disable the SE Linux code. If you have development mode turned on and boot with no policy then the machine will give the same behaviour as a non-SE machine, however there will be a small (maybe 2%) performance hit. If you enable this option and boot with selinux=0 appended to the kernel command line then SE Linux will be entirely disabled and the performance hit will be removed. If you want to use User-Mode-Linux (UML) with SE Linux then you need to apply the UML kernel patch, the LSM kernel patch, and an additional patch that can be found on http://www.coker.com.au/uml/ . Feel free to ask me if you have any queries about how to do this properly. Russell Coker [EMAIL PROTECTED]
Re: getting started with SELinux
On Sat, 29 Nov 2003 05:10, Martin G.H. Minkler [EMAIL PROTECTED] wrote: A little OT, but http://www.adamantix.org 's distro provides everything and more SELinux has to offer while IMHO being a little easier to handle. Adamantix is not Debian. The people subscribed to this list are here for Debian security not other OS security. Don't want to discourage anybody from SELinux, especially not with kernel 2.6 reaching production status, just my 2c ;-) I doubt that there's any risk of that. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: getting started with SELinux
On Sat, 29 Nov 2003 11:46, Forrest L Norvell [EMAIL PROTECTED] wrote: un libselinux-devnone(no description available) ii libselinux1 1.2-1.1 SELinux shared libraries un libselinux1-dev none(no description available) un old-selinux-policynone (no description available) ii selinux 2003081307-8 Management utilities for selinux should be removed, it is for the old SE Linux. It should have been automatically removed because of conflicting with the new packages. I removed selinux and updated to the new version of coreutils (which is necessary even though I'm running a 2.4.x kernel -- is this The new coreutils is not strictly necessary, I try to set the dependencies to drag in the modified coreutils so that ls etc can do what you want. There is a bug in my coreutils package in that cp copies the security.selinux xattr even if you don't ask it to, this currently breaks Debian package building in enforcing mode (I'll fix it soon). weird?), which fixed my policy problems, and now I have a policy installed and loaded. Now I have a question about devfs: I use devfs + devfsd, but I don't have devfs-se.so, nor do I know where to find Devfs is not supported by the new SE Linux (which you are using). Devfs is on the way out, so the NSA people do not consider it to be worth their effort to support it. If someone contributes kernel code patches to make it work properly then such patches will probably be accepted. But if that doesn't happen then devfs won't be supported. I have been using and supporting devfs for years, but this compelled me to start removing devfs from my systems. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security patches
On Sun, 30 Nov 2003 14:53, Colin Walters [EMAIL PROTECTED] wrote: On Sat, 2003-11-29 at 22:47, David Spreen wrote: of their programs. the system could use a db of installed-package resources. Therefore we would need to create a common language that could be translated to any acl-format. This doesn't make sense. The basis of SELinux is Type Enforcement and RBAC, not ACLs. I think that was just a terminology error. Trying to create some sort of generic security policy that could map to a SELinux policy or grsecurity policy would be very difficult, and I wouldn't trust my system's security to such a thing. It would be difficult, and the output of such a program would need to be checked by a human. But such a program should be able to at least reduce the difficulty of writing new policy. Maybe if Brian May is interested in getting a second Ph.D he can look at it... -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security patches
On Sun, 30 Nov 2003 15:32, Colin Walters [EMAIL PROTECTED] wrote: However, this is not such a bad idea, if you don't try to be too formal about it. If maintainers shipped English descriptions (say, README.Security) of what the security implications of their programs were, it could be very helpful for people writing security policies. These people would include the Debian maintainers of various security systems, as well as end-user system administrators. Sounds reasonable. For example, the Apache maintainer might write (I'm making this up): README.Security: In its most basic configuration, this package runs as a daemon listening on port 80. It does not require write access to any portion of the filesystem. It has no sensitive files (such as cryptographic keys). It also commonly needs to bind to port 443, if it does so then it needs to read SSL private key files somewhere under /etc. In common configurations it needs to access ~/public_html or ~/www or ~/web for most users. It commonly needs to create and access memory mapped files under /tmp. It is reasonably common for it to run a SETUID root wrapper program named suexec or cgiwrap to run user CGI-BIN scripts under the correct UID. In some configurations it may run as a web proxy, so it may need to connect to other local web servers. Apache always needs to load shared objects from /usr/lib/apache/1.3 (or presumably /usr/lib/apache/2.0 for the new Apache). This is just from memory, Apache configuration can be complex at the best of times. If we start asking dd's to write such plain-English policy statements for their packages we will probably soon discover that most of them don't know all the things that their package does. When you write SE Linux policy for a daemon you often get surprised to discover that it does things you did not expect. For example the way that cardmgr tries to create device nodes in several different directories, the way that lilo wants to create device nodes under /tmp, the way that sshd needs to run xauth for X forwarding, the way sendmail will bind to a high TCP port as part of it's startup process, the way that quotacheck needs to read every single file on the system, and lots more. Some of these are things that seem obvious in retrospect (of course sshd needs to run xauth, the need for it is obvious but most people wouldn't think of it when describing sshd functionality). Some of these are not obvious at all (quotacheck file reading and sendmail binding to a high port) and may even be considered bugs in the daemons. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security patches
On Sun, 30 Nov 2003 22:33, Martin Pitt [EMAIL PROTECTED] wrote: On 2003-11-29 21:08 +1100, Russell Coker wrote: It's not a question of how difficult it is to get the grsec patch to apply and work correctly on a Debian kernel. It's a question of whether anyone is prepared to do it. If using a Debian-patched kernel is a requirement then I guess that there is not much one can do about that. (That's why I voted for having clean upstream kernel sources in Debian and providing Debian patch packages separately; but that has already been discussed without much of an outcome...) I don't have any strong feelings about whether we should use a kernel.org kernel or a Debian kernel for desktop use. But as the decision has been made to go with a Debian kernel we should stick with that. As a separate issue neither the stock 2.4.x kernel nor the Debian kernel works well for the enterprise. It's on my to-do list to put a Red Hat kernel patch in Debian... grsecurity keeps its configuration in a single file and has the best design IMHO: it does _not_ need another system account, but either the configuration can be changed by putting the current root shell into 'admin mode' (by supplying a passphrase) or it cannot be changed at When the current root shell gets admin mode are other root processes prevented from reading/writing it's pty? Yes, of course. In my current ACL setting, _nothing_ (but login and getty) is allowed to access /dev/vc/*; with ptys, a similar approach would be do disallow access to /dev/pts/* in general and only allow it to ssh (I don't use incoming ssh on my box, so I did not test this). Disallowing access to /dev/pts will not work, it will break script, screen, cyclades-serial-client, wall, some implementations of talk, and probably lots of other things. With SE Linux the access is determined by the type label on the object (file, directory, pipe, socket, or device node). When you change to an administrative role via the newrole command it relabels the controlling tty to prevent such access. What you say seems to indicate that grsec does not prevent another root user from taking over the session after it's been put in admin mode (or if it does prevent such actions it does so by reducing the functionality of the system). That's why I wrote it seems and not it is so. :-) However, the arguments sound quite strong and I know a lot of people that share the negative attitude against LSM. This does not mean that I claim to have better understanding of security than Linux or the NSA; because I don't, I just have to consider the opinions of other people. Sure you can consider their opinions. Also consider that they are somewhat unhappy at having their code left out when SE Linux was put into Linus' source tree. LSM was not invented by the SE Linux people, it was requested by Linus as a way of enabling the integration of multiple security systems into the kernel. It's a pity that the developers of other security systems didn't get involved, it would be good to have a choice of LIDS, HP's system, DTE, and others in the standard kernel. The claims of porting to LSM from our current approach takes time and effort could have been made by SE Linux developers. However instead of complaining they re-implemented SE Linux twice over the course of LSM development (the first version of LSM was rejected because it had a multiplex system call similar to socketcall() but worse). I think that the result is worth the effort. PS I have a SE Linux play machine online for everyone to try out. You can login as root and see how SE Linux protects the system. There is an IRC channel dedicated to supporting it. See the URL in my .sig. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LSM-based systems and debian packages
On Mon, 1 Dec 2003 04:27, Andreas Barth [EMAIL PROTECTED] wrote: Is it possible for me as a package maintainer to specifiy the needed rights for my programms in a way that as much systems as possible can use these without the need for a sysadmin to change anything? Or would each LSM-based system need it's own configuration? And if so, which should be supported by a package, and how? There will be support in RPM for packages that contain SE Linux policy. For Debian such support will come later (if at all) as the plan is to centrally manage all policy for free software, and it's not difficult to apply custom policy for non-free software. There are patches for cron, xdm type programs, procps, psmisc, pam, and logrotate for SE Linux which will hopefully get accepted into Debian packages soon. What I would even like more is a HOWTO What a debian package maintainer should do to support LSM-based security-systems properly (and this should become part of the Developers Reference). I'm willing to create a template of such a HOWTO in parallel to adding support to LSM to my packages, if I can; and this would mean that someone with knowledge would be willing to guide me, and answer my (partly very unknowing) questions about a lot of more or less simple things. The best thing at the moment is to do things that are good for security even on non-SE Linux machines. Don't have the daemon re-write it's own config files in /etc. Have a separate process to access password files and manipulate data from them. Don't copy files into a chroot for every invocation (Postfix is difficult because of this), or if you must copy such files around then make it easy to discover where it is to modify the process (Postfix startup scripts are difficult to understand and manage). Documentation on exactly what cron jobs do would be good too, as they are particularly painful to get right. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security patches
On Mon, 1 Dec 2003 05:10, Milan P. Stanic [EMAIL PROTECTED] wrote: On Sun, Nov 30, 2003 at 11:24:43PM +1100, Russell Coker wrote: It's a pity that the developers of other security systems didn't get involved, it would be good to have a choice of LIDS, HP's system, DTE, and others in the standard kernel. LIDS uses LSM in 2.5/2.6 kernel series, IIRC. LIDS does not appear to be in 2.6 at all. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LSM-based systems and debian packages
On Mon, 1 Dec 2003 07:43, Andreas Barth [EMAIL PROTECTED] wrote: There will be support in RPM for packages that contain SE Linux policy. For Debian such support will come later (if at all) as the plan is to centrally manage all policy for free software, and it's not difficult to apply custom policy for non-free software. Managing at one place is IMHO a disadvantage for e.g. backported packages, extra packages, ... I would have favored some central place like /usr/share/lintian/overrides is for lintian where every package could drop it's special file - but of course, if the persons with more wisdom decide this than it's ok from my point of view, and I'll follow this. Actually this should already work. Drop files under /usr/share/selinux/policy/default and then run /usr/sbin/selinux-update if it exists and you should get most of what you want. There are patches for cron, xdm type programs, procps, psmisc, pam, and logrotate for SE Linux which will hopefully get accepted into Debian packages soon. What about the gettys? I'm asking this because I wrote the initial mail because of mgetty, a package where I expect some non-standard setup (though of course, I could be wrong, as I don't know much about this topic). Getty policy is pretty simple. Get run from init, open a terminal device, then spawn /bin/login. fbgetty requires one extra capability than other getty's, but fbgetty should be considered deprecated anyway. The best thing at the moment is to do things that are good for security even on non-SE Linux machines. Don't have the daemon re-write it's own config files in /etc. Have a separate process to access password files and manipulate data from them. /etc/passwd (or more exact: getpwuid etc) is not considered a password file, isn't it? password file in that context meant the file containing the password (IE /etc/shadow in the case of system authentication), not the misnamed /etc/passwd. But really I was referring to general user stuff. Such as gpg and it's secret key file, the POP password stored for the MUA, etc. Don't copy files into a chroot for every invocation (Postfix is difficult because of this), or if you must copy such files around then make it easy to discover where it is to modify the process (Postfix startup scripts are difficult to understand and manage). Documentation on exactly what cron jobs do would be good too, as they are particularly painful to get right. You mean: Just standard good behaviour for maintability of code? Yes! Putting a file in /etc/logrotate.d is not considered usage of cron? A logrotate file is considered use of cron. Logrotate has to be given permission to access the log files etc on it's own, or a script has to be launched with a domain transition to do things (or both). Some remark about another mail I got in private: It's not that I want to do only something for LSM-based systems. I'll try to support any security enhancement that's in Debian. So I'll certainly do something for SELinux if this is needed, as SELinux runs with the standard kernel and is compatible with LSM (which itself is approved by Linus, and I'm certainly not in the position to overrule Linus decisions). If it's also usefull to do something for grsecurity, I would also do this; however, it would be _really_ usefull if the grsecurity-patch would be compatible with the standard Debian kernel. Talking about what should be done to improve security is always a nice thing. I imagine that if you document the basic functionality of your package and make sure it does no silly things then things will be easier for people using grsec too. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security patches
On Mon, 1 Dec 2003 07:46, Andreas Barth [EMAIL PROTECTED] wrote: * Russell Coker ([EMAIL PROTECTED]) [031130 21:40]: On Mon, 1 Dec 2003 05:10, Milan P. Stanic [EMAIL PROTECTED] wrote: On Sun, Nov 30, 2003 at 11:24:43PM +1100, Russell Coker wrote: It's a pity that the developers of other security systems didn't get involved, it would be good to have a choice of LIDS, HP's system, DTE, and others in the standard kernel. LIDS uses LSM in 2.5/2.6 kernel series, IIRC. LIDS does not appear to be in 2.6 at all. It seems that there are at least patches for 2.6, see http://www.lids.org/ (or http://lsm.immunix.org/lsm_modules.html ) The Immunix site is way out of date, they don't have a 2.4.x patch later than 2.4.20 or a 2.5 patch later than 2.5.72 in the download section (and no support for 2.6.x at all). As for having patches for 2.6, it would be more convenient for everyone if they would submit them to Linus. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LSM-based systems and debian packages
On Tue, 2 Dec 2003 08:48, Andreas Barth [EMAIL PROTECTED] wrote: * Russell Coker ([EMAIL PROTECTED]) [031201 05:10]: On Mon, 1 Dec 2003 07:43, Andreas Barth [EMAIL PROTECTED] wrote: What about the gettys? I'm asking this because I wrote the initial mail because of mgetty, a package where I expect some non-standard setup (though of course, I could be wrong, as I don't know much about this topic). Well, mgetty (and vgetty for voice) does also in addition to normal login - receive faxes (and can start a whole bunch of things with receiving faxes, like printing, forwarding per mail, ...) - receive voice messages (to these apply the same option as to faxes) - fire up pppd - fire up uucico - fire up [any custom programm, if configured by the system administrator] This will require some new policy. There is currently no uucp policy (it seems that no SE Linux users are using it). For pppd something like domain_auto_trans(getty_t, pppd_exec_t, pppd_t) should do it. For faxes and voice messages there is probably needed some policy for fax and voice software. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LSM-based systems and debian packages
On Tue, 2 Dec 2003 18:32, Peter Palfrader [EMAIL PROTECTED] wrote:
There is currently no uucp policy (it seems that no SE Linux users are
using it).
I have one, but it does only allow what I need for uucp, which is
certainly just a small subset of possible uucp uses.
I've attached a modified version, please check it out. I've changed some of
the things to do it in the recommended manner (eg the system_crond_entry()
macro), and removed some things.
The part for running ssh looked suspect, I think it's probably best to just
have can_exec(uucp_t, ssh_exec_t).
Let me know what you think, in a few days we should have something ready to be
sent upstream.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
# postfix
/etc/uucp(/.*)? system_u:object_r:etc_uucp_t
/usr/bin/uuxsystem_u:object_r:uucp_exec_t
/usr/bin/uucp system_u:object_r:uucp_exec_t
/usr/bin/uustat system_u:object_r:uucp_exec_t
/usr/bin/uuname system_u:object_r:uucp_exec_t
/usr/bin/uulog system_u:object_r:uucp_exec_t
/usr/bin/uuto system_u:object_r:uucp_exec_t
/usr/bin/uupick system_u:object_r:uucp_exec_t
/usr/bin/cu system_u:object_r:uucp_exec_t
/usr/sbin/uuxqt system_u:object_r:uucp_exec_t
/usr/sbin/uupollsystem_u:object_r:uucp_exec_t
/usr/sbin/uusched system_u:object_r:uucp_exec_t
/usr/sbin/uuratesystem_u:object_r:uucp_exec_t
/usr/sbin/in.uucpd system_u:object_r:uucp_exec_t
/usr/lib/uucp/uuchk system_u:object_r:uucp_exec_t
/usr/lib/uucp/uucicosystem_u:object_r:uucp_exec_t
/usr/lib/uucp/uuconvsystem_u:object_r:uucp_exec_t
/usr/lib/uucp/uudemon.day system_u:object_r:uucp_exec_t
/usr/lib/uucp/uudemon.hrsystem_u:object_r:uucp_exec_t
/usr/lib/uucp/uutraf.pl system_u:object_r:uucp_exec_t
/var/spool/uucp(/.*)? system_u:object_r:uucp_spool_t
/var/log/uucp(/.*)? system_u:object_r:uucp_log_t
#DESC UUCP - Unix to Unix Copy Program
#
# Author: Peter Palfrader [EMAIL PROTECTED]
#
# TODO: the different uucp subsystems should really be in different domains
# uucico, cu, uuxqt, rmail, rnews etc
#
# This policy file only allows my most basic mail usage
# the configuration uses an ssh port and postfix's rmail
# Type for files created during execution of postfix.
daemon_domain(uucp, `, privmail')
general_domain_access(uucp_t)
log_domain(uucp)
type etc_uucp_t, file_type, sysadmfile;
type uucp_spool_t, file_type, sysadmfile;
# The sysadm may want to call uucico directly, not from cron
role sysadm_r types uucp_t;
role sysadm_r types system_mail_t; # esp this is very evil
domain_auto_trans(sysadm_t, uucp_exec_t, uucp_t)
# Access terminals.
allow uucp_t admin_tty_type:chr_file rw_file_perms;
ifdef(`gnome-pty-helper.te', `allow uucp_t sysadm_gph_t:fd use;')
# Call external programs (like ports..)
can_exec(uucp_t, { bin_t sbin_t shell_exec_t })
allow uucp_t { bin_t sbin_t }:dir r_dir_perms;
allow uucp_t { bin_t sbin_t }:lnk_file r_file_perms;
allow uucp_t var_lib_t:dir r_dir_perms;
allow uucp_t proc_t:file r_file_perms;
# postfix calls uux
ifdef(`postfix.te', `
domain_auto_trans(postfix_pipe_t, uucp_exec_t, uucp_t)
')
allow mta_user_agent uucp_spool_t:file rw_file_perms;
# Use capabilities.
allow uucp_t self:capability { setgid setuid };
# Allow operations in our spool
allow uucp_t var_spool_t:dir r_dir_perms;
allow uucp_t uucp_spool_t:dir create_dir_perms;
allow uucp_t uucp_spool_t:file create_file_perms;
# Allow logging
allow uucp_t uucp_log_t:file { append getattr };
allow uucp_t uucp_log_t:dir r_dir_perms;
# We need to execute other uucp programs
can_exec(uucp_t, uucp_exec_t);
# reading our conf
allow uucp_t etc_t:dir r_dir_perms;
allow uucp_t etc_t:file r_file_perms;
allow uucp_t etc_uucp_t:dir r_dir_perms;
allow uucp_t etc_uucp_t:file r_file_perms;
# Allow creating the lockfile
allow uucp_t var_lock_t:dir rw_dir_perms;
allow uucp_t var_lock_t:file create_file_perms;
tmp_domain(uucp)
# rmail
allow system_mail_t uucp_spool_t:file rw_file_perms;
# for cron jobs
# system_crond_t is not right, cron is not doing what it should
ifdef(`crond.te', `
system_crond_entry(uucp_exec_t, uucp_t)
allow crond_t uucp_spool_t:dir r_dir_perms;
');
dontaudit uucp_t etc_runtime_t:file r_file_perms;
dontaudit uucp_t sysadm_home_dir_t:dir r_dir_perms;
dontaudit uucp_t file_t:dir { search };
dontaudit uucp_t proc_t:file r_file_perms;
dontaudit uucp_t { boot_t modules_object_t src_t }:dir { getattr search };
# When the user domain runs ps, there will be a number of access
# denials when ps tries to search /proc. Do not audit these denials.
dontaudit uucp_t
Re: LSM-based systems and debian packages
On Wed, 3 Dec 2003 00:56, Peter Palfrader [EMAIL PROTECTED] wrote: I've attached a modified version, please check it out. I've changed some of the things to do it in the recommended manner (eg the system_crond_entry() macro), and removed some things. The part for running ssh looked suspect, I think it's probably best to just have can_exec(uucp_t, ssh_exec_t). The ssh port, which is often used to establish a secure line to the remote peer, needs to run ssh to connect to a remote host. Just using can_exec(uucp_t, ssh_exec_t) is not sufficient, we would also need to read random devices, open network connections, etc. For a more general policy, using the network might be necessary for the tcp port anyway, but I don't use that. Why not just permit the uucp domain to do that? Or if you really want to create a new domain then do it in a way that does not overload home in type names (confusion over what constitutes a USER home directory is not something we want). I have added the ssh parts back to my policy, the rest seems to work. What is mta_user_agent for and why would it need to write to our spool? postfix_postdrop_t has the attribute mta_user_agent. If you want to ever get it working on other mail servers then using attributes such as mta_user_agent is necessary. If you use the attributes correctly then it should be possible to have it work with any mail server. Please send me a new copy of your policy. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: secure file permissions
On Mon, 8 Dec 2003 19:16, Domonkos Czinke [EMAIL PROTECTED] wrote: I recommend using the chattr program. You should set them immutable chattr +i /etc/passwd /etc/shadow /etc/group /etc/gshadow. Man chattr. In a stock Linux kernel the permissions required to chattr -i a file are exactly the same as those required to write to /etc/passwd or /etc/shadow. So what does this gain? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security patches
On Fri, 19 Dec 2003 08:02, martin f krafft [EMAIL PROTECTED] wrote: I would be very interested, Russel, to hear your opinion about the claim that the LSM hooks are dangerous in terms of root kit exploits. Do you agree? If not, then please tell us what LSM precautions take care to prevent that. Henrique sums it up pretty well. There are kernel module root kits out there being used right now. Some are buggy and allow experienced administrators to find them, some probably aren't! LSM gives access in parts of the code needed to perform access control. For example there are cases where you can make a system call that takes pointers and then change the data that is pointed to between the start of the system call and when it actually does things. This is why auditing and access control systems that just take over entries in the system call table are not good enough. However if all you want to do is hide a process from appearing in /proc, hide a file in a directory, etc. Then all you have to do is to take over the system call table entries for the relevant calls. A minor race condition that could allow someone to see your hidden process on a SMP machine when you have shared memory used for parameters isn't the big risk for an attacker in terms of discovery! If the administrator thinks that an attacker has loaded a kernel module then they can boot from a CD and run tripwire. In summary, LSM provides features that are useful for the rightful administrator to protect against hostile users. But those features aren't as necessary for an attacker to protect against the administrator. If someone can load their own code into your kernel then you've lost the game already. In terms of LSM protection against this, if you use SE Linux then all aspects of file access and module loading are controlled by the policy. I am going to write a policy that implements something similar to BSD secure levels so that you can put a server into a mode where all kmem and module load access is disabled. That should be all you need. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security patches
On Fri, 19 Dec 2003 20:18, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: On Fri, 19 Dec 2003, Russell Coker wrote: In terms of LSM protection against this, if you use SE Linux then all aspects of file access and module loading are controlled by the policy. I am going to write a policy that implements something similar to BSD secure levels so that you can put a server into a mode where all kmem and module load access is disabled. That should be all you need. I think there is a LSM BSD secure levels module around (that has nothing to do with SE Linux), which should be much easier an install for those who want to play with BSD secure levels in Linux. It has been floating around. AFAIK it was never released in a fully working form, and it definately has not been included in the kernel.org kernel. Russel, do you know if there is any talk about changing the kernel itself so that it cannot write to its own exec pages? That would kill the stealth capabilities of _all_ kernel-changing rootkits but ones that change the on-disk kernel image or initrd image itself... (and having those on RO media is quite straightforward, anyway). Smart-ass answer: It's called the HURD. Serious answer: The kernel has to be able to manage all aspects of virtual memory, so protecting it from itself is impossible. If we went to some sort of HAL scheme similar to NT then we could do some of this (but it doesn't seem to do NT much good). If we went to a full micro-kernel then we could have only the micro-kernel itself being granted such access, but then it wouldn't be Linux any more. SE Linux could be ported to the HURD. Much (most?) of the early work that SE Linux is based on was done on micro-kernelled OSs. I have no time to do the serious stuff (restricting which ports a process can use when communicating with other processes and the micro-kernel, or porting the security server to be a daemon/translator), but I can help with some of the testing and writing policy. It should be possible to make SE HURD more secure than SE Linux. I am sure that the NSA people would be intersted in such a project, I doubt that they would have any time to contribute to it, but I'm sure that they would give some good advice if asked. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GnuPG mutt on Woody 3.0r2.
On Mon, 22 Dec 2003 19:45, Marcel Weber [EMAIL PROTECTED] wrote: s. keeling wrote: gpg: Signature made Sun Dec 21 17:14:28 2003 MST using DSA key ID 946886AE gpg: Good signature from Trey Sizemore [EMAIL PROTECTED] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. gpg: Fingerprint: 683F FFE2 AA2D D341 6002 A973 8443 F068 9468 86AE You have to establish a network of trust. If you do not trust this key (you have to sign it, to mark it trusted) or if you do not trust any key that has signed the above, you get exactly this result. Signing a key you don't know is not a good idea, it's easy to accidentally upload a key... There is a gpg option lsign which can be used for this, it's like a regular signature but it can never be exported. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GnuPG mutt on Woody 3.0r2.
On Mon, 22 Dec 2003 20:02, Marcel Weber [EMAIL PROTECTED] wrote: Russell Coker wrote: Signing a key you don't know is not a good idea, it's easy to accidentally upload a key... There is a gpg option lsign which can be used for this, it's like a regular signature but it can never be exported. Right: But if he is sure he trusts this key he should sign it and upload it to the key server. If he is sure because he verified the key fingerprint while meeting the owner in person, and the owner provided photo-id (or is someone he has known for many years) then he can do that. Alternatively signing a key based on a phone call with someone you know well enough to recognise their voice may be OK. Being sure because the key servers generally have the right data is of course not a reason to upload. I assume that if he had met the person and verified the fingerprint then he would have signed the key and we wouldn't be having this discussion. If he hasn't met them then it should not be signed. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Attempts to poison bayesian systems
This discussion has some minor relevance to debian-isp, but nothing to do with debian-security. Let's move the discussion to debian-isp. On Wed, 24 Dec 2003 00:25, Dale Amon [EMAIL PROTECTED] wrote: I've been noticing loads of mails like this lately: emery atrocious larval drippy elate incontrollable raster anglicanism checkerberry feed sit ajar saturable decathlon already climate inhibition pagoda narcissus expository toni I can only assume someone out there is trying to attack bayesian systems by loading them up with all sorts of normal words so that good mail gets false positives, thus breaking the systems. I'm getting about 5-10 of those per day to my personal mailbox, and another 10 or more through mailing lists. I don't think it's an active attempt to poison bayesian systems, just an attempt to avoid them by making the ratio of spam-content to non-spam much lower. One technique that's being used a lot is to get books in electronic form and put a coupld of sentences in every spam (sentences from a book will pass gramatical checking etc, unlike the example you posted above). Also text from a book will have the right ratio of words, you will almost never find such a long sentence in an email message without a punctuation character, and, or, or other common words except in the case of source code (which is another category in bayesian filters). I've never done anything serious with bayesian filters. The machine that hosts my email has spamassasin doing something, but I've never investigated that (other people manage it). I manage using DNSBL, iptables, and Postfix configuration for blocking spam. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security patches
On Sun, 4 Jan 2004 07:53, martin f krafft [EMAIL PROTECTED] wrote: also sprach Russell Coker [EMAIL PROTECTED] [2003.12.19.0229 +0100]: In terms of LSM protection against this, if you use SE Linux then all aspects of file access and module loading are controlled by the policy. I am going to write a policy that implements something similar to BSD secure levels so that you can put a server into a mode where all kmem and module load access is disabled. That should be all you need. Is this current work in progress? Do you have an ETA? No ETA at the moment. But it will be done. also sprach Henrique de Moraes Holschuh [EMAIL PROTECTED] [2003.12.19.1018 +0100]: I think there is a LSM BSD secure levels module around (that has nothing to do with SE Linux), which should be much easier an install for those who want to play with BSD secure levels in Linux. The question is: does it mix with SE Linux? I always wondered about LSM... they are stacking modules, right? So this would have to come before or after SELinux, at which point one can take control from the other, no? LSM in it's current form only supports denying access. So if you have two modules stacked then either one can prevent an operation, but if one module prevents it the other can not allow it. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: strange apache error.log entry
On Wed, 21 Jan 2004 11:28, Markus Schabel [EMAIL PROTECTED] wrote: hello folks! can you tell me what the following means in an apache error.log and where it comes from? I've searched through all other apache log files but didn't find something that could generate this. (sure, the server got hacked and is out-of-order now...) /var/log/apache/error.log: [Sun Jan 18 14:54:35 2004] [error] [client 80.142.221.116] File does not exist: /var/www/sammy/www/bc-nrw/images/halb_banner_med.jpg --14:59:21-- http://www.geocities.com/fonias28/psybnc.tgz = `psybnc.tgz' Looks like they used wget to download psybnc, it's an IRC bot. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mail processing tool
On Sun, 25 Jan 2004 20:49, Raffaele D'Elia [EMAIL PROTECTED] wrote: checks for new mail in a maibox via pop3; If you use IMAP it should be possible for you to ask the server to notify you when new mail is received. This should give you a faster response if the server correctly implements dnotify and will also give less CPU and disk use on both client and server. Finally it will give less log entries (as login and logout are logged), having a log entry every minute from your script will waste disk space. Last time I tested this functionality I found it not to work in Courier IMAP, but this may have been fixed in a more recent version of Courier. Also note that the functionality of IMAP servers varies considerably (so if one doesn't work then you can try another). In answer to your original question, I'm not aware of any program to do this for you. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to tell what process accessed a file
On Sun, 15 Feb 2004 05:31, Wade Richards [EMAIL PROTECTED] wrote: Every once in a while I get a bunch of errors because some process tried to access my CDROM, triggering automount when there's no disk in the drive. SE Linux can audit all interesting actions, exec, read, write, create, signals, etc. Also there are kernel auditing systems such as SNARE, but none of them are packaged for Debian. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help! File permissions keep changing...
On Wed, 18 Feb 2004 23:30, Kristopher Matthews [EMAIL PROTECTED] wrote: This is a security nightmare. I would *not* recommend doing any such thing in a user filesystem. You're making the assumption that he LIKES his users. :) It's not a matter of whether the admin likes his users, it's whether they like him. A hostile user can create a hard link to /etc/shadow, /etc/passwd, etc in their home directory. Then such a recursive chown will give the hostile user root on the machine. If you are going to change such things then you need to use the -uid or -gid options to find (depending on whether you are changing the UID or GID), and you need to do it when the machine is in single-user mode (IE no-one can login and cron jobs can't run). The other way of doing it properly is to write a program that open's each file, calls fstat() to check the UID/GID, then uses fchown() or fchmod(). It would be nice if someone was to patch the -R option of chown/chgrp/chmod in coreutils to do this sort of thing. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help! File permissions keep changing...
On Wed, 18 Feb 2004 23:59, Javier Fernández-Sanguino Peña [EMAIL PROTECTED] wrote: On Wed, Feb 18, 2004 at 11:05:30AM +0100, Richard Atterer wrote: Waah, SCARY! Users can create hard links to arbitrary files in that directory, e.g. links to other users' private files or to /etc/shadow, and automatically get read access to those files. That is, of course, if the partitions in the system have not been setup properly. I assumed they were ok, he _did_ say that he was changing file permissions and owners manually. Regardless, you will still have the same problem if a user creates hard links to files owned by another user (presuming that you don't have a mount point per user or a file system such as NFS that doesn't support hard-links). As I recall this entire discussion started with users who didn't know how to manage their own permissions, so presumably they make their home dir mode 755 or worse on occasion... Even if the users' home dirs are mode 711 (fairly common when web servers and other daemons want to read sub-dirs of the user's home dir) that will still allow hard links to known files such as ~/.login, ~/.bashrc, etc. Take over one of those files and taking over the entire account becomes trivial. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help! File permissions keep changing...
On Thu, 19 Feb 2004 00:23, Javier Fernández-Sanguino Peña [EMAIL PROTECTED] wrote: On Wed, Feb 18, 2004 at 11:50:27PM +1100, Russell Coker wrote: If you are going to change such things then you need to use the -uid or -gid options to find (depending on whether you are changing the UID or GID), and you need to do it when the machine is in single-user mode (IE no-one can login and cron jobs can't run). Hmmm.. I did say there was plenty of room for improvement, after all, obviously shell scripting is more prone to failure than a proper program in C but let's give it a shot: Your script still had a race condition. If you use file input redirection and have the ls/chown/chmod commands operate on /proc/self/fd/something then you might be able to do it. It would be nice if someone was to patch the -R option of chown/chgrp/chmod in coreutils to do this sort of thing. As an enhancement over the -h option? (to exclude hard links as well as symlinks) With hard links in many cases it's impossible to tell which was the original, so excluding hard links is not possible. We just need options to only chown/chmod/chgrp files if the original uid/gid/mode matches certain criteria. Also the chown/chmod/chgrp command needs to be performed on the file handle (which those commands don't currently do). -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help! File permissions keep changing...
On Thu, 19 Feb 2004 09:12, Michael Stone [EMAIL PROTECTED] wrote: On Wed, Feb 18, 2004 at 11:50:27PM +1100, Russell Coker wrote: The other way of doing it properly is to write a program that open's each file, calls fstat() to check the UID/GID, then uses fchown() or fchmod(). It would be nice if someone was to patch the -R option of chown/chgrp/chmod in coreutils to do this sort of thing. To do what? The logic rapidly gets too complex for the command line, imo. (chown --only-if-uid-isn't-root? chown --onlyuids=1000-1009?) chown --source-uid=1000 -R 1001 /home/usera That should be OK. The alternatives are to write a separate program, or to have a commonly desired operation that is extremely difficult to perform securely on a live system. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Backporting SELinux to woody
On Wed, 10 Mar 2004 08:58, Milan P. Stanic [EMAIL PROTECTED] wrote: [ Sorry, I'm not sure if this list is right place to ask this, but I can't remember better one ] The NSA mailing list is another option, but this one is OK. I'm trying to backport SELinux tools and libraries from unstable to stable (woody). Well, actually I succeed to build all except coreutils and sysvinit and installed all under UML and get to the point where I cannot login in. I've found problem with pam (backported one) which is compiled on the woody platform. Here is the syslog message: - Mar 9 19:29:44 [login] PAM adding faulty module: /lib/security/pam_unix.so Mar 9 19:29:44 [login] PAM unable to dlopen(/lib/security/pam_selinux.so) Mar 9 19:29:44 [login] PAM [dlerror: /lib/libselinux.so.1: undefined symbol: ls etxattr] - I suspect that the problem can be with old glibc (2.2.5) but I'm not sure. Because that I'd like to ask should I backport glibc from sarge? There have been some changes to the way libxattr works. From memory I think that you needed an extra -l option on the link command line when compiling with old libc6. I can't remember whether it was linking the PAM module or libselinux that needed it (or maybe both). -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Backporting SELinux to woody
On Wed, 10 Mar 2004 21:26, Milan P. Stanic [EMAIL PROTECTED] wrote: There have been some changes to the way libxattr works. From memory I think that you needed an extra -l option on the link command line when compiling with old libc6. I can't remember whether it was linking the PAM module or libselinux that needed it (or maybe both). I already found that -lattr should be added to Makefiles in policycoreutils-1.6 to build it and to Makefile for pam_unix module into libpam. I also think that the same should be done in libselinux1-1.6 and even looked through Makefiles there, but didn't found where and how to link libattr to libselinux1. That because I don't know how to build libraries i.e. I know ./configure make or fakeroot debian/rules binary for libraries but I don't know low-level work. So, the question: how can I link libattr to libselinux1? Edit src/Makefile and add -lattr in the $(CC) line for $(LIBSO). -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Backporting SELinux to woody
On Thu, 11 Mar 2004 08:22, Milan P. Stanic [EMAIL PROTECTED] wrote: On Wed, Mar 10, 2004 at 01:29:16PM +0100, Milan P. Stanic wrote: That is. I just rebuilt policycoreutils and pam with libselinux1 which is linked with libattr and it was smooth. Now I have to backport coreutils and sysvinit, huh. Hate to reply myself, but I'd like to inform you that I backported libselinux, selinux-utils, policycoreutils, pam, coreutils, sysvinit, checkpolicy and selinux-policy-default to woody. It works under UML. If someone needs them I can put it on the net or post somewhere, or maybe help if the help is needed. If you could establish an apt repository for it then that would be very useful. Brian's SE Linux packages haven't been updated for a while. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Backporting SELinux to woody
On Thu, 11 Mar 2004 20:40, Milan P. Stanic [EMAIL PROTECTED] wrote: On Thu, Mar 11, 2004 at 09:02:50AM +1100, Russell Coker wrote: If someone needs them I can put it on the net or post somewhere, or maybe help if the help is needed. If you could establish an apt repository for it then that would be very useful. Brian's SE Linux packages haven't been updated for a while. Can I leave control and changelog files in packages as is they now, i.e. original from respective DD's? I don't like idea to rebuild all of them just to put my name, comments and notes. If you copy all files related to a package intact then you don't have to make such changes. If you make any changes at all (even re-compiling with a different compiler and/or libc) then you must update the changelog appropriately. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Backporting SELinux to woody
On Thu, 11 Mar 2004 22:14, Milan P. Stanic [EMAIL PROTECTED] wrote: On Thu, Mar 11, 2004 at 09:42:52PM +1100, Russell Coker wrote: If you copy all files related to a package intact then you don't have to make such changes. If you make any changes at all (even re-compiling with a different compiler and/or libc) then you must update the changelog appropriately. Is it enough to put note in changelog that the package is backported to woody? Yes, that's fine. I can do that for binary packages tomorrow but I don't have enough time for sources until next week. Can I put in version something like libselinux1_1.6-0.1-bp.mps_i386.deb instead of libselinux1_1.6-0.1_i386.deb? Sure. The exact version numbering isn't overly important. People who put multiple back-port repositories in their apt config may get results that don't work well, but that's just a mistake anyway. Just make sure that your repository is in some way internally consistent and can be differentiated from other repositories and everything will be fine. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Backporting SELinux to woody
On Fri, 12 Mar 2004 06:25, Norbert Tretkowski [EMAIL PROTECTED] wrote: * Milan P. Stanic wrote: Can I put in version something like libselinux1_1.6-0.1-bp.mps_i386.deb instead of libselinux1_1.6-0.1_i386.deb? Well, if 1.6-0.1 will be in our next stable release, your backport will not be replaced with the version from stable. I'd suggest using libselinux1_1.6-0.0-bp.mps_i386.deb instead. Actually there was already a 1.6-1 release which will be in stable (unless we get newer versions first). -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel 2.4.22 patch
On Sat, 20 Mar 2004 05:14, Phillip Hofmeister [EMAIL PROTECTED] wrote: On another note, The GRSecurity/SELinux patches mitigate a lot of kernel vulnerabilities and userland vulnerabilities. If you are running your own kernel you may wish to look at them. Nothing protects you against kernel bugs. PaX (part of GRSEC) does some things which can theoretically protect against some kernel bugs, I am not sure whether it would have done any good against any of the recent kernel bugs (I guess if it did then we would have heard about it ;). Any improvement to system security which can make it more difficult for a hostile remote user to run code on your system will make it more difficult for a local kernel bug to be exploited. SE Linux, exec-shield, GRSEC, etc all help in this regard. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Cron - was Known vulnerabilities left open in Debian?
On Tue, 23 Mar 2004 08:19, Florian Weimer [EMAIL PROTECTED] wrote: No, it's another example for a package which heavily deviates from upstream (AFAIK, upstream is defunct) and is now developed by the GNU/Linux distributions (and each variant has a slightly different features). Despite this, the situation with cron is rather good; its complexity is not so high that it's close to impossible to port back security bugs. Cron is a good candidate for a fork. Cron is not THAT difficult in terms of coding, assembling a small team with representatives from all major distributions to maintain a fork of Vixie cron should be doable. Another option is using Dillon cron or fcron as a replacement. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: name based virtual host and apache-ssl
On Wed, 24 Mar 2004 22:22, Michael Stone [EMAIL PROTECTED] wrote: The best you could do would be to attach different certificates to different ports, but that would be extremely cumbersome and probably would lead to confusion. What if you had http://www.company1.com/ redirect to https://www.company1.com:81/ and http://www.company2.com/ redirect to https://www.company2.com:82/ ? www.company1.com and www.company2.com would have the same IP address. This should work. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VPN Firewall Kernel
On Thu, 1 Apr 2004 17:59, [EMAIL PROTECTED] (Michael Becker) wrote: If you just want a kernel, with almost everything in there belonging to security, have a look at WOLK (Working OverLoaded Kernel) at http://sourceforge.net/projects/wolk It appears that WOLK is not in Debian. I would guess that given it's aim to include as many patches as possible it would conflict with most other kernel patches (including the Debian kernel patch). If you feel that the Debian kernel-source packages provide no benefit for you then this may be OK. Neither the URL you provide nor the Freshmeat entry list what patches are included in WOLK. In Debian there are patches for exec-shield, SE Linux, GRSecurity, and the Adamantix kernel patch (PAX + RSBAC + maybe some other things). If you use one of the kernel patch packages in Debian then it will usually apply to the Debian kernel-source packages, and you can have some expectation of it being maintained for future kernel versions. Also there is a better chance that other Debian kernel patches will work with it. You might consider that this is not a problem if you have the skill and time to merge patches whenever you build a new kernel, but it can be convenient to save the time. Another option is to use a kernel source tree provided by another distribution. The Hardened Gentoo people are doing some interesting stuff in regard to kernel security patches. Compiling Gentoo kernel source on and for a Debian machine should not cause any problems. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: passwords changed?
On Sat, 10 Apr 2004 04:22, [EMAIL PROTECTED] wrote: Is there anything ordinary that can cause passwords to be changed? I tried to log in last night and sshd wouldn't accept either my user's password or my root password. When I got physical access this morning, I couldn't log into the console either. So, my first though is that I got rooted, and so I pulled the ethernet cable. However, I thought that the idea of a rootkit was to hide any evidence. So, changing the passwords wouldn't be something normal Root kits are often used by people who are a lot less intelligent than the people who wrote them. Also there is no requirement that someone who cracks your machine install a root kit. When was the last time you could login? Have you done any changes since then? Try copying the /etc/passwd and /etc/shadow to a test machine and see if it lets you login then (IE test if it is actually a password change or something broken in PAM etc). The system is actually Redhat 8.0 (not my choice) fully up to date, or as up to date as redhat lets you get nowadays. The 2 services running are sshd and proftpd. I'm definetly putting debian on it, if it does turn out to be rooted. What versions of sshd and proftpd? Both of them have had security issues at various times. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Server slowdown...
On Mon, 12 Apr 2004 10:00, Joe Bouchard [EMAIL PROTECTED] wrote: In a meeting at work (I'm part of the IT group at a large corporation) someone mentioned a particular kind of network hardware which would stop working correctly after a while. Here are some ways that network issues can slow down a server: On shared media (such as 10base2) accidentally leave an interface in promiscuous mode (there used to be a bug in tcpdump whereby running two copies of it at the same time could cause the interface to remain in promiscuous mode after both copies had exited). A moderately busy 10base2 could destroy the performance of a decent 1995 server machine if an interface was in promiscuous mode, and as the CPU use occurred in interrupt context none of the usual tools would tell you what was happening. Send lots of minimal size packets to a server or to the media broadcast address. Until recently minimal size packets on 10Mb media could destroy the performance of most systems. Now with Gig-E even using 1500 byte packets you can destroy the performance of most systems. If you had a router break and repeatedly send a single IP datagram to your server on a Gig-E link then the likely result would be a dramatic loss of performance. If you suspect this then the best thing to do is run a program to measure system performance on the console and unplug the network cables. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: logcheck.ignore entries
On Thu, 15 Apr 2004 02:01, Jeff Coppock [EMAIL PROTECTED] wrote: I'm having trouble with getting entries here to work. I have the following /var/log/auth.log messages that I want to filter out of logcheck (version 1.2.16, sarge): CRON[15302]: (pam_unix) session opened for user root by (uid=0) CRON[15302]: (pam_unix) session closed for user root CRON[15613]:(pam_unix) session opened for user mail by (uid=0) CRON[15613]:(pam_unix) session closed for user mail So, I have the following entry in /etc/logcheck/logcheck.ignore: Try this one: CRON\[.*\]:( )?\(pam_unix\) session (opened)|(closed) for user (root)|(mail) You hadn't accounted for the optional space after the ':' (or was that a typo?), the \[.*\] part is better than just a .* (imagine if you could fool cron about the user-name to log), also a .* on the end is redundant. For having two different words match you need to put each word in braces, (opened|closed) is the same as opene(d|c)losed. For the benefit of other readers, '.' in a regular expression matches any character and '*' means zero or more instances of the previous atom. See regex(7) for more details. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: makedev: /dev/tty([0-9])* should not have 666 permissions
On Tue, 20 Apr 2004 07:50, Jan Minar [EMAIL PROTECTED] wrote: It seems like they should be 660, not 600, as I suggested (wall(1) and talkd(1) would break otherwise, probably). What prevents wall from sending those escape sequences? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unusual spam recently - hummm - postprocess
On Sat, 5 Jun 2004 08:52, Michael Stone [EMAIL PROTECTED] wrote: So, adding handling for SPF RRs in one's MTA yields significant advantages today, despite the technology being new, because _all_ of the forgemail claiming to be from aol.com, msn.com, hotmail.com, pobox.com, etc. can be detected all in one step. Well, I guess the spammers will have to use different addresses. That shouldn't take long. Which leads to more spam that uses addresses from small domains in the From: field, and thus more need for administrators of small servers to implement SPF records to counter it. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam fights
On Thu, 10 Jun 2004 18:21, Jaroslaw Tabor [EMAIL PROTECTED] wrote: We are allowing all emails from whitelits. Who is we in this context? Individual users or mailing list administrators? For unknown sender, automated confirmation request is send. If For mailing lists this can be achieved by making the list subscriber-only. For individual accounts such behaviour is very anti-social as it results in confirmation messages being sent in response to virus messages. This means that even though my anti-virus software is updated regularly I still get hit by viruses through those stupid confirmation messages! My response to these scumbags who send me the confirmation messages is that if they are on a mailing list I'm on then I black-list their email address if it's known (or their mail server if their email address is not clear). If a confirmation message appears to be in response to a virus then I respond to it. Let the scumbag get another copy of the virus... I'm planning to develop this feauture, but It will be nice to hear from what you thing about this idea. Don't do it. Confirmation systems are just as bad as the problems that they try to solve. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam fights
On Fri, 11 Jun 2004 06:03, Alain Tesio [EMAIL PROTECTED] wrote: On Thu, 10 Jun 2004 18:58:33 +1000 Russell Coker [EMAIL PROTECTED] wrote: For mailing lists this can be achieved by making the list subscriber-only. For individual accounts such behaviour is very anti-social as it results in confirmation messages being sent in response to virus messages. Not if the message if refused by the smtp server before it's delivered, right ? It's not that antisocial to ask the 1% people who aren't subscribed to subscribe before sending a message. It is not anti-social for a mailing list of (potentially) thousands of people to require a subscription before posting. It is anti-social for every idiot on the net to think that they are important enough to require a subscription from everyone who wants to send them email. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam fights
On Fri, 11 Jun 2004 19:29, Dale Amon [EMAIL PROTECTED] wrote: On Fri, Jun 11, 2004 at 10:45:44AM +1000, Russell Coker wrote: It is anti-social for every idiot on the net to think that they are important enough to require a subscription from everyone who wants to send them email. Like it or not (and I don't) that is where we are headed if other solutions to spam are not implimented that cover non-NANOG type persons. I strongly suspect It won't work because challenge-response systems are technically no good. While CR systems are almost never used because the people who use them are universally regarded as cretins, the spammers won't bother about trying to fool them. If CR systems get popular then spammers will start replying to the messages. Most spammers have working email addresses, so it would not be difficult to automate a response to a CR system. Any CR system which just requires that you reply to this email will be trivially broken by spammers. One CR system I saw used a web page with some obscured text that is (supposedly) only readable by humans. There are two ways of solving this (if it ever becomes popular). One way is to make entering such things a condition for downloading free porn from a porn site (a document on using porn sites to subscribe to hotmail etc was published some time ago). The other way is better OCR software. Finally, a large chunk of spam is entered by humans. The Nigerian spammers often do things manually with cut/paste and don't have software to automate it (a friend witnessed a Nigerian spammer doing this at an Internet cafe). Such people will get past any CR system that could be devised. we'll see a generation of mail systems which greylist by default at the very least. Perhaps a future secreterial job will be to wade through the muck and query the boss as to whether one or two should be allowed access. That is a secretarial job today. Some people (such as Bill Gates) employ a team of people to filter their email. For some people, even the volume of non-spam mail could be rather intolerable. Imagine if you were Tom Hanks and your private email got out and you had to go through thousands of adoring fan mails to find that movie contract from your agent... It's quite easy to search on From: field. Of course you need a decently fast Internet connection to download all the messages, but I'm sure Tom can afford that. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam fights
On Fri, 11 Jun 2004 21:38, Dale Amon [EMAIL PROTECTED] wrote: That said, those who can afford it will hire human operators to act as email gatekeepers; those who can't will use whatever a salesman can convince them is affordable and works. Whether we like it or not will not figure into the decision. Some of the anti-spam people are very enthusiastic about their work. I wouldn't be surprised if someone writes a bot to deal with CR systems. It should not be technically difficult to publish some email addresses, wait for challenge messages to come in response to virus messages, and then have it automatically send an appropriate response to the challenge followed by a series of flames. As to the type in this random code from a jpeg, I use that on samizdata (a major blog for which I'm one of the editors). It stopped the problem of blog-spam cold; the human entry is stopped cold by having a team of writers who delete on sight. One - many communication is different. If you want to get a letter to the editor published in a newspaper you have to confirm your identity and contact details before it will be considered. This can involve a journalist phoning you to confirm your identity and permission for publication. If you want to send mail to most mailing lists you have to subscribe first. Blogs are in the same category so I agree with what you are doing there. At the end of the day, dealing with spam is an employment opportunity, not something that will be solved technically. Human problems require human solutions. Sometimes human solutions involve humans writing and installing programs to implement them. Totally stopping spam in an automatic manner is not possible. Reducing it by a factor of 100 so that humans can manually deal with the residue is possible. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hashcash - was re: Spam fights
On Fri, 11 Jun 2004 22:34, Patrick Maheral [EMAIL PROTECTED] wrote: It seems that most people here don't like CR systems, and I'd have to agree with that consensus. I'm just wondering what is the general feeling about using hashcash and other header signatures systems. Currently you can't accept only such messages because almost no-one sends them. Most people see no need to send them because almost no-one checks for them when receiving a message. Anti-spam measures may be used on workstations eventually, but have to be initially installed at servers if they are to become popular. The people who run big mail servers (AOL, Hotmail, etc) don't want to install hashcash for the same reason that spammers won't install it. Besides, with an army of Windows Zombies you could generate those signatures anyway... -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hashcash - was re: Spam fights
On Fri, 11 Jun 2004 23:43, [EMAIL PROTECTED] (Rens Houben) wrote: In other news for Fri, Jun 11, 2004 at 11:24:05PM +1000, Russell Coker has been seen typing: Besides, with an army of Windows Zombies you could generate those signatures anyway... Why bother, when said windows machines will have perfectly good signatures stored on them somewhere already? Presumably the signature would be based on the envelope recipient and therefore signatures you find on someone else's machine would not do any good. If it was otherwise then a single signature would work for an entire spam run. I am assuming that the sending machine would not store the signatures for messages it sent, which could be re-used if the spam messages were to have an ancient time-stamp. However this still wouldn't be of any great use, not many people have more than 10,000 messages stored in their sent-mail folder and the common case is far less. Capturing a lot of zombies to generate signatures would probably be easier than trying to find a machine that had a large sent-mail folder. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spam fights
On Sat, 12 Jun 2004 04:22, s. keeling [EMAIL PROTECTED] wrote: Incoming from Rick Moen: Quoting Russell Coker ([EMAIL PROTECTED]): Some of the anti-spam people are very enthusiastic about their work. I wouldn't be surprised if someone writes a bot to deal with CR systems. A bot to detect C-R queries and add them to the refused-mail ACL list would be most useful. ;- A better one would be one that successfully negotiates the C-R itself. Then we can give the spammers a copy and teach the C-R nitwits a lesson. Proof that I am correct. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rbl's status?
On Mon, 14 Jun 2004 16:39, Adrian 'Dagurashibanipal' von Bidder [EMAIL PROTECTED] wrote: Also you may want to look at the rfc-ignorant.org ones, but reading nanae I got the impression that they are more trouble than they're worth. This thread inspired me to fiddle with my anti-spam settings again. Below is my current Postfix configuration for those who are interested. My latest addition is RHSBL entries. So far rhsbl.sorbs.net has not caught anything (only been on for about 30 mins and it's late in the list). The rfc-ignorant.org entries have been catching a lot, one thing that they cught is yahoo.com because [EMAIL PROTECTED] allegedly doesn't work. I've just sent a test message to [EMAIL PROTECTED] and it hasn't bounced yet... Maybe the Yahoo abuse team are being butt-head's about clicking on the removal URL. smtpd_client_restrictions = permit_mynetworks, reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.sorbs.net, reject_rbl_client list.dsbl.org, reject_rbl_client cbl.abuseat.org, reject_rbl_client dnsbl.njabl.org, reject_rbl_client sbl.spamhaus.org, reject_rbl_client relays.ordb.org, reject_rhsbl_client rhsbl.sorbs.net, reject_rhsbl_client dsn.rfc-ignorant.org, reject_rhsbl_client postmaster.rfc-ignorant.org -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: password managers
On Tue, 15 Jun 2004 04:56, andrew lattis [EMAIL PROTECTED] wrote: currently i've got an ever growing password list in a plain text file stored on an encrypted loopback fs, this is getting cumbersome... figaro's password manager (package fpm) looks nice and uses blowfish to encrypt data but i can't find anything showing any type of third party audit. what does everyone else use to keep track of all there passwords? OS/X from Apple has a password manager program, it allows passwords to be made available to applications for certain time periods (not sure how this is supposed to work as the application could just write it to disk). I think that an ideal password management scheme would be mediated by a SGID application (SGID so that it can access storage unavailable to regular user processes and so that it can't be ptraced). Password storage would be either in a file owned by the user that is mode 0600 under a mode 1770 system directory with group ownership being the group that the management program is SGID to, or a regular file in the home directory that is encrypted (requiring a password authentication for the first login of the day or something similar). The password management system would need to have helpers for managing passwords that would be called by the application. For example there would be POP and IMAP helpers which would establish a connection to the mail server, authenticate, and then use a unix domain socket to pass the file handle for the TCP socket back to the calling application (so the MUA would never be able to recover the password). -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Crash Bug????
On Tue, 15 Jun 2004 17:24, Rudy Gevaert [EMAIL PROTECTED] wrote: Would it be possible to run that program trough e.g. perl/php/... ? A use could ftp the executable and write a php script that execute it. Does PHP allow executing arbitary binaries? If the user can install CGI-BIN scripts then that's a good way of running a kernel security attack (or other local or back-end network attack). -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: password managers
On Tue, 15 Jun 2004 18:46, Alberto Gonzalez Iniesta [EMAIL PROTECTED] wrote: Some of the applications I run use kwallet, that seems similar to what Russell Cooker described for OS X. No. kwallet can be ptraced, this allows a hostile program to get access to all it's data with ease. Of course in OS/X I expect that you could fool the password manager somehow to get access. But at least they stop ptrace. Also kwallet seems to have no features for restricting access to data. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: My details
On Sat, 3 Jul 2004 10:28, LOGAN Jim [EMAIL PROTECTED] wrote: WHO R U FUCKIN' BASTARD ? I HATE THE BLOODY MOTHER FUCKERS LIKE U ! I DON' T LIKE YOUR DAMN' VIRUS , SON OF A BITCH ! ...I' LL GET YOUR BLOODY SKIN ! WOLVERINE Does your mother know you talk like that? The debian-security list has nothing to do with the virus you received. It probably came from one of your friends who uses Outlook. PS This is a good example of why children should be supervised when using the Internet. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PaX on Debian
On Mon, 26 Jul 2004 02:57, John Richard Moser [EMAIL PROTECTED] wrote: I'm interested in discussing the viability of PaX on Debian. I'd like to discuss the changes to the base system that would be made, the costs in terms of overhead and compatibility, the gains in terms of security, and the mutability (elimination) of the costs. Before we can even start thinking about PaX on Debian we need to find a maintainer for the kernel patch who will package new versions of the patch which apply to the Debian kernel source tree. We have had a few flame-wars about this in the past which have had no positive result because no-one has volunteered to do the kernel coding work. A PaX protected base system would be best compiled ET_DYN, which can be done by using modified spec files or a specially patched gcc to make pies-by-default binaries. Certain things don't compile this way; and thus would need this functionality disabled (modified spec, -fno-pic -nopie). This will be discussed in greater detail later. Debian does not use spec files, spec files are for RPM based distributions. It would have to be a modification to debian/rules in all the packages, or a modification to gcc and/or dpkg-buildpackage. A PaX protected base would also benefit from Stack Smash Protection, which can be done via the gcc patch ProPolice. This imposes minimal overhead, which will be discussed in greater detail later. It overlaps and extends many of the protections PaX offers, but catches earlier on; and is thus a good system to pair with PaX. We have recently discussed this on at least one of the lists you posted to. The end result of the discussion is that GCC is getting another SSP type technology known as mudflap. Mudflap depends on some major new features of GCC 3.5, so it looks like we won't be getting this until GCC 3.5 as the Debian GCC people don't want to merge in other patches which have no apparent chance of being included upstream. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PaX on Debian
On Mon, 26 Jul 2004 13:48, John Richard Moser [EMAIL PROTECTED] wrote: | Before we can even start thinking about PaX on Debian we need to find a | maintainer for the kernel patch who will package new versions of the | patch which apply to the Debian kernel source tree. We have had a few Are you talking PaX or grsecurity? PaX is significantly less invasive than grsecurity. There will still be issues, of course. PaX. AFAIK the only PaX kernel-patch package in Debian is the Adamantix kernel source, which has RSBAC and a bunch of other stuff, and the GRSec patch. Neither of them apply to the Debian kernel source tree. Where would I see debian's 2.6.7 source tree? I'm not a deb user, remember, so I'll need a tarball or something. http://ftp.debian.org/debian/pool/main/k/ | We have recently discussed this on at least one of the lists you | posted to. | The end result of the discussion is that GCC is getting another SSP type | technology known as mudflap. Mudflap depends on some major new | features of | GCC 3.5, so it looks like we won't be getting this until GCC 3.5 as the | Debian GCC people don't want to merge in other patches which have no | apparent chance of being included upstream. Then don't use ProPolice/SSP for now. That seems to be what will happen. I'd rather see SSP included sooner, but I guess it won't happen. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
init scripts and su
The start scripts for some daemons do su - user or use
start-stop-daemon -c to launch the daemon, postgresql is one example.
During the time between the daemon launch and it closing it's file handles and
calling setsid(2) (which some daemons don't do because they are buggy) any
other code running in the same UID could take over the process via ptrace,
fork off a child process that inherits the administrator tty, and then stuff
characters into the keyboard buffer with ioctl(fd,TIOCSTI,c) (*).
To address these issues for Fedora I have written a program named init_su.
init_su closes all file handles other than 1 and 2 (stdout and stderr). File
handles 1 and 2 are fstat()'d, if they are regular files or pipes then they
are left open (no attack is possible through a file or pipe), otherwise they
are closed and /dev/null is opened instead. /dev/null is opened for file
handle 0 regardless of what it might have pointed to previously. Then
setsid() is called to create a new session for the process (make it a group
leader), this invalidates /dev/tty. Then the uid is changed and the daemon
is started.
I have attached the source code to init_su, please check it out and tell me
what you think. After the discussion concludes I will write a patch for
start-stop-daemon to give similar functionality.
(*) On system boot and shutdown there is no problem. It's when the
administrator uses /etc/init.d/postgresql to start or stop the database that
there is potential for attack.
http://www.redhat.com/archives/fedora-devel-list/2004-July/msg01314.html
I have also started a similar discussion on the Fedora development list about
this issue, see the above URL.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
#include stdio.h
#include string.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include pwd.h
#include stdlib.h
#include unistd.h
#include syslog.h
void usage(const char * const msg)
{
if(msg)
fprintf(stderr, Error: %s\n\n, msg);
fprintf(stderr, Usage: init_su [-l] user -c command\n);
exit(1);
}
int main(int argc, char **argv)
{
int i, fd;
int login = 0;
char *command = NULL, *user = NULL, *shell = NULL, *nu_argv[4];
struct passwd *pw;
int int_c = 0;
while(int_c != -1)
{
int_c = getopt(argc, argv, -lc:s:);
switch(int_c)
{
case 1:
if(!strcmp(optarg, -))
{
login = 1;
}
else
{
user = optarg;
}
break;
case 'l':
login = 1;
break;
case 's':
shell = optarg;
break;
case 'c':
command = optarg;
break;
}
}
if(!user || !command)
usage(NULL);
pw = getpwnam(user);
if(!pw)
usage(User unknown.);
if(setregid(pw-pw_gid, pw-pw_gid))
usage(Can't setgid(), are you root?);
if(setreuid(pw-pw_uid, pw-pw_uid))
usage(Can't setuid(), are you root?);
if(!shell)
shell = pw-pw_shell;
if(login)
{
nu_argv[0] = strrchr(shell, '/');
if(!nu_argv[0])
usage(Bad shell.);
nu_argv[0] = strdup(nu_argv[0]);
nu_argv[0][0] = '-';
}
else
nu_argv[0] = shell;
nu_argv[1] = -c;
nu_argv[2] = command;
nu_argv[3] = NULL;
close(0);
for(i = 3; i 1024; i++)
close(i);
openlog(initrc_su, LOG_CONS | LOG_NOWAIT, LOG_DAEMON);
fd = open(/dev/null, O_RDWR);
if(fd == -1)
{
syslog(LOG_ERR, Can't open /dev/null when trying to execute program %s, command);
return 1;
}
for(i = 0; i 3; i++)
{
struct stat sbuf;
if(i != fd (fstat(i, sbuf) == -1 || (!S_ISREG(sbuf.st_mode) !S_ISFIFO(sbuf.st_mode)) ))
{
close(i);
if(dup2(fd, i) != i)
{
syslog(LOG_ERR, Can't dup2() when trying to execute program %s, command);
return 1;
}
}
}
if(fd = 3)
close(fd);
setsid(); /* it's OK if this fails as we get the right result anyway */
execv(shell, nu_argv);
syslog(LOG_ERR, Can't exec program %s, command);
return 1;
}
Re: running services in their own little world
On Mon, 26 Jul 2004 22:43, Milan P. Stanic [EMAIL PROTECTED] wrote: If so when will the patch be submitted to Linus? Who knows? These days patches doesn't get accepted so easy :-( The SE Linux patches get accepted easily enough. Most of the 2.6.x kernels have had SE Linux changes in them. Adding a new LSM module is like adding a new device driver, people who choose not to use it will not even notice it's there, so there's nothing stopping Linus from adding them at any time. It would be good if SE Linux wasn't the only security module in the kernel.org kernel tree. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: preventing /dev/kmem and /dev/mem writes?
On Mon, 26 Jul 2004 22:54, [EMAIL PROTECTED] wrote: I have a machine that has been the unfortunate victime of SuckIT r00tkit. As this exploit relies on writing to /dev/kmem, I was thinking of making /dev/mem and /dev/kmem unwriteable. I have heard this breaks X and some gdb functions, but does anyone know any other specific problems this might have? Some boot loaders need to access /dev/mem or /dev/kmem for getting BIOS data. Once your machine is in a bootable state you should not need /dev/k?mem for that. klogd uses such access, probably for decoding Oops messages (it can probably operate fine without it for some loss of functionality). vmware uses such access (and lots of other invasive access to kernel memory). Many xdm type programs read kernel memory as a source of randomness. This is bad because kernel memory is not random and it may leak some information from the kernel. xdm in Fedora should be fixed to use /dev/random. The X server needs such access if it's accessing the hardware directly. If it uses the fbdev then it should not need such access. The above is taken from the SE Linux policy. Apart from the programs listed above in SE Linux nothing is granted such access. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: preventing /dev/kmem and /dev/mem writes?
On Mon, 26 Jul 2004 23:38, [EMAIL PROTECTED] wrote: I have a machine that has been the unfortunate victime of SuckIT r00tkit. As this exploit relies on writing to /dev/kmem, I was thinking of making /dev/mem and /dev/kmem unwriteable. I have heard this breaks X and some gdb functions, but does anyone know any other specific problems this might have? Some boot loaders need to access /dev/mem or /dev/kmem for getting BIOS data. Once your machine is in a bootable state you should not need /dev/k?mem for that. but isn't that just read-only? Yes. But if you can read /dev/mem then you can probably find a copy of /etc/shadow and other useful stuff in there... -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: preventing /dev/kmem and /dev/mem writes?
On Tue, 27 Jul 2004 00:23, Michael Stone [EMAIL PROTECTED] wrote: On Mon, Jul 26, 2004 at 11:38:33PM +1000, [EMAIL PROTECTED] wrote: /dev/kmem unusable. That, he says, will break lilo (I can't use GRUB as it doesn't support booting off RAID devices properly) Hmm. Seems to work here. It seems that lilo code run in real mode puts some special data below 640K, and then the lilo installer which runs from Linux accesses /dev/mem to read it. Whether this information is required depends on which lilo options you use. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: init scripts and su
On Tue, 27 Jul 2004 07:48, Andrew Pimlott [EMAIL PROTECTED] wrote: During the time between the daemon launch and it closing it's file handles and calling setsid(2) (which some daemons don't do because they are buggy) any other code running in the same UID could take over the process via ptrace, fork off a child process that inherits the administrator tty, and then stuff characters into the keyboard buffer with ioctl(fd,TIOCSTI,c) (*). If this is a real problem (which it sounds like), it's not specific to init scripts. Shouldn't it be fixed in su? Ideally yes. But that involves proxying all operations on the pseudo-tty which is quite a difficult task. Maybe your changes should happen in su by default, with a --leak-tty option if you want to keep the terminal. I can't imagine us changing the way su works by default. The only way to make su user not have this problem by default is to proxy the pseudo-tty stuff. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt 0.6 and how it does *not* solve the problem
On Mon, 23 Aug 2004 09:34, Geoff [EMAIL PROTECTED] wrote: There is an elaborate system to maintain quality in new Debian developers (which seems like a good idea to me). Why not have some sort of system for ensuring the quality in continuing DD? If a DD didn't meet the criteria they would go into an inactive list, and if they stayed in the inactive list for 3 months, would go into the retired list, and their gpg keys _somehow_ invalidated. Is it possible on a gpg key server to mark a key as invalid, with out access to the private key? Sounds like a reasonable idea. We can't automatically make the key invalid. But we can have a central Debian key that's used to sign the keys of all developers. If such a signature was revoked then it would show the change in status of the developer. Removing developers who don't meet certain criteria (EG no package uploads for 6 months) from active status makes a lot of sense. Anyone care to propose a GR? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt 0.6 and how it does *not* solve the problem
On Mon, 23 Aug 2004 13:07, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Russell Coker [EMAIL PROTECTED] writes: Removing developers who don't meet certain criteria (EG no package uploads for 6 months) from active status makes a lot of sense. Anyone care to propose a GR? Careful about terminology here. I wouldn't say remove, just we drop them from the list of signatures. They are still Debian developers. Removing from active status seems appropriate to me. If we are afraid of compromised packages then we can't have an automated method of changing status back to active. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt 0.6 and how it does *not* solve the problem
On Mon, 23 Aug 2004 14:46, Bron Gondwana [EMAIL PROTECTED] wrote: Removing developers who don't meet certain criteria (EG no package uploads for 6 months) from active status makes a lot of sense. Anyone care to propose a GR? This doesn't work. The problem is basically: a) what about a package which they uploaded while valid, more than 6 months ago, that someone wants to download and install now. That package doesn't matter, if they don't have active status then the Debian server machines won't accept it. b) if by date, what's to stop someone backdating a package and falsifying a mirror/proxy with a copy of their package. The signature will still check out. Because they can't go back in time and get the Debian server to accept the package. If you wanted to implement this the only safe way to do it and have the original packages by ex-developers still installable is to have a central daemon check the signature and co-sign the fact that they checked the signature at a certain date (upload date) and that it was valid as of that time. Isn't the entire point of apt security extensions to make sure that the packages can only be accepted if they come from the Debian server not another server that impersonates it? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt 0.6 and how it does *not* solve the problem
On Mon, 23 Aug 2004 13:30, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Russell Coker [EMAIL PROTECTED] writes: Removing from active status seems appropriate to me. But that's a totally different subject. If you want to remove Debian developers from the list of developers, because they haven't uploaded in six months (what about packages that don't have bugs?!) then that's a different topic. Please don't tie it to the security thing, which doesn't require removing them as developers. Which is why I haven't suggested removing them entirely, just removing their active status (and therefore rights to upload packages, login to Debian servers, etc). -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rebuilding packages on *all* architectures
On Mon, 20 Sep 2004 06:15, martin f krafft [EMAIL PROTECTED] wrote: I want to add another point to this discussion. While we cannot prevent malicious maintainers from installing to the archives or poisoning the buildds, requiring all binaries to be remade on the buildds would rule out the possibility that an trojaned maintainer's machine would cause infected software to be distributed in the archives. Security it not absolute. But requiring all architectures to be rebuilt does add a significant amount of security, IMHO. Requiring all packages to be rebuilt will prevent the binary from not matching the source. But what if the source is modified? Taking over a DD's machine and modifying the source tree that is used to make the .diff.gz shouldn't be impossible. We don't have any source auditing processes that could deal with this. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Hardened project status.
On Sun, 26 Sep 2004 07:22, Lorenzo Hernandez Garcia-Hierro [EMAIL PROTECTED] wrote: - openssh (i'm working on the patches that bring SecurID Token use features, and others from independent hackers) Most of the features you list are things that are difficult to get into Debian/main. But token based security for openssh is something that seems like it could go in without too much pain. Have you talked to Matthew Vernon about this? About the kernels...the work is in production state, i've currently tested them on some machines , 2 of them are shared environments (software-libre.org ourproject.org) with user chroots, etc. I've also did the DHKP, but i'm going to remix it and use instead of the current patches (OW and others) the PaX + RSBAC + SELinux mix. You have RSBAC and SE Linux in the same kernel? What's the point? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Hardened project status.
On Mon, 27 Sep 2004 00:39, Lorenzo Hernandez Garcia-Hierro [EMAIL PROTECTED] wrote: Most of the features you list are things that are difficult to get into Debian/main. Not too really difficult, it depends on how it gets developed: http://www.debian-hardened.org/wiki/index.php/CVS_Development_Organization SSP and PIE don't affect the binaries performance (not seriously), and arbitrary patches get tested before using them. It goes under the lead210 pool before it goes to system-dh. These things are obviously difficult due to the amount of time that has been spent on them without anything getting into main. The last discussion of SSP resulted in the GCC package maintainers indicating that they wanted to wait for Mudflap, other discussion indicates that Mudflap won't do what we really want in regard to such things (more of a debugging tool than a method of securing production code). So I guess SSP is on hold until after Mudflap. About the kernels...the work is in production state, i've currently tested them on some machines , 2 of them are shared environments (software-libre.org ourproject.org) with user chroots, etc. I've also did the DHKP, but i'm going to remix it and use instead of the current patches (OW and others) the PaX + RSBAC + SELinux mix. You have RSBAC and SE Linux in the same kernel? What's the point? I haven't done that work, we are just starting to decided what's the painless solution. Best thing to do is to have separate kernels for GRSEC, RSBAC, and SE Linux. I am happy to test out all the SE Linux kernels you produce and review all code and configuration that you use. Let me know when you are ready for me to do this. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: arp table overflow due to windows worm
On Mon, 18 Oct 2004 07:08, Rick Moen [EMAIL PROTECTED] wrote: Quoting Jason Lunz ([EMAIL PROTECTED]): The entire neighbor cache was completely rewritten recently, and I believe it was prompted by exactly this sort of situation. Just wanted to mention: That neigbour table overflow error can also be caused by inadvertantly removing the localhost line from one's /etc/hosts file, with the result that an avalanche of local socket requests clobber the system's ARP cache. How does that work? Connections to 127.0.0.0/8 go to device lo unless your routing table is broken. Lookups on localhost with gethostbyname() should be expected to fail if there is no entry in /etc/hosts unless your default DNS search name has a localhost entry (in which case you have an entirely different set of problems). -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security issue? Daemon users has to much rights...
On Sun, 24 Oct 2004 19:24, Jan Lhr [EMAIL PROTECTED] wrote:
Yes, and that is one of the core points in my suggestion that you look
at SELinux or a similar mandatory access control based security module.
SELinux is overkill in some ways. A system adminstrator, not being able to
handle ACLs won't be able to handle SELinux.
One of the problems with managing Unix access control is that there is no way
of analysing the chain of operations.
Program A can execute program B which is SETGID, which then gives it access to
execute program C which is SETUID (but not executable by the original GID),
etc. Analysing this would require an operation equivalent to find / to get
the data and a tool which no-one has bothered writing to analyse it.
The SE Linux policy has an analysis tool which can follow chains of execution.
If you are concerned about programs that can read /etc/shadow then you can
search the policy to get a list of the domains that are permitted access to
shadow_t. Then you can get a list of types that are entry-points for those
domains (EG the domain passwd_t has { read write } access to shadow_t and can
be entered through type passwd_exec_t) and check which files are labelled
with that type. The code in those programs can then be audited for correct
operation. Also the number of domains which can execute passwd_exec_t files
to enter the passwd_t domain is a small sub-set of the domains in the system.
The Unix permission system is very difficult to manage, and many security
problems have occurred because of mistakes, misunderstandings, and oversights
in manipulating it. Posix ACLs make things worse by having all the features
of Unix permissions plus more complexity. SE Linux is far easier to manage
correctly. Unix permissions are much easier to manage, this can be
considered a good thing (ease of use) or a bad thing (ease of borking a
system).
The problems which started this discussion are all already solved with the
default SE Linux policy.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
Re: SELinux in debian/sarge
On Monday 24 January 2005 19:10, Markus Schabel [EMAIL PROTECTED] wrote: I've setup a server with selinux enabled, using the packages from Russel Coker (http://www.coker.com.au/selinux/) but they are a bit outdated, at least there are more current packages in debian/testing available (coreutils, dpkg, dselect, initscripts, sysv-rc, sysvinit). I think the packages in sarge are not SE-enabled? Are there newer/current packages somewhere around (didn't find anything on apt-get.org and google)? dselect, initsctips, and sysv-rc don't matter. I will put new versions of dpkg and sysvinit on my site soon. Some other people are working on coreutils. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compromised system - still ok?
On Monday 07 February 2005 14:43, Alvin Oga [EMAIL PROTECTED] wrote: No, you make an image, reinstall, and if you have time (ie. you normally dont) then you can start the forensics. yes about making an image ... i assume you mean - take the box down, - i hate taking the box down, as you can lose valuable info in its memory Unless you have special hardware installed it's impossible to take a memory image of a running machine. There are PCI cards available which use bus-mastering to copy the memory of a live machine for forensics, but they are expensive and would have to be installed before the machine was cracked. Inspecting the memory of a running machine that has been properly cracked is a problem as it may be obscured by a kernel module. Most people recommend abruptly cutting the power to a machine that may have been compromised. That prevents unlinking files that have no links but which were in use at the time. A shutdown process will give a consistent file system (losing data from temporary files) and may also lose other data. - i'd re-install into a new disk and leave the cracked one alone ( disks are super cheap ) - i would not reinstall on the cracked disk as it can have hidden filesystems How would hidden filesystems work? Some name-brand machines (particularly laptops) have a BIOS extension stored on an IDE hard disk which apparently has some reserved disk space. It seems that my Thinkpad had something like this, but now that I'm running 2.6.10 Linux sees all the disk space which would allow me to increase my Linux use by 3.4G which would overwrite the Thinkpad stuff. Once Linux is using all the space there's no-where to hide. Assuming that you use all your disk space then hidden file systems shouldn't be an issue. However it may be good to keep the disk anyway for evidence purposes. Data on original disk may be better regarded than data on a DVD if the case ever comes to court. - for forensics.. use a good cd or build a custom disk with with lot of fun forensics on it and fiddle till one finds all the answers :-0 Make sure that you don't do forensics on the original image. Investigating the situation may require running fsck etc which changes things. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: FIle access auditing
On Wednesday 27 April 2005 21:16, Marcell Metzner [EMAIL PROTECTED] wrote: I have seen this using SE Linux or RSBAC. This 2 are the best I have seen till now. One limitation of SE Linux in this regard is due to the design of the LSM interface. The LSM interface does not get called until after Unix permissions have been checked. So for example if I have a process running as UID!=0 and group!=shadow which attempts to read /etc/shadow then that operation will not be audited by SE Linux. RSBAC is not based on LSM and is not subject to that limitation, so it may be able to audit such things. However there is code in the standard kernel.org 2.6.x kernels to do this, you need the auditctl and auditd programs and the following options in your kernel config: CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Securing bind..
On Sun, 30 Dec 2001 11:18, Petre Daniel wrote: Well,i know Karsten's on my back and all,but i have not much time to learn,and too many things to do at my firm,so i am asking if one of you has any idea how can bind be protected against that DoS attack and if someone has some good firewall for a dns server ( that resolves names for internal clients and also keeps some .ro domains) please post it to the list.. both ipchains and iptables variants are welcome.. thank you. Which DOS attack are you referring to? For making bind secure I suggest running it as non-root using authbind and build your kernel with OpenWall, LSM, or GRSecurity so that stack overflows don't get anywhere. Then have a script to restart it if it dies. Also don't allow recursion from outside machines. Another possibility is to have the port for outgoing connections be something other than 53 (54 seems unused) and use iptables or ipchains to block data from the outside world coming to port 53. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: virtual hosting
On Tue, 26 Mar 2002 15:49, Michal Novotny wrote: It is possible to make virtual web hosting (apache) in chroot jail? Yes. Just install complete copies of Debian in the chroot jails. There is a little problem with about 1500 domains/clients. How can I set it up (with perl/php/ssi/ssl/cgi/ftp/mysql etc.) ? I think it have to be all in the chrooted directory, so will it be apache/perl/mysql/libs for each domain? or could it be symlinked? Symlinks do not work across chroot jails by definition. I do not imagine about 1500 chroots... You would need to have a lot of memory and CPU power for that many chroot's. But I think if it can work then it will be so secure, isn't it? If it has root access for ANYTHING and it uses a stock kernel then running it chroot gives no extra protection. If you want chroot to actually give you any significant security benefits then you need a kernel patch such as grsecurity. Let's leave debian-security out of this now and keep it on debian-isp. -- If you send email to me or to a mailing list that I use which has 4 lines of legalistic junk at the end then you are specifically authorizing me to do whatever I wish with the message and all other messages from your domain, by posting the message you agree that your long legalistic sig is void. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How efficient is mounting /usr ro?
On Fri, 17 Oct 2003 07:08, Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: A read-only /usr is not a security measure. Depends on your definition og it-security. It reduces downtime, prevents some admin and software failures and therefore is a security measure. So is a tape backup a security measure? What about a UPS? Is ECC memory a security measure? I guess it's a security measure to buy rack mount servers from companies such as Dell rather than assembling your own white-box machines then. :-# Security is about protection from unauthorised access and keeping the system running in the face of attack. A read-only /usr does not help this in the regular case as anyone who has permissions to modify files under /usr also has permissions to remount it read-write. Any measure you take to prevent remounting /usr will probably also prevent file writes as well, so having it mounted read-only gains little. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: How efficient is mounting /usr ro?
On Sat, 18 Oct 2003 07:07, Adam ENDRODI wrote: To stay on topic, I'm for keeping /usr and /usr/local read-only, because really nothing should update them except for a few programs under controlled circumstances (that's what makes the enforcment of this policy cheap). In addition, it might help you notice an intrusion. Unless you have a good auditing setup (none of the various auditing modules are available in Debian) then you probably won't notice an automated attack that is blocked by having a read-only file system. The attack may continue hitting you regularly until you remount it rw for an upgrade, at which time the attack will succeed. If you want security for such things then use SE Linux, systrace, RSBAC, or GRSEC. Don't waste time with ro mounts of /usr. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: How efficient is mounting /usr ro?
On Sat, 18 Oct 2003 23:36, Goswin von Brederlow wrote: Michael Stone [EMAIL PROTECTED] writes: A quiescent filesystem isn't going to be corrupted in a system crash. You need to have metadata inconsistencies caused by filesystem activity before you can get corruption. Which you get from time to time due to programs opening files read-write when possible, mtime and atime updates etc. Opening a file read-write does not necessarily imply actually writing to it. Programs that open read-write when they don't need to are broken, and they are actively being tracked down and fixed. Such programs get logged in the kernel message log in SE Linux and it's easy to track them down and fix them. As for atime, the -onoatime mount option takes care of it. I mount lots of file systems with noatime just to improve performance. One machine that I inspected had no writes to it's root file system during normal operations after noatime was installed. Anyway perhaps we should get a new mailing list debian-security-de for the German meaning of security. Then the rest of us can discuss crypto, MAC, and other things that match the English meaning of the word. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: How efficient is mounting /usr ro?
On Sun, 19 Oct 2003 03:44, Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: Anyway perhaps we should get a new mailing list debian-security-de for the German meaning of security. Then the rest of us can discuss crypto, MAC, and other things that match the English meaning of the word. Very funny. Personally I feel you are just short sighted, but if you like It's not a joke. This list was not created for discussions on how to avoid FSCK problems on servers that run all the time, debian-isp was created for that sort of thing. When an existing list doesn't fill a need then the best thing to do is to create a new list. If you get a debian-security-de list as I suggest then you can discuss things in German too, which should be a double benefit. me to shut p on this issues, I have no problem with that. However, how good is a box which cannot be hacked but can simply be DOSed? Name one DOS attack that is avoided by mounting /usr ro. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Why do system users have valid shells
On Wed, 22 Oct 2003 18:50, Tobias Reckhard wrote: also su user -c command won't work, you'll need to use sudo or suid bit, and that's a bit messy. This is true, when I need to su to this user's account (for troubleshooting, usually), I need to 'chsh -s /bin/bash mirror' first (and change it back later). However, I only need to do this very seldom. And I haven't ever needed to su to daemon, bin, sys, games, man, lp, mail, news, uucp, proxy, postgres, www-data, backup, operator, list, irc, gnats, nobody, amavis or cyrus. That's the list of user accounts with shell /bin/sh on my Debian box. Also I think it should be noted that even if there is some unusual administrative action that requires having a valid shell, the administrator could always change the shell, perform the action, then change it back. Having a valid shell all the time because it might be needed at some time is not a good idea. I recall that there was a bug in pam in unstable at one time that would allow logging in to those accounts. Setting the shells to /bin/false would have prevented that bug from being a problem. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Why do system users have valid shells
On Wed, 22 Oct 2003 19:27, Dariush Pietrzak wrote: 'su -s /bin/bash -c cmd user ' sounds like a very bs argument Do you understand the term 'breakage' ? Do you understand the term testing? How about the idea that changing something in the system may force to you to rewrite parts of code? Some of us have run fairly complete Linux machines for years with most of those accounts set to /bin/bash for their shell without any problems. I stopped doing that for two reasons, one is that upgrades of base-passwd whinged at me all the time, and the other is that I have little need for such measures now that I'm running SE Linux on all important machines. As most people who are interested in secure systems are not yet running SE Linux I think that there are some good benefits to be achieved by making the shells of those accounts be /bin/bash by default. As some people (such as myself) have run systems in such a manner for years without breakage I am quite confident that we can get these things right. We can start with bin, daemon, sys, and sync which are the least likely accounts to need a login shell. After those changes have been tested to everyone's satisfaction we can then move on to others. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Why do system users have valid shells
On Wed, 22 Oct 2003 20:00, Dariush Pietrzak wrote: Do you understand the term 'breakage' ? Do you understand the term testing? Why should I? Because some of us have already performed extensive tests on this when it was raised previously. The idea of giving non-login accounts a shell of /bin/false is hardly new. The question was - what can go wrong. Well, the thing I mentioned can go wrong. It's not a bs argument, and not even very bs argument, since I'm not arguing about anything, just pointing to potential source of problems. And before we can go on with testing maybe we should think for a second what could go wrong? If you ask question 'What can go wrong', answer 'ooh, probably nothing' has rather low informational value. Which is why in my answer I told you that I had run it for a period of years on a number of machines and not found problems. Some of us have run fairly complete Linux machines for years with most of those accounts set to /bin/bash for their shell without any problems. I /bin/bash? It's a typo, right? Yes, meant to say /bin/false. whinged at me all the time, and the other is that I have little need for such measures now that I'm running SE Linux on all important machines. Good for you, I envy you, I ain't got enough time to setup and maintain SE Linux on my machines. Which is why you can benefit from using /bin/false for such accounts. without breakage I am quite confident that we can get these things right. That's the point 'we can get these things right'. Of course we can, and we should, but I don't think we can just flip the switch and forget about this. The best course of action would be to gather possible sources of problems first, then test the change, etc.. So we start by getting some developers to test it (which has already been done). Then we get a version of base-passwd to change some of the shells in unstable (as it's only in unstable initially and users get asked whether they want to update /etc/passwd it should not be a problem). After that if we have no problems it will migrate into testing. Running around saying oh no things might break does not help. Do the tests and you'll find that very little breaks even if you change all non-user accounts to have /bin/false as the shell. Last time I tested this extensively the only thing that broke was man. I think I submitted a bug report against man-db about it, it may be fixed now. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
