Re: [Cooker] security audit
Thierry Vignaud wrote: Henri <[EMAIL PROTECTED]> writes: sorry, i don't have any idea of the time needed to audit something like drakconf... there's not so many points where we exec some process or write some files in drakconf, so this one is easy. but when you talk about drakconf, i suspect you really want to says "drakconf + all the toolts it runs", don't you ? Yes, of course. That would not make any sense to suggest to audit drakconf but not every *drake tool. this is of course much more work Of cours ! Building a secure, easy, optimized...ecc OS is definitly a long and hard work ! I agree that performing an audit on Mandrake tools is important, it's laughable to suggest we audit every piece of software we include. Not every sofware : i was only asking about specific mandrake tools and "critical" ones : i think about verifying a last time, just before releasing, that permissions on tools installed in /sbin/ and /usr/sbin are correct, for example... If fact, my question is : what is done about security before a new release ? Is there a specific "security last step", as there is a features freeze ecc. ? not much is done. it may be good that such works is done by people other than mdk developers. it would be nice if some volunters check and reports strange things Why not trying to develop some partnership with engineer schools ? I think mandrake team could go and meet students, offering Cooker CDs and ask students to test it, or organize a "debug party" : one day with students and mandrake team, testing things and correcting bugs "on the fly" : that would be great for students, would be a good publicity, and would be useful... Of course this does not concerns security fixes. But if students are in the abbit of working with mandrake, perhaps they will have the idea to join or create projects around it.
Re: [Cooker] security audit
Henri <[EMAIL PROTECTED]> writes: > sorry, i don't have any idea of the time needed to audit something > like drakconf... there's not so many points where we exec some process or write some files in drakconf, so this one is easy. but when you talk about drakconf, i suspect you really want to says "drakconf + all the toolts it runs", don't you ? this is of course much more work > > I agree that performing an audit on Mandrake tools is important, > > it's laughable to suggest we audit every piece of software we > > include. > > Not every sofware : i was only asking about specific mandrake tools > and "critical" ones : i think about verifying a last time, just > before releasing, that permissions on tools installed in /sbin/ and > /usr/sbin are correct, for example... > If fact, my question is : what is done about security before a new > release ? Is there a specific "security last step", as there is a > features freeze ecc. ? not much is done. it may be good that such works is done by people other than mdk developers. it would be nice if some volunters check and reports strange things
Re: [Cooker] security audit
On Fri, 14 Mar 2003, Henri wrote: > Not every sofware : i was only asking about specific mandrake tools and > "critical" ones : i think about verifying a last time, just before > releasing, that permissions on tools installed in /sbin/ and /usr/sbin > are correct, for example... FYI, rpmlint does permission checks (suid, setgid etc), but some software is purposely shipped with setuid. For one, smbmount is, since I would rather have smbmount setuid than have a newbie run as root since he can smbmount (via komba2 or something). The astute admin will probably not even want samba-client on his server. Unfortunately, some things have to make security take a back seat. But smbmount (actually, smbmnt) is supposed to be pretty secure, aimed at being setuid. Regards, Buchan -- |Registered Linux User #182071-| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7
Re: [Cooker] security audit
Vincent Danen wrote: On Thu Mar 13, 2003 at 08:26:23PM +0100, Henri wrote: OpenSource is said to be more secure : a question has come to my mind : before releasing the 9.1, will there be a security audit on critical apps, on drakconf tools ecc. or not ? Perhaps this would avoid big holes like the shutdown one, no ? You're kidding, right? A security audit in two days? sorry, i don't have any idea of the time needed to audit something like drakconf... I agree that performing an audit on Mandrake tools is important, it's laughable to suggest we audit every piece of software we include. Not every sofware : i was only asking about specific mandrake tools and "critical" ones : i think about verifying a last time, just before releasing, that permissions on tools installed in /sbin/ and /usr/sbin are correct, for example... If fact, my question is : what is done about security before a new release ? Is there a specific "security last step", as there is a features freeze ecc. ? Thanks for your explainations. No other vendor has done this, even those who profess to have secure Linux distros. The only exception to this is OpenBSD, but they also still ship BIND4 IIRC. The "big hole" in shutdown is a configuration flaw, not necessarily a flaw in any one program. A mistake was made in assuming that removing /usr/bin/shutdown was enough; this was proven to be inaccurate. To completely remove this, the /etc/pam.d/shutdown file needs to be removed as well... consolehelper doesn't really do anything on it's own other than talk to pam, and pam was still allowing it. So a config file needs to removed. Yes, little things like this need to be checked and avoided. But asking us to do a wholesale security audit based on this one situation is not entirely realistic.
Re: [Cooker] security audit
Levi Ramsey wrote: On Fri Mar 14 13:45 -0500, scott chevalley wrote: or, even more simply, resetting the bios, either by removing the cmos battery, or in some computers there is a cmos clear pin header. short the pins and it clears cmos, including passwords That wouldn't disable the LILO password, though... true, but it would allow someone with a boot disk or cd to boot the system...
Re: [Cooker] security audit
On Fri Mar 14 13:45 -0500, scott chevalley wrote: > or, even more simply, resetting the bios, either by removing the cmos > battery, or in some computers there is a cmos clear pin header. short > the pins and it clears cmos, including passwords That wouldn't disable the LILO password, though... -- Levi Ramsey [EMAIL PROTECTED] [EMAIL PROTECTED] The food of love is Mandrake root. GPG Fingerprint: 354C 7A02 77C5 9EE7 8538 4E8D DCD9 B4B0 DC35 67CD Currently playing: Apocalyptica - Nothing Else Matters Linux 2.4.21-0.13mdk 15:20:00 up 2 days, 1:26, 13 users, load average: 0.01, 0.03, 0.04
Re: [Cooker] security audit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Straight wrote: > On Friday 14 March 2003 11:11 am, Levi Ramsey wrote: > >>If someone has physical access to the computer they can pass their own >>parameters to the kernel, including init=/bin/bash, whcih, bada bing >>bada boom, gives them instant root. > > > man lilo - you can restrict it from allowing cmdline, or even booting > altogether wihout a pw. > BTW, if you haven't tried: # msec 4 you should (at least on a server machine). Many of the settings there rock (IIRC it restricts by default if you installed in level 4), such as not showing OS details in a getty etc etc ... Regards, Buchan - -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+cjTYrJK6UGDSBKcRAghBAKCcmWVnou3LVCH3988CTPCjJ35mCACgmecF 1XgtEY+VjUAzs7sDNMfZ4FY= =ZAHh -END PGP SIGNATURE-
Re: [Cooker] security audit
On Fri, 2003-03-14 at 17:07, Vincent Danen wrote: > On Fri Mar 14, 2003 at 03:11:24PM +, Adam Williamson wrote: > > > Not entirely. You also have to lock your case shut somehow to stop > > someone opening it up and flicking the BIOS reset... > > > > Anyway, in regards to the original bug, this isn't purely a local > > exploit, surely? Doesn't it also apply to someone ssh'ing in from a > > remote site? i.e., I could give a simple user account to someone in > > Australia, thinking it's safe, and they could then ssh in and use this > > exploit to get a root shell? > > No. This is a console-only thing, driven by pam. pam only allows users at > a physical console access to this. Same with halt and reboot, which act as > expected. Aha, good. :) -- adamw
Re: [Cooker] security audit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 14 March 2003 17:59, Levi Ramsey wrote: > On Fri Mar 14 11:52 -0500, Jason Straight wrote: > > On Friday 14 March 2003 11:11 am, Levi Ramsey wrote: > > > If someone has physical access to the computer they can pass their own > > > parameters to the kernel, including init=/bin/bash, whcih, bada bing > > > bada boom, gives them instant root. > > > > man lilo - you can restrict it from allowing cmdline, or even booting > > altogether wihout a pw. > > Still, if someone has physical access to the computer, there's no > stopping them from opening it, removing the drive, mounting it > themselves, and editing the boot-sector to disable the password ;o) use an encrypted fs then:o) - -- Regards, Per Øyvind Karlsen Sintrax Solutions http://www.sintrax.net - +47 41681061 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+cjCBv8F7V9JOSuURAvSpAJ9cmew2atRnWw5wPfbTiMSc42Y+lwCguww/ w399+xqSLr7GtMz2C3MQyuE= =oee+ -END PGP SIGNATURE-
Re: [Cooker] security audit
Levi Ramsey wrote: On Fri Mar 14 11:52 -0500, Jason Straight wrote: On Friday 14 March 2003 11:11 am, Levi Ramsey wrote: If someone has physical access to the computer they can pass their own parameters to the kernel, including init=/bin/bash, whcih, bada bing bada boom, gives them instant root. man lilo - you can restrict it from allowing cmdline, or even booting altogether wihout a pw. Still, if someone has physical access to the computer, there's no stopping them from opening it, removing the drive, mounting it themselves, and editing the boot-sector to disable the password ;o) or, even more simply, resetting the bios, either by removing the cmos battery, or in some computers there is a cmos clear pin header. short the pins and it clears cmos, including passwords
Re: [Cooker] security audit
On Fri Mar 14, 2003 at 03:11:24PM +, Adam Williamson wrote:
> Not entirely. You also have to lock your case shut somehow to stop
> someone opening it up and flicking the BIOS reset...
>
> Anyway, in regards to the original bug, this isn't purely a local
> exploit, surely? Doesn't it also apply to someone ssh'ing in from a
> remote site? i.e., I could give a simple user account to someone in
> Australia, thinking it's safe, and they could then ssh in and use this
> exploit to get a root shell?
No. This is a console-only thing, driven by pam. pam only allows users at
a physical console access to this. Same with halt and reboot, which act as
expected.
--
MandrakeSoft Security; http://www.mandrakesecure.net/
Online Security Resource Book; http://linsec.ca/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
pgp0.pgp
Description: PGP signature
Re: [Cooker] security audit
On Fri Mar 14 11:52 -0500, Jason Straight wrote: > On Friday 14 March 2003 11:11 am, Levi Ramsey wrote: > > If someone has physical access to the computer they can pass their own > > parameters to the kernel, including init=/bin/bash, whcih, bada bing > > bada boom, gives them instant root. > > man lilo - you can restrict it from allowing cmdline, or even booting > altogether wihout a pw. Still, if someone has physical access to the computer, there's no stopping them from opening it, removing the drive, mounting it themselves, and editing the boot-sector to disable the password ;o) -- Levi Ramsey [EMAIL PROTECTED] [EMAIL PROTECTED] The food of love is Mandrake root. GPG Fingerprint: 354C 7A02 77C5 9EE7 8538 4E8D DCD9 B4B0 DC35 67CD Currently playing: Metallica - Welcome Home (Sanitarium) Linux 2.4.21-0.13mdk 11:50:00 up 1 day, 21:56, 13 users, load average: 0.01, 0.11, 0.19
Re: [Cooker] security audit
On Friday 14 March 2003 11:11 am, Levi Ramsey wrote: > If someone has physical access to the computer they can pass their own > parameters to the kernel, including init=/bin/bash, whcih, bada bing > bada boom, gives them instant root. man lilo - you can restrict it from allowing cmdline, or even booting altogether wihout a pw. -- Jason Straight [EMAIL PROTECTED] icq: 1796276 pgp: http://www.JeetKuneDoMaster.net/~jason/pubkey.asc
Re: [Cooker] security audit
On Friday 14 March 2003 09:56 am, scott chevalley wrote: > perhaps not by default, but if you type > linux single init=/bin/sh > > at a lilo prompt (or grub, but it would look different), you can bypass > any security on the system except for encrypted filesystem security, as > far as I'm aware. Besides, with all the knoppix based CD distro's out > there, including one that fits on a business card CD, anyone can boot > the pc with that and Knoppix will automatically mount all the > recognizable partitions as it boots.. > > Just my 0.02 > > Scott Dont overlook lilo's security - my laptop is setup to boot HD only, bios settings are pw protected. Lilo will boot linux without a password but requires a password if any cmdline options are given to lilo with a kernel, so it still stops people from booting with an external disk, and can't boot single mode. -- Jason Straight [EMAIL PROTECTED] icq: 1796276 pgp: http://www.JeetKuneDoMaster.net/~jason/pubkey.asc
Re: [Cooker] security audit
On Fri Mar 14 9:23 -0500, jokerman64 wrote: > I disagree, i don't think that if you go into single user mode that you should > be root. You should still have to log in. The argument that someone has > physical access to your computer thus making it your problem and not an > exploit is IMHO fallacious. No one should be able to get root that easily. If someone has physical access to the computer they can pass their own parameters to the kernel, including init=/bin/bash, whcih, bada bing bada boom, gives them instant root. The moral of this is that if your computer is not physically secure it will never be secure. This is not saying that there's no point in making it closer to secure; just that there's a limit to how secure you can make it. In addition, some of the extremely high-security measures are pointless on a non-physically-access controlled system. -- Levi Ramsey [EMAIL PROTECTED] [EMAIL PROTECTED] The food of love is Mandrake root. GPG Fingerprint: 354C 7A02 77C5 9EE7 8538 4E8D DCD9 B4B0 DC35 67CD Currently playing: Monster Magnet - Space Lord Linux 2.4.21-0.13mdk 11:00:03 up 1 day, 21:06, 13 users, load average: 0.33, 0.38, 0.34
Re: [Cooker] security audit
Adam Williamson <[EMAIL PROTECTED]> writes: > Anyway, in regards to the original bug, this isn't purely a local > exploit, surely? Doesn't it also apply to someone ssh'ing in from a > remote site? i.e., I could give a simple user account to someone in > Australia, thinking it's safe, and they could then ssh in and use this > exploit to get a root shell? No. -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] security audit
On Friday 14 March 2003 10:11 am, Adam Williamson wrote: > Not entirely. You also have to lock your case shut somehow to stop > someone opening it up and flicking the BIOS reset... > > Anyway, in regards to the original bug, this isn't purely a local > exploit, surely? Doesn't it also apply to someone ssh'ing in from a > remote site? i.e., I could give a simple user account to someone in > Australia, thinking it's safe, and they could then ssh in and use this > exploit to get a root shell? Yeah, I just wasn't going that in depth. Of course for real physical security, you should install your systems inside a farraday cage so no one can use eavesdropping methods to get your passes too. Just the point that single mode isn't really a weakness, no more than being able to run bash as root is. If someone is allowed to get to single mode without supplying some form of security authentication then the administrator has already failed his job of being physically secure. May as well just log in as root at the console and leave it unlocked that way. :) -- Jason Straight [EMAIL PROTECTED] icq: 1796276 pgp: http://www.JeetKuneDoMaster.net/~jason/pubkey.asc
Re: [Cooker] security audit
On Fri, 2003-03-14 at 14:39, Jason Straight wrote: > > I disagree, i don't think that if you go into single user mode that you > > should be root. You should still have to log in. The argument that someone > > has physical access to your computer thus making it your problem and not an > > exploit is IMHO fallacious. No one should be able to get root that easily. > > So set a bios password or a bootloader password if you are worried about > physical security, because simply having someone not log in as root by single > mode won't save you from a bootdisk anyway. > > Having a password in single mode would be useless as a means of physical > security. > > Set your bios with a pw (edit pw, not a boot pw - after all you don't want to > have to enter a pw every time you boot - that sucks), set your bios to only > boot from HD. > > Now in lilo set it restricted so that someone with physical access can't give > options to lilo bootparams without supplying a password. > > Now no one can use a bootdisk to get around OS security, and no one without > the password can boot single mode. Problem solved. Not entirely. You also have to lock your case shut somehow to stop someone opening it up and flicking the BIOS reset... Anyway, in regards to the original bug, this isn't purely a local exploit, surely? Doesn't it also apply to someone ssh'ing in from a remote site? i.e., I could give a simple user account to someone in Australia, thinking it's safe, and they could then ssh in and use this exploit to get a root shell? -- adamw
Re: [Cooker] security audit
jokerman64 wrote: On Friday 14 March 2003 6:58 am, Han Boetes wrote: Chmouel Boudjnah <[EMAIL PROTECTED]> wrote: Han Boetes <[EMAIL PROTECTED]> wrote: That's a local exploit. I can think of a few other local ``exploits'' as well, like booting in single user mode. this is not a exploit if you can _boot_ in single user mode it's mean you have acess to the hardware and if you have access we cannot do anything of security for you. Ahem, you are right. :) # Han I disagree, i don't think that if you go into single user mode that you should be root. You should still have to log in. The argument that someone has physical access to your computer thus making it your problem and not an exploit is IMHO fallacious. No one should be able to get root that easily. perhaps not by default, but if you type linux single init=/bin/sh at a lilo prompt (or grub, but it would look different), you can bypass any security on the system except for encrypted filesystem security, as far as I'm aware. Besides, with all the knoppix based CD distro's out there, including one that fits on a business card CD, anyone can boot the pc with that and Knoppix will automatically mount all the recognizable partitions as it boots.. Just my 0.02 Scott
Re: [Cooker] security audit
On Friday 14 March 2003 06:45 am, Guillaume Cottenceau wrote: > Henri <[EMAIL PROTECTED]> writes: > > on critical apps, on drakconf tools ecc. or not ? Perhaps this > > would avoid big holes like the shutdown one, no ? > > The shutdown problem is not a big hole. It grants local root > access only for people with a login on the "physical" machine > (console login). Securing those machines is already "something" > since you at least need to password-protect the bootloader (and > forbid booting from floppy/cdrom/network) and encrypt the > partitions. Not to say it's non-important, but it's not a problem > for servers, so to say. This is true besides under windows using fat32 or ntfs even with it encrypted you an still access the data. For this to happen you would have to invite somebody into your server room, office or home and let them take a whack at hacking your system. -- -~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~- Brook Humphrey Mobile PC Medic, 420 1st, Cheney, WA 99004, 509-235-9107 http://www.webmedic.net, [EMAIL PROTECTED], [EMAIL PROTECTED] Holiness unto the Lord -~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-
Re: [Cooker] security audit
Henri <[EMAIL PROTECTED]> writes: > on critical apps, on drakconf tools ecc. or not ? Perhaps this > would avoid big holes like the shutdown one, no ? The shutdown problem is not a big hole. It grants local root access only for people with a login on the "physical" machine (console login). Securing those machines is already "something" since you at least need to password-protect the bootloader (and forbid booting from floppy/cdrom/network) and encrypt the partitions. Not to say it's non-important, but it's not a problem for servers, so to say. -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] security audit
Henri <[EMAIL PROTECTED]> writes: > That was a simple suggestion, it seemed important to me, that's > all. Is security concerning only security experts ? I don't > think so. Where is the problem to be a customer asking questions > about security yo the expert precisly ?! If you can justify the > choice not to do audits, then every thing is alright ! why > answering me this way ? If mandrake security team does not like > this kind of questions, allright, i'll remember not to be worried > about security if i choose mandrake. I asks questions to my Han Boetes is not a Mandrake employee, he's talking only on behalf of himself. Actually we provide @linux-mandrake.com email addresses to some external people, that's confusing because some people think afterwards that they are talking on behalf of Mandrake. Only people with @mandrakesoft.com email addresses are Mandrake employees. Vincent Danen is MandrakeSoft's security team leader. -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] security audit
On Friday 14 March 2003 09:23 am, jokerman64 wrote: > On Friday 14 March 2003 6:58 am, Han Boetes wrote: > > Chmouel Boudjnah <[EMAIL PROTECTED]> wrote: > > > Han Boetes <[EMAIL PROTECTED]> wrote: > > > > That's a local exploit. I can think of a few other local > > > > ``exploits'' as well, like booting in single user mode. > > > > > > this is not a exploit if you can _boot_ in single user mode it's > > > mean you have acess to the hardware and if you have access we cannot > > > do anything of security for you. > > > > Ahem, you are right. :) > > > > > > > > # Han > > I disagree, i don't think that if you go into single user mode that you > should be root. You should still have to log in. The argument that someone > has physical access to your computer thus making it your problem and not an > exploit is IMHO fallacious. No one should be able to get root that easily. So set a bios password or a bootloader password if you are worried about physical security, because simply having someone not log in as root by single mode won't save you from a bootdisk anyway. Having a password in single mode would be useless as a means of physical security. Set your bios with a pw (edit pw, not a boot pw - after all you don't want to have to enter a pw every time you boot - that sucks), set your bios to only boot from HD. Now in lilo set it restricted so that someone with physical access can't give options to lilo bootparams without supplying a password. Now no one can use a bootdisk to get around OS security, and no one without the password can boot single mode. Problem solved. -- Jason Straight [EMAIL PROTECTED] icq: 1796276 pgp: http://www.JeetKuneDoMaster.net/~jason/pubkey.asc
Re: [Cooker] security audit
On Friday 14 March 2003 6:58 am, Han Boetes wrote: > Chmouel Boudjnah <[EMAIL PROTECTED]> wrote: > > Han Boetes <[EMAIL PROTECTED]> wrote: > > > That's a local exploit. I can think of a few other local > > > ``exploits'' as well, like booting in single user mode. > > > > this is not a exploit if you can _boot_ in single user mode it's > > mean you have acess to the hardware and if you have access we cannot > > do anything of security for you. > > Ahem, you are right. :) > > > > # Han I disagree, i don't think that if you go into single user mode that you should be root. You should still have to log in. The argument that someone has physical access to your computer thus making it your problem and not an exploit is IMHO fallacious. No one should be able to get root that easily. -- A bird in hand is less painful than two in the bush.
Re: [Cooker] security audit
Chmouel Boudjnah <[EMAIL PROTECTED]> wrote: > Han Boetes <[EMAIL PROTECTED]> wrote: > > > That's a local exploit. I can think of a few other local > > ``exploits'' as well, like booting in single user mode. > > this is not a exploit if you can _boot_ in single user mode it's > mean you have acess to the hardware and if you have access we cannot > do anything of security for you. Ahem, you are right. :) # Han -- http://www.xs4all.nl/~hanb/software
Re: [Cooker] security audit
Han Boetes <[EMAIL PROTECTED]> writes: > That's a local exploit. I can think of a few other local ``exploits'' as > well, like booting in single user mode. this is not a exploit if you can _boot_ in single user mode it's mean you have acess to the hardware and if you have access we cannot do anything of security for you.
Re: [Cooker] security audit
Han Boetes a écrit: Henri <[EMAIL PROTECTED]> wrote: OpenSource is said to be more secure : a question has come to my mind : before releasing the 9.1, will there be a security audit on critical apps, on drakconf tools ecc. or not ? These tools only run with root permissions. Mot much to hack anymore once you got that. Perhaps this would avoid big holes like the shutdown one, no ? That's a local exploit. I can think of a few other local ``exploits'' as well, like booting in single user mode. I think you'd better leave the worrying about security to the experts. That was a simple suggestion, it seemed important to me, that's all. Is security concerning only security experts ? I don't think so. Where is the problem to be a customer asking questions about security yo the expert precisly ?! If you can justify the choice not to do audits, then every thing is alright ! why answering me this way ? If mandrake security team does not like this kind of questions, allright, i'll remember not to be worried about security if i choose mandrake. I asks questions to my internet provider, why not asking them to mandrake ? I think every customer should wait for infos about security. Concerning the root excecution of drake tools, would it be profitable to use systrace ? # Han
Re: [Cooker] security audit
Henri <[EMAIL PROTECTED]> wrote: > OpenSource is said to be more secure : a question has come to my mind > : before releasing the 9.1, will there be a security audit on critical > apps, on drakconf tools ecc. or not ? These tools only run with root permissions. Mot much to hack anymore once you got that. > Perhaps this would avoid big holes like the shutdown one, no ? That's a local exploit. I can think of a few other local ``exploits'' as well, like booting in single user mode. I think you'd better leave the worrying about security to the experts. # Han -- http://www.xs4all.nl/~hanb/software
Re: [Cooker] security audit
On Thu Mar 13, 2003 at 08:26:23PM +0100, Henri wrote:
> OpenSource is said to be more secure : a question has come to my mind :
> before releasing the 9.1, will there be a security audit on critical
> apps, on drakconf tools ecc. or not ? Perhaps this would avoid big holes
> like the shutdown one, no ?
You're kidding, right? A security audit in two days?
I agree that performing an audit on Mandrake tools is important, it's
laughable to suggest we audit every piece of software we include. No other
vendor has done this, even those who profess to have secure Linux distros.
The only exception to this is OpenBSD, but they also still ship BIND4 IIRC.
The "big hole" in shutdown is a configuration flaw, not necessarily a flaw
in any one program. A mistake was made in assuming that removing
/usr/bin/shutdown was enough; this was proven to be inaccurate. To
completely remove this, the /etc/pam.d/shutdown file needs to be removed as
well... consolehelper doesn't really do anything on it's own other than talk
to pam, and pam was still allowing it. So a config file needs to removed.
Yes, little things like this need to be checked and avoided. But asking us
to do a wholesale security audit based on this one situation is not entirely
realistic.
--
MandrakeSoft Security; http://www.mandrakesecure.net/
Online Security Resource Book; http://linsec.ca/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
pgp0.pgp
Description: PGP signature
