On Tuesday 28 November 2006 10:42, Craig White wrote: >On Tue, 2006-11-28 at 10:12 -0500, Gene Heskett wrote: >> On Tuesday 28 November 2006 07:31, Craig White wrote: >> >---- >> >The update wasn't the issue...you installed another snapshot of >> > amanda - all files without contexts for SELinux I would bet. >> >> Of course its from the tarball, built right here, I'm a tester. Whats >> wrong with that? > >---- >nothing but being a tester means that you have the tools to actually >test or can acquire the skills to necessary to properly install test >snapshot - and this includes the nuances of the host build system. >---- > Thats what I'm trying to do by asking the questions below. >> >One of the issues you are going to have with installing stuff from >> >source is that none of those files will have the proper contexts for >> >SELinux and you are either going to have to actually learn how to >> > live with SELinux or just shut if off. >> > >> >Blaming errors on the packages when you don't understand what you are >> >doing makes you look rather foolish. >> >> I'm not blaming the errors on the amanda packaging Craig as I haven't >> used a packaged amanda in at least 5 years. But I damned sure do >> object to building it right here on this box where its going to run, >> using the tools supplied with the distribution, only to have selinux >> decide its not safe to run it even if its (theoreticly) set to >> permissive. That to me is a tool error and goes back to both selinux >> and the compiler suite. And maybe should be bugzilla'd. OTOH, I've >> been a fool before, one who believes that this crap should Just >> Work(TM). > >---- >I suppose that if you want to provide evidence that demonstrates that >having selinux set to permissive was still blocking it from working (on >bugzilla), then the developers would have a chance to fix whatever is >blocking it from working. Until then, your complaints are anecdotal. >---- > Plenty of evidence exists in my logs from all my attempts to get cron to run it. From logwatch: --------------------- Cron Begin ------------------------ **Unmatched Entries** Nov 27 01:01:02 coyote crond[19038]: Authentication service cannot retrieve authentication info Nov 27 01:01:02 coyote crond[19038]: CRON (amanda) ERROR: failed to open PAM security session: Success Nov 27 01:01:02 coyote crond[19038]: CRON (amanda) ERROR: cannot set security context Nov 27 08:15:01 coyote crond[27069]: Authentication service cannot retrieve authentication info Nov 27 08:15:01 coyote crond[27069]: CRON (amanda) ERROR: failed to open PAM security session: Success Nov 27 08:15:01 coyote crond[27069]: CRON (amanda) ERROR: cannot set security context Nov 27 08:20:02 coyote crond[27236]: Authentication service cannot retrieve authentication info Nov 27 08:20:02 coyote crond[27236]: CRON (amanda) ERROR: failed to open PAM security session: Success Nov 27 08:20:02 coyote crond[27236]: CRON (amanda) ERROR: cannot set security context Nov 27 08:33:01 coyote crond[27756]: Authentication service cannot retrieve authentication info Nov 27 08:33:01 coyote crond[27756]: CRON (amanda) ERROR: failed to open PAM security session: Success Nov 27 08:33:01 coyote crond[27756]: CRON (amanda) ERROR: cannot set security context Nov 27 08:37:01 coyote crond[27889]: Authentication service cannot retrieve authentication info Nov 27 08:37:01 coyote crond[27889]: CRON (amanda) ERROR: failed to open PAM security session: Success Nov 27 08:37:01 coyote crond[27889]: CRON (amanda) ERROR: cannot set security context Nov 27 19:15:01 coyote crond[7053]: Authentication service cannot retrieve authentication info Nov 27 19:15:01 coyote crond[7053]: CRON (amanda) ERROR: failed to open PAM security session: Success Nov 27 19:15:01 coyote crond[7053]: CRON (amanda) ERROR: cannot set security context Nov 27 19:20:01 coyote crond[7220]: Authentication service cannot retrieve authentication info Nov 27 19:20:01 coyote crond[7220]: CRON (amanda) ERROR: failed to open PAM security session: Success Nov 27 19:20:01 coyote crond[7220]: CRON (amanda) ERROR: cannot set security context Nov 27 20:15:01 coyote crond[16171]: Authentication service cannot retrieve authentication info Nov 27 20:15:01 coyote crond[16171]: CRON (amanda) ERROR: failed to open PAM security session: Success Nov 27 20:15:01 coyote crond[16171]: CRON (amanda) ERROR: cannot set security context Nov 27 20:25:01 coyote crond[16717]: Authentication service cannot retrieve authentication info Nov 27 20:25:01 coyote crond[16717]: CRON (amanda) ERROR: failed to open PAM security session: Success Nov 27 20:25:01 coyote crond[16717]: CRON (amanda) ERROR: cannot set security context ---------------------- Cron End ------------------------- >> Does this mean I have to reboot and relabel the system everytime I >> install a new version of amanda to test it? >> >> If so, that does rather label linux's extended uptime claims as a lie >> from the gitgo now doesn't it? > >---- >I previously supplied the link to the information on SELinux to you the >first time you got in a tizzy and I will supply it again... > >http://fedora.redhat.com/docs/selinux-faq-fc5/ Thanks, again. >If you want to relabel the entire file system - that is a prerogative >that you enjoy but clearly not the only method available to you. >Knowledge is power...perhaps you want to absorb the information on the >above since 'local policy' is likely to be more enduring. Learning how >to use tools such as chcon might also prove useful. >---- Fine, go ahead and do a 'man chcon'. Now tell me what 'CONTEXT' means... Without that definition the whole manpage may as well be written in swahili. >> Now lets see if the problem can be fixed within the framework of this >> PITA called selinux. >> >> Is there a method that I can use to relabel a freshly built snapshots >> whole src+object tree before I become root to do the make install? If >> there is, then I'll just incorporate it right into the build script >> I've been using for years. That would be the ideal situation IMO. > >---- >Your opinion is just one opinion. Shared by many I'd think. >You can set file security contexts at any point along the way but they >might change depending upon how they are moved and what contexts already >exist. I would presume that it's more common to fix file contexts after >the files are copied to their final location, again, either through >policy, by existing tools or by a complete relabel of the file system. > >If you were familiar with rpm building, you could probably alleviate >many of your problems with contexts and upgrades and post install >scripts. By the way, it's pretty easy to build rpm's from a >tarball...what you need is a spec file. My guess is that someone >unwilling to spend the time and energy learning how to operate with >SELinux isn't going to spend the time learning to use rpm-build since >he's already figured out ./configure && make && make test && make >install > >Here's a hint...get the current SRPM for amanda and modify the spec >file. Fine, I can do that. But the chances of its working within the framework of amanda's view of security are slim to none when the limitations of the rpm package system are applied. This has been discussed to death with no viable solution being developed on either side of this divide. Up till now, if one wanted an amanda install that Just Worked(TM), one followed the build instructions for amanda, and it Just Worked(TM). Now, I'm busy reloading yumex trying to find the src rpms. It looks like they should be in core, but theres no trace of them there. So where to next coach? Humm, restricting yumex to core-source gets me a blank screen! With no repo errors reported. Can anyone address that? >Also, I find it really hard to believe that someone who logs in as root, >runs GUI as root actually changes to another user to ./configure && make >&& make test before changing back to root to make install. Because thats one of the things that makes amanda fairly secure, it runs as an unpriviledged user, only doing suid root for those portions of its job that require it. Strangely for you I suppose, I find it a perfectly sensible method of obtaining some security. After all, amanda has been around for about as many years as linux, probably longer. I came into camp in 1998 when it was at about 2.4.2p1, now its 2.5.1p2, in late 2006. The ChangeLog starts with version 2.3.0, but the first time a change was dated was quite some time later, after version 2.4.0p1, and that was in 1998. So I think amanda knows just a wee tiny bit about security, and probably more than this recent PHB hire, selinux. Besides that, its all in my script. Which is very simple, but consistent from build to build, unlike my fingers and their well known typos... >---- > >> What I'm saying, nay demanding, is that selinux isn't to be sensitive >> to this. We can fix the build system, or we can fix selinux by >> disabling it, which is the current situation. > >---- >disabling is a very reasonable solution for those unwilling to spend the >time and energy necessary to understand how to maintain a system running >SELinux. >---- > >> Just to keep peace in the camp, I'd much druther fix the build system >> if its possible. And the fixes will be published on the amanda-user >> and amanda-hackers lists if they can be made to work. No one should >> be forced to endure this constant harrassment by a tool that lies >> outright to the end user. Because thats exactly what its doing when >> it blames it on pam. > >---- >perhaps you need to demonstrate what is wrong with the build system and >SELinux because as I see it, there are thousands of packages available >for FC-6 and they seem to manage to live with SELinux. The rpm packagers have demonstrated on numerous occasions that they do not fully understand the system of permissions amanda manipulates as she wanders through the the dle's given, always running with just enough perms to get the job done and no more. Suid's ignored or miss-applied are one of the typical errors, and then we on the list have to figure out what it was that the latest rpm broke, often with far more meager clues than what I usually bring to this list. Occasionally we can sort it, but we usually wind up recommending the user go get the tarball, setup a user amanda on his system, and become that user to build it, even using my script modified to suit his particular system with mods as required, which they will be because the server ip address (or the FQDN works too if its resolvable) is hard coded into amanda at build time. Likewise, so is the location of tar, again for security reasons. One of the more blatant errors or 'shortcuts' rpm packagers do is use localhost, which amanda, for security reasons doesn't allow since localhost is every machine on the planet, instead the server address in particular is compiled in as stated above. Then become root to install it because the install script needs to set some utils suid as it goes. rpm cannot be made to do either, because rpm has no idea of the servers address at install time. Thats the first and most common breakage because the packager substitutes localhost for the FQDN when he builds it. Oh, it *looks* like it works, until you need to do a restore, at which point localhost is rejected, often silently so as to not give the hacker/thief any clues as to why its failing. This is considered a security feature by forcing the re-install back on the same machine as opposed to somebody finding a partially bad tape in the trash and recovering your sensitive data for his/her own nefarious purposes just because his machine is also 'localhost.localdomain'. As to those problems being fixable, I'll leave it to the rpm developers to find a solution that works. The amanda people *know* what works and aren't inclined to allow a huge security hole to be allowed without disowning the result. Rightfully so IMO. Sure, I'm willing to see if I can make an installable rpm, but seeing as how the use of rpm instead of locally built srcs forces so many compromises into amanda that until rpm is fixed, a just works amanda install, one that also works 100% for recovery, is probably just a wishfull dream. > >Craig -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
