I was just wondering how AppArmor and vsftpd will react if one enables the vsftpd option chroot_local_user=YES on /etc/vsftpd.conf Correct me if I am wrong, but as much as i understood, AA is for protecting data integrety as chroot jails for creating user confinement. In that case the combination of both will be a very good compromise in security vs performance or it's just a bit overkill ? Miguel Albuquerque Network Administrator DISCLAIMER - This message is intended for the use of the named person only. The information contained in this E-mail is confidential and any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited. This message does not represent a formal commitment by Codalis SA. Codalis SA is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt.
The protections offered by chroot are redundant with the protections offered by AppArmor. You can use both at the same time, and stuff will "just work". However, the combination is slightly *less* secure than AppArmor alone. Details here http://lists.suse.com/archive/suse-security/2006-Jul/0026.html So do this: * If you *must* use chroot, then use AA anyway, as the combination is more secure than chroot alone. * If you don't have to use chroot, then turn chroot off and use AA by itself, as AA alone is more secure than AA+chroot. Crispin Miguel ALBUQUERQUE wrote:
I was just wondering how AppArmor and vsftpd will react if one enables the vsftpd option chroot_local_user=YES on /etc/vsftpd.conf
Correct me if I am wrong, but as much as i understood, AA is for protecting data integrety as chroot jails for creating user confinement. In that case the combination of both will be a very good compromise in security vs performance or it's just a bit overkill ?
*Miguel Albuquerque** Network Administrator* signature http://www.codalis.ch/
DISCLAIMER - This message is intended for the use of the named person only. The information contained in this E-mail is confidential and any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited. This message does not represent a formal commitment by Codalis SA. Codalis SA is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt.
-- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com Hack: adroit engineering solution to an unanticipated problem Hacker: one who is adroit at pounding round pegs into square holes
Which system is obviously marking such mails as SPAM and why!? On Sat, 5 Aug 2006, Crispin Cowan wrote:
The protections offered by chroot are redundant with the protections offered by AppArmor.
Hi Crispin. Don't forget to mention that he should find all and every hard/soft link to the server and refer to the AppArmor profile (is this possible? Otherwise *copy* the Profile <shiver/>) for the case that a link instead of the "original" binary is used. <sigh/> Regards Henning Hucke -- Single tasking: Just Say No.
Henning Hucke wrote:
Which system is obviously marking such mails as SPAM and why!?
I have no idea :(
On Sat, 5 Aug 2006, Crispin Cowan wrote:
The protections offered by chroot are redundant with the protections offered by AppArmor.
Don't forget to mention that he should find all and every hard/soft link to the server and refer to the AppArmor profile (is this possible? Otherwise *copy* the Profile <shiver/>) for the case that a link instead of the "original" binary is used. <sigh/>
Well, no, that is not correct. AppArmor offers no protection for unconfined processes. You cannot force someone with an unconfined shell to only execute programs under an AppArmor profile, because they can just copy the program itself to another place and run it. If you want to defend your system against a shell user, you must confine their shell in the first place. If you have confined their shell, then you only give them execute permissions to the programs you want them to be able to execute, and under the policies you desire. You don't need to worry about strange aliases, because the confined shell has no permission to execute them anyway. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com Hack: adroit engineering solution to an unanticipated problem Hacker: one who is adroit at pounding round pegs into square holes
On Thu, 17 Aug 2006, Crispin Cowan wrote:
[...] Well, no, that is not correct.
Effectively you blame the german iX magazine to talk rubbish. The point is: as long as the maintainer doesn't work with the necessary care a server might be started in a protected environment if started "normaly" and in an unprotected environment if started for instance chrooted _despite_ the fact that one and the same binary - for instance via a hardlink - is used. The underlaying mechanisms which are used for instance by selinux protect _everything_ which uses the protected binary might it be a hardlink or a softlink. This smells like AppArmor droped security in favor of ease of use for not so firm people. No good deal! SuSE Linux more and more drifts towards "another Windows". In the meantime I know a lot of people - amongst them are numerous administrators which I personally rate as good or very good ones - who already droped SuSE in favor of Debian or comparable distributions. Mind that. I personally will install the coming (already released?) SuSE 10.2 on my machines and if it will not attract me the installation after this one will be debian. But still: Maybe I'm unfair to SuSE/Novell. If it should be the case that I already have the *alternatives* selinux _or_ AppArmor I would have to take the above critics. What I want to have is the choice! Give other users a tool at hand with which they might secure their machines in obscurity as long as you give _me_ the tools at hand to really secure the machines under my administration.
[...]
Best regards Henning Hucke -- Mountain Dew and doughnuts... because breakfast is the most important meal of the day.
Henning Hucke wrote:
SuSE Linux more and more drifts towards "another Windows". In the meantime I know a lot of people - amongst them are numerous administrators which I personally rate as good or very good ones - who already droped SuSE in favor of Debian or comparable distributions.
Mind that.
I personally will install the coming (already released?) SuSE 10.2 on my machines and if it will not attract me the installation after this one will be debian.
But still: Maybe I'm unfair to SuSE/Novell. If it should be the case that I already have the *alternatives* selinux _or_ AppArmor I would have to take the above critics. What I want to have is the choice! Give other users a tool at hand with which they might secure their machines in obscurity as long as you give _me_ the tools at hand to really secure the machines under my administration.
Let me get this straight: You're trashing SuSE because AppArmor isn't the be-all / end-all of perfect security perfection, so you're going to use a distribution that doesn't even have AppArmor at all? AppArmor is a tool. It's meant to help a server deal with possibly insecure software without the extra hassles of chroot. As far as I can tell, it works very well in that task. However, as you say, it's not going to stop people who already have shell access from doing naughty things. It never claimed to. Ease of use is not some windows concept. AppArmor is nice and easy to use for the task it was meant to do, and that's a good thing. The more complicated something is, the better chance it gets screwed up. It also frees up my time to take care of other tasks. Are you some kind of masochist that you'd rather make your life harder? If you need user-level security, go with SELinux. The right tool for the right job. Many administrators are taking a hard look at Debian and CentOS for one reason: Package management. SuSE completely and utterly screwed the pooch with the whole zen/rug garbage. AppArmor, however, has been a major plus in SuSE's favor, imho.
suse@rio.vg wrote on 18.08.2006 14:59:40:
Henning Hucke wrote:
SuSE Linux more and more drifts towards "another Windows". In the meantime I know a lot of people - amongst them are numerous administrators which I personally rate as good or very good ones - who already droped SuSE in favor of Debian or comparable distributions.
Mind that.
I personally will install the coming (already released?) SuSE 10.2 on
my
machines and if it will not attract me the installation after this one
will be debian.
But still: Maybe I'm unfair to SuSE/Novell. If it should be the case that I already have the *alternatives* selinux _or_ AppArmor I would have to take the above critics. What I want to have is the choice! Give other users a tool at hand with which they might secure their machines in obscurity as long as you give _me_ the tools at hand to really secure the machines under my administration.
Let me get this straight: You're trashing SuSE because AppArmor isn't the be-all / end-all of perfect security perfection, so you're going to use a distribution that doesn't even have AppArmor at all?
AppArmor is a tool. It's meant to help a server deal with possibly insecure software without the extra hassles of chroot. As far as I can tell, it works very well in that task.
However, as you say, it's not going to stop people who already have shell access from doing naughty things. It never claimed to. Ease of use is not some windows concept. AppArmor is nice and easy to use for the task it was meant to do, and that's a good thing. The more complicated something is, the better chance it gets screwed up. It also frees up my time to take care of other tasks. Are you some kind of masochist that you'd rather make your life harder?
If you need user-level security, go with SELinux. The right tool for the right job.
Seems a pretty good approach : the right tool for the right job ! Personnaly I've choosen AA by exactly the same reasons above : gives me time to take care of other tasks. Have fun ! Miguel Albuquerque Network Administrator DISCLAIMER - This message is intended for the use of the named person only. The information contained in this E-mail is confidential and any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited. This message does not represent a formal commitment by Codalis SA. Codalis SA is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt.
Henning Hucke wrote:
On Thu, 17 Aug 2006, Crispin Cowan wrote:
[...] Well, no, that is not correct.
Effectively you blame the german iX magazine to talk rubbish.
Sorry, I can't read German, so I wouldn't know.
The point is: as long as the maintainer doesn't work with the necessary care a server might be started in a protected environment if started "normaly" and in an unprotected environment if started for instance chrooted _despite_ the fact that one and the same binary - for instance via a hardlink - is used. How could that happen?
* Deliberately: the administrator went to some effort to make a copy of the program and run it in an alternate configuration. * Maliciously: someone was given a shell and abused it, or they escaped from an *unconfined* service and started doing other stuff. In any of these cases, the person doing the bad thing already has an unconfined root shell. The game is already over; that they can start another process without AA confinement is uninteresting compared to the fact that they can now rootkit the machine.
The underlaying mechanisms which are used for instance by selinux protect _everything_ which uses the protected binary might it be a hardlink or a softlink.
The difference you highlight is that SELinux provides for a default policy that applies if no other, more specific policy applies. We have studied providing a default policy mechanism in AA, but it has this problem: * The default policy must be "tight" enough that it at least prevents the attacker from breaking AppArmor itself. Otherwise the attacker first breaks AA, and then does whatever else they want, and the default policy is no more than a speed bump. * The default policy must be "loose" enough that administrative programs like RPM, YaST, ZMD, etc., and the AA administrative software itself, can do their work. Otherwise we would need to provide a specific policy for each one of these that is loose enough for them to do their jobs. The intersection of "tight enough" and "loose enough" is the null set. A speed bump is an unacceptably weak security mechanism. So the only alternative is to provide specific policies for every administrative program. So we will not be provisioning a default policy until at least we can do that. Instead, we provide the aa-unconfined program. Go run it on your SUSE10.*, SLES10, or SLED10 machine, and see that it reports a bunch of programs listening to open network ports, and the AA profiles wrapped around those programs. If all open network ports lead to AA-confined programs, then as far as network attackers are concerned, your machine is "completely" confined, even though you are no where near having profiled everything on the machine. If, in the attack Henning is concerned about here, you some how managed to start a program without an AA profile, then the aa-unconfined scanner will detect it. If you are very worried about that, then set up aa-unconfined to run in a cron job and alert you if it sees a problem. Something like this should do the trick: aa-unconfined | grep "not confined" | mail root@example.com SELinux, in contrast, does have a default policy. This is part of why SELinux is so difficult to use in practice.
This smells like AppArmor droped security in favor of ease of use for not so firm people. No good deal!
That is exactly what AppArmor did: * SELinux: Lets build a secure system, and then start trying to make it usable. Result: painful-to-use system that is completely foreign to UNIX administrators. * AppArmor: Lets try to make UNIX/Linux more secure, while still being UNIX. Result: transparent UNIX-like mechanisms that help make your machine more secure. People choosing SELinux after considering AppArmor happens approximately never. People choosing neither SELinux nor AppArmor and instead remaining "naked" because it is too much bother happens all the time. I am happy with the decision to emphasize ease of use in AppArmor, as it means that we can help many, many more people than if we had sacrificed usability to enhance security.
SuSE Linux more and more drifts towards "another Windows". I think it is a bit absurd to claim that SUSE is becoming "another Windows" every time we add a usability feature. In this case, we have added a feature that makes Linux much more secure than anything Windows has. It is also much more secure than a common Red Hat machine, in which SELinux has been disabled because it was too annoying :)
In the meantime I know a lot of people - amongst them are numerous administrators which I personally rate as good or very good ones - who already droped SuSE in favor of Debian or comparable distributions.
Mind that.
I do mind that. This is why, even though AppArmor is fully integrated into YaST, that is only a graphical gloss on top of AppArmor. A the core, AppArmor is command-line driven, making it fast and easy for the power user to use, works well over slow SSH connections, and is scriptable.
I personally will install the coming (already released?) SuSE 10.2 on my machines and if it will not attract me the installation after this one will be debian.
But still: Maybe I'm unfair to SuSE/Novell. If it should be the case that I already have the *alternatives* selinux _or_ AppArmor I would have to take the above critics. What I want to have is the choice! Give other users a tool at hand with which they might secure their machines in obscurity as long as you give _me_ the tools at hand to really secure the machines under my administration.
SELinux and AppArmor cannot share the same machine. Integrating SELinux into SUSE would require lots and lots of work, and instead we put those resources towards making AppArmor better. There are many other places users can get SELinux, so the community gets choice. The number of users who would actually choose SELinux over AppArmor, after having tried both, is very small, so we thought it better to just concentrate on AppArmor. And there is opensuse.org where you can use the portal to build any RPM packages for SUSE that you want. If you want SELinux in SUSE, you can actually do it yourself. Personally, my experience is that every time I direct an engineer to work on SELinux, after a while they threaten to quit if I don't change their assignment :) Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com Hack: adroit engineering solution to an unanticipated problem Hacker: one who is adroit at pounding round pegs into square holes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2006-08-17 at 18:53 -0700, Crispin Cowan wrote:
Henning Hucke wrote:
Which system is obviously marking such mails as SPAM and why!?
I have no idea :(
SuSE. See the headers of Miguel's email: X-Virus-Scanned: by amavisd-new at Relay2.suse.de X-Spam-Status: Yes, hits=5.2 tagged_above=-20.0 required=5.0 tests=BAYES_50, FORGED_RCVD_HELO, HTML_30_40, HTML_IMAGE_ONLY_16, HTML_MESSAGE, HTML_SHORT_LINK_IMG_2, MIME_BASE64_NO_NAME, RCVD_IN_WHOIS_BOGONS X-Spam-Level: ***** X-Spam-Flag: YES So, Relay2.suse.de is the culprit. Typically it is the Bayes test, but not for this one. It is much worse in suse-linux-s: X-Virus-Scanned: by amavisd-new at Relay1.suse.de X-Spam-Status: Yes, hits=5.2 tagged_above=-20.0 required=5.0 tests=BAYES_99, DNS_FROM_RFC_ABUSE X-Spam-Level: ***** X-Spam-Flag: YES There the bayessian filter needs to be retrained. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFE5bKGtTMYHG2NR9URAvZ5AJ0Tp3HDyu+1t0pWwLPnRnwVtgFxXQCeI6th WtEwmauZ1waAw3IUpfoTqAM= =Fwhn -----END PGP SIGNATURE-----
On Fri, Aug 18, 2006 at 02:28:53PM +0200, Carlos E. R. wrote:
The Thursday 2006-08-17 at 18:53 -0700, Crispin Cowan wrote:
Henning Hucke wrote:
Which system is obviously marking such mails as SPAM and why!?
I have no idea :(
SuSE.
See the headers of Miguel's email:
X-Virus-Scanned: by amavisd-new at Relay2.suse.de X-Spam-Status: Yes, hits=5.2 tagged_above=-20.0 required=5.0 tests=BAYES_50, FORGED_RCVD_HELO, HTML_30_40, HTML_IMAGE_ONLY_16, HTML_MESSAGE, HTML_SHORT_LINK_IMG_2, MIME_BASE64_NO_NAME, RCVD_IN_WHOIS_BOGONS X-Spam-Level: ***** X-Spam-Flag: YES
So, Relay2.suse.de is the culprit. Typically it is the Bayes test, but not for this one. It is much worse in suse-linux-s:
X-Virus-Scanned: by amavisd-new at Relay1.suse.de X-Spam-Status: Yes, hits=5.2 tagged_above=-20.0 required=5.0 tests=BAYES_99, DNS_FROM_RFC_ABUSE X-Spam-Level: ***** X-Spam-Flag: YES
It got more relaxed now. At some point in time we will switch lists.suse.com to the new mailinglist system (as running on opensuse.org) and fix spam handling. Ciao, Marcus
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2006-08-18 at 14:31 +0200, Marcus Meissner wrote:
It got more relaxed now.
True, about last week it tagged about half of the spanish list as spam. This week it is not happening, it seems.
At some point in time we will switch lists.suse.com to the new mailinglist system (as running on opensuse.org) and fix spam handling.
Good! :-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFE5bUqtTMYHG2NR9URArF5AJ9J5ckiGTq6GoJtLbqcK9h9nMWPOgCdHaEY 60PhkX9+1KVVSIc3H7EbC2M= =Gt6t -----END PGP SIGNATURE-----
participants (6)
-
Carlos E. R. -
Crispin Cowan -
Henning Hucke -
Marcus Meissner -
Miguel ALBUQUERQUE -
suse＠rio.vg