Re: Security issue? Daemon users has to much rights...
Greetings,...
Am Samstag, 23. Oktober 2004 05:58 schrieb Daniel Pittman:
> 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:
> 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.
SELinux is overkill in some ways. A system adminstrator, not being able to
handle ACLs won't be able to handle SELinux.
> [...]
>
> > 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.
Well, standard debian binary code is available for nearly everyone. Sec-by-obs
by setting fs-rights was not in my intention.
> [...]
>
> >> 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.
Of course. But even chrooting everything was exploited in past. If you are a
victim of multiple vulns - god bless you.
> 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.
If a file can be accessed through some link, loading, etc. tricks sec. on
fs-level is not implemented correctly. Without taking control over
kernel-functions (like root-kits do, but you have to be root to do so) no one
should be able to bypass the file-system layer. The best example for this is
mounting partition's noexec. Everyone, who has sticked is nose into that
topic is able to bypass this flag, but programs like dpkg are not able to do
there work, if /tmp is mounted noexec - strange world. If the non-execution
idea was implemented correctly neither this bypass nor any other would be
possible. (I'd like to append, that Imho the current linux kernel / userland
architecture is unable to allow a clean implementation of this).
>
> 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 gain root, everything is possible on a root centric-system. Using
non-root-centric systems is tending to confuse naive admins.
> >> 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. ;)
Well, I've some other work to do in the next months. ;-)
> 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.
Well, yeah. But peopple who developed trojan horses like magic like magic
latern are not trustworthy in my opinion. ;-)
> > 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. :)
Of course, at the end of these days, even bypassing of chroot and vmware is
documented.
> 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.
Well, at least definig rules for suid-binaries would be a step forward in the
right direction., This can either be down through a traditional unix group or
through more modern acls.
>
> Also, I believe that there is a good deal more work in making this
> security system accessible out of the box than you suggest.
Even by considering an amount of 20 root-suid-binaries, which should be
protected, it is very difficult to check which packages need's them to be
suid. But if maintainers declare what suids they need, this could be done in
a couple of days.
> 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.
Well, probably you were right here. It might be better to use distributions,
which already introduced them instead of re-inventing the wheel.
Keep smiling
yanosz
Reply to: