Re: Attempts at security (was Re: Draft spec for new dpkg "triggers" feature)
On Sun, Feb 04, 2007 at 12:27:41PM +1100, Russell Coker wrote: > On Saturday 03 February 2007 23:47, Hendrik Sattler > <[EMAIL PROTECTED]> wrote: > > > It's disabled by default, unlike in Fedora and Red Hat Enterprise Linux > > > where it's on by default. I believe that the latest release of SUSE has > > > AppArmor on by default. > > RedHat has a long history of strange decisions. > Red Hat has a long history of making Linux easy to use. Try using Fedora and > Debian for the same sys-admin tasks and compare. You will discover that > right from the install Fedora is a lot easier. Of course the Debian > installer gives many options that the Fedora installer doesn't (degraded RAID > arrays and encrypted block devices as two examples), but it's a lot harder to > use. Any chance we could stick to arguing the technical case for SELinux, instead of inviting the thread to be further derailed in response to FUD about the usability of the Debian installer? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attempts at security (was Re: Draft spec for new dpkg "triggers" feature)
On Saturday 03 February 2007 23:47, Hendrik Sattler <[EMAIL PROTECTED]> wrote: > > It's disabled by default, unlike in Fedora and Red Hat Enterprise Linux > > where it's on by default. I believe that the latest release of SUSE has > > AppArmor on by default. > > RedHat has a long history of strange decisions. Red Hat has a long history of making Linux easy to use. Try using Fedora and Debian for the same sys-admin tasks and compare. You will discover that right from the install Fedora is a lot easier. Of course the Debian installer gives many options that the Fedora installer doesn't (degraded RAID arrays and encrypted block devices as two examples), but it's a lot harder to use. The "targeted" SE Linux policy was developed because the "strict" policy was too difficult to use for most of the Fedora user-base. > > You claim that almost all the examples I gave have problems. Please > > explain the problems that you believe to be in exec-shield, PIE, and > > poly-instantiated directories. Make sure that they are real examples not > > "a program might have some problem" claims. > > PIE: > http://www.linuxfromscratch.org/hlfs/view/unstable/uclibc/chapter02/pie.htm >l Does X already work with it? Mplayer is also name there and thus probably > xine (using these win32-DLLs), too? How about things like Mono? I don't recall anyone seriously suggesting compiling all programs with PIE, just the ones that are likely to be attacked. Mplayer does many nasty things (such as loading Windows DLLs). You can expect it to have problems that other programs don't have. > Exec-shield is related to it, AFAIK. Not really. > For the poly-instantiated views to directories, I am not sure that this is > thought to its end, yet. It's been around in various forms for more than 10 years, people have thought about it a lot. > The main usage will probably be /tmp but there are > already solutions for secure temp file creation. http://www.coker.com.au/selinux/talks/sage-2006/PolyInstantiatedDirectories.html There aren't any other solutions to the problems that are solved by PI-directories. Read my paper from the above URL and see if you can discover another solution. > Users may get confused why they do not see the same directory contents > althought the path is the same. Generally with PI-directories a user doesn't have the opportunity to see different views of the same directory so this isn't a problem. -- [EMAIL PROTECTED] http://etbe.blogspot.com/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attempts at security (was Re: Draft spec for new dpkg "triggers" feature)
Am Samstag 03 Februar 2007 02:21 schrieb Russell Coker: > On Saturday 03 February 2007 05:17, Hendrik Sattler > <[EMAIL PROTECTED]> wrote: > > And everybody gets the SE Linux overhead if he wants or not? > > It's disabled by default, unlike in Fedora and Red Hat Enterprise Linux > where it's on by default. I believe that the latest release of SUSE has > AppArmor on by default. RedHat has a long history of strange decisions. > > The current > > system does not give you perfect security but neither does adding SE > > Linux. Instead, you probably get annoying permission problems. > > This is why every Windows user uses the administrator account for > everything. No, this is caused by other system design flaws and some bad software companies. Some learned and improved (Nero) and some didn't (Epson). But Microsoft probably had reason why they hide the file system ACL settings by default (hint: complexity). > > > You want features such as exec-shield, well you don't get them - > > > because of other people with the same attitude as you. > > > > Please differ between things that are pretty much automatic (even when > > not only using debian packages) and things that you need some days to > > setup correctly (if you ever manage to do so). > > And always think about the problems that you introduce with such things > > (and almost all you named have such). > > You claim that almost all the examples I gave have problems. Please > explain the problems that you believe to be in exec-shield, PIE, and > poly-instantiated directories. Make sure that they are real examples not > "a program might have some problem" claims. PIE: http://www.linuxfromscratch.org/hlfs/view/unstable/uclibc/chapter02/pie.html Does X already work with it? Mplayer is also name there and thus probably xine (using these win32-DLLs), too? How about things like Mono? Exec-shield is related to it, AFAIK. Since this is selective for every application, it is good. But everything that increases restrictions of whatever kind will hit a project that cannot handle this restriction. Not naming those in the same spot as advertising it does not really help... But you are right, most users and even programmers will never notice... For the poly-instantiated views to directories, I am not sure that this is thought to its end, yet. The main usage will probably be /tmp but there are already solutions for secure temp file creation. Although it can integrate with SE Linux, it does not require it. Users may get confused why they do not see the same directory contents althought the path is the same. HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attempts at security (was Re: Draft spec for new dpkg "triggers" feature)
On Feb 02, Russell Coker <[EMAIL PROTECTED]> wrote: > One of the enemies of security in Debian is the fact that every person > controls their little area and has no requirement to work towards common > goals (apart from the most obvious ones of making the system work). Things used to be different, before somebody spread the meme that policy must reflect usage and packages do not really need to follow it anyway. Does anybody else remember these times? -- ciao, Marco signature.asc Description: Digital signature
Re: Attempts at security (was Re: Draft spec for new dpkg "triggers" feature)
On Saturday 03 February 2007 05:17, Hendrik Sattler <[EMAIL PROTECTED]> wrote: > And everybody gets the SE Linux overhead if he wants or not? It's disabled by default, unlike in Fedora and Red Hat Enterprise Linux where it's on by default. I believe that the latest release of SUSE has AppArmor on by default. > The current > system does not give you perfect security but neither does adding SE Linux. > Instead, you probably get annoying permission problems. This is why every Windows user uses the administrator account for everything. > Name a few guys that really likes to use this on a private machine and some > real-life improvements that it brings. Hint: "increased security" is not an > argument. SE Linux is enabled by default in Fedora. I believe that the majority of Fedora users don't even know it's there. Their machine just works and tends not to get cracked. > > You want features such as exec-shield, well you don't get them - because > > of other people with the same attitude as you. > > Please differ between things that are pretty much automatic (even when not > only using debian packages) and things that you need some days to setup > correctly (if you ever manage to do so). > And always think about the problems that you introduce with such things > (and almost all you named have such). You claim that almost all the examples I gave have problems. Please explain the problems that you believe to be in exec-shield, PIE, and poly-instantiated directories. Make sure that they are real examples not "a program might have some problem" claims. -- [EMAIL PROTECTED] http://etbe.blogspot.com/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attempts at security (was Re: Draft spec for new dpkg "triggers" feature)
Am Freitag 02 Februar 2007 13:49 schrieb Russell Coker: > One of the enemies of security in Debian is the fact that every person > controls their little area and has no requirement to work towards common > goals (apart from the most obvious ones of making the system work). > > This means that instead of having a little cooperation from other > developers anyone who wants to get a significant change included will have > to fight hundreds of battles. > > SE Linux is a classic example of this. Debian could have had SE Linux > support long before Fedora, but instead it gets it long afterwards. > > The same battles occur with regard to all the other security measures I > mentioned (and some others I didn't). We could made Debian the most secure > Linux distribution, there are many people who have the skills and the > interest in doing so. And everybody gets the SE Linux overhead if he wants or not? The current system does not give you perfect security but neither does adding SE Linux. Instead, you probably get annoying permission problems. Name a few guys that really likes to use this on a private machine and some real-life improvements that it brings. Hint: "increased security" is not an argument. Not being able to change the cause to the better doesn't mean to introduce a mess to control the result. And I really hope that Debian never considers installing+enabling selinux by default. > You want features such as exec-shield, well you don't get them - because of > other people with the same attitude as you. Please differ between things that are pretty much automatic (even when not only using debian packages) and things that you need some days to setup correctly (if you ever manage to do so). And always think about the problems that you introduce with such things (and almost all you named have such). HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attempts at security (was Re: Draft spec for new dpkg "triggers" feature)
On Fri, Feb 02, 2007 at 11:49:23PM +1100, Russell Coker wrote: > > One of the enemies of security in Debian is the fact that every person > controls their little area and has no requirement to work towards common > goals (apart from the most obvious ones of making the system work). > > This means that instead of having a little cooperation from other developers > anyone who wants to get a significant change included will have to fight > hundreds of battles. This is not a bug, it is a feature ;-) Regards, Paddy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attempts at security (was Re: Draft spec for new dpkg "triggers" feature)
On Friday 02 February 2007 22:21, Ian Jackson <[EMAIL PROTECTED]> wrote: > > > If you want a general purpose hook, or some crazy SE-Linux-specific > > > feature, then you should probably propose one. Personally I think a > > > general purpose hook feature would probably be abused so should not be > > > provided, and I think SE-Linux is no more than an interesting research > > > project and should not be deployed (ever) so obviously we shouldn't > > > have any code in dpkg for it. > > > > I'm curious, do you have the same attitude towards non-executable stack > > (Exec-Shield/PaX/OpenWall), Poly-Instantiated directories, and PIE > > executables? > > This is rather off-topic So let's move it back to debian-devel where it's on-topic. > but since you ask, no, I don't have the same > attitude towards those. My objection to SE Linux is based on the > complexity required to make anything of it, and as we all know > complexity is the enemy of security. SE Linux makes the situation > worse, not better. One of the enemies of security in Debian is the fact that every person controls their little area and has no requirement to work towards common goals (apart from the most obvious ones of making the system work). This means that instead of having a little cooperation from other developers anyone who wants to get a significant change included will have to fight hundreds of battles. SE Linux is a classic example of this. Debian could have had SE Linux support long before Fedora, but instead it gets it long afterwards. The same battles occur with regard to all the other security measures I mentioned (and some others I didn't). We could made Debian the most secure Linux distribution, there are many people who have the skills and the interest in doing so. You want features such as exec-shield, well you don't get them - because of other people with the same attitude as you. > > I'm just wondering if you want Debian to have less security than > > Fedora in all areas. > > Have you stopped beating your wife ? No Ian, it was an entirely serious and sensible question. If you wanted no extra security features then your attitude would make sense. If you want features in other areas then the best strategy for you to adopt would be to refrain from actively preventing work on adding optional features that you don't intend to use. When you take a deliberately obstructive attitude towards my SE Linux work it means that I have less time to work on other projects - many of which are related to improving Debian security. -- [EMAIL PROTECTED] http://etbe.blogspot.com/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development
