Re: stack protection
On Sun, Aug 24, 2003 at 01:19:38AM +1000, Russell Coker wrote:
> On Sat, 23 Aug 2003 19:36, Milan P. Stanic wrote:
> > > Allowing the system administrator to write to /dev/mem as part of
> > > debugging the kernel is a feature.
> >
> > UID 0 must have rights to do everything. root can "format" filesystem,
> > by mistake or by intention.
>
> UID does not have to be the only method of determining access rights. In SE
> Linux you have the Identity (based on the login name for interactive sessions
> and cron jobs, or system_u otherwise) which determines which roles are
> permitted. You have the Role which determines which domains are permitted,
> for an Identity that is permitted to use multiple roles there are methods of
> changing roles during a session or of determining which Role to use when
> logging in. Then you have the Domain which determines the access rights.
>
> When you login to do administrative work by default you will have the context
> root:sysadm_r:sysadm_t as the Identity:Role:Domain. This will deny you
> access to block devices, when you run mount or mkfs they run in different
> domains which have the access needed to do their job.
Complexity and security doesn't mix well.
[...]
> Writing perfect software is impossible.
I agree, but writing secure (not perfectly secure) software may be
nearly possible.
I don't like to start flame war, but must mention djbdns and qmail.
> For a good defence you want to have multiple levels. Medieval castles never
> had a single level of defence, they were built on a hill, they were
> surrounded by a moat, they had outer walls and then a fortified keep inside
> so that even filling in the moat and smashing the outer walls would not let
> an attacker win.
"Denial of Service" was the most successful method to defeat it. :-)
[...]
> Writing quality software is good. Having stack protection is good too (the
> original topic of this thread). But it still doesn't provide as much
> protection as you will really want, SE Linux is still necessary even if you
> run top quality software.
Having capability to execute code in any place is flexibility of the
OS. If the kernel forbids execution code on the stack, such kernel
forbids using legitimate programming method and I think if it goes this
way we will have OS (kernel) which puts limits and bounds.
> Most Unix daemons are not of the highest quality, consider that they added a
> "-b" switch to start-stop-daemon. Think about the quality of coding that
> goes into a daemon that doesn't even call the daemon(0,0) library call or
> have equivalent code!
That couldn't be solved by SE Linux (or similar code) but just
mitigated a little.
> PS The ptrace exploit code that was released did not work on SE Linux
> systems. The reason was that the socket access necessary to trigger the
> module load in the exploit code was denied to the user_t domain because it
> was not needed (everything that is not needed is denied by default). It
> might have been possible to write an exploit to work on SE Linux, but no-one
> did so.
SE Linux (and Linux kernel) is the program. Programs have bugs. Some
of the bugs can be used as security exploit. If there isn't known
exploit now (I don't know but what knows NSA or "black hat" community?)
doesn't mean it will not emerge tomorrow.
I'm not against SE Linux, RSBAC GRSec, LIDS etc. I'm using some them
on servers and playing with all of them. I just like to say that putting
limits in the (our loved (Debian)/Linux) is not good thing, IMO.
Reply to: