Re: stack protection
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.
Then when you run a daemon it runs in a domain that has only the access needed
for it's operation, dhcpd_t can do raw network access and bind to UDP port
67. named_t can bind to port 53 for TCP and UDP and port 953 for TCP.
Neither named nor dhcpd can access files under user home directories, read
/etc/shadow, etc. Which is a very good thing as both have a bad history.
> > Allowing the dhcp server to write to /dev/mem because it's UID 0 and Unix
> > security sucks is a bug.
>
> The problem isn't with UID 0, but with bugs in software.
>
> I think that the problem cannot be solved in wrong place. It isn't
> possible to have secure DHCP server by fixing kernel, but by writing
> secure (OK, with less bugs) DHCP server.
Writing perfect software is impossible.
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.
If you have only a single level of security then any hole that is found will
make you lose. If you have several levels of security then ideally it will
not be possible to successfully attack you unless holes are found in all
levels simultaneously, which is a much more difficult and less likely event.
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.
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!
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.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
Reply to: