On 23 Oct 2004, Jan LÃhr wrote: > Am Freitag, 22. Oktober 2004 14:02 schrieb Daniel Pittman: >> On 22 Oct 2004, Jan LÃhr wrote: >>> because of the recent xpdf issues I tested the access restrictions of >>> some users like lp, mail, etc. with default settings in sarge. I noticed >>> that, by default, no acl were used to prevent access to vital system >>> commands, the user shouldn't have. For instance: lp could mount a vfat >>> partion marked as user mountable in fstab, execute df or mount to gain >>> information about the systems topology.
[...] >> This is, in large part, because preventing access to the binaries >> commands on disk does little or nothing to prevent a determined attacker >> from gaining the equivalent functionality through directly calling the >> kernel. > > That's true as well. But the binaries are just an example for unnecessary > rights. 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. [...] > Of course not. But on the other hand, there are parts of the system, a deamon > user should not be able to stick his nose in. Imho a more restrictive way is > necessary. MAC allows you to actually enforce these rules, rather than simply making it a bit harder or the mechanism a bit more obscure. As people have been saying for years, security through obscurity is no real security at all -- and preventing access to on-disk binary code does not prevent access to the risky areas. [...] >> I think that trying to enforce this sort of security at the filesystem >> level is doomed to failure, as it is the wrong level to work at. > > Ok, but why should lp (as user) be able to access mount (suid)? I see no > reason to allow them to do so, but I see many reasons for not allowing them > to do so. They shouldn't be able to access mount, or related functionality. Trying to enforce that through filesystem permissions is a task that has a large number of failure points, especially in the face of multiple vulnerabilities. One of the most common failures for this sort of security is a copy of the binary accessed through another path name, etc, that allows the undesired code to be executed despite protection in of the main copy. Also, trying to define the security rules at the filesystem level provides no real protection against many locally exploitable holes. Many of these can be accessed by talking over network sockets or other channels than the filesystem. >> If you want to achieve this sort of high level security by default, >> consider finding and working with the people who are trying to provide >> the tools and environment required to run SELinux, or some other MAC >> implementation, in Debian. > > NSA is evil by default ;-) The code is all out there; feel free to audit it. ;) Alternatively, trust some other group who write LSM code to implement a MAC system, or even one of the alternative security models, and work on getting that into Debian as an option or, eventually, by default. I named SELinux because I know there to be a real effort to get this working out of the box, not because I have any special love for it. > Of course, providing security on that level is not the best way to > ensure the system's integrity and safety. But why do you think, that > security on filesystem level is doomed to failure if it's part of a > security concept? The introduction of shadow passwords use the concept > of file system level security. Imho allowing $daemon to access > $some-unnecessary-suid-binary is doomed to failure. You may note that the shadow password system has also moved on, to include other methods for encrypting the password since, at the end of the day, these filesystem permissions can be bypassed. :) You are right when you say that using filesystem permissions can provide some measure of additional security, and when you say that the introduction of an ACL capability into many common filesystems in Linux opens the door to enabling this. Between the complexity of the ACL system, the difficulty in defining security rules for a full blown Unix, I don't believe that this can work. Also, I believe that there is a good deal more work in making this security system accessible out of the box than you suggest. However, this is a volunteer project - if you think it is helpful, go ahead and lead the effort. I will happily be proved wrong when your ACL security project shows up real world benefits. >>> Who's in charge with this decision? >> >> I don't think you could succeed in having this imposed by fiat on the >> Debian project, especially at this late stage, since it would be a huge >> level of work. > > Well, yes. Sid might be a target as well. Practically, what you probably want to do is work on getting ACL-enabled tools into base, and then start working through and getting individual packages enhanced to use them. I wouldn't expect to see significant gains within six months to a year of concentrated effort from a number of people when dealing with a project of this scope. Regards, and good luck, Daniel -- Onanism produces seminal weaknesses, impotence, dysury, tabes dorsalis, pulmomary consumption, dyspepsia, dimness of sight, vertigo, epilepsy, hypochondriasis, loss of memory, manalgia, fatuity, and death. -- Dr. Benjamin Rush, _Medical Inquiries_, 1812 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]