Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I cannot seem to force an SUID program to drop a core on segfault (or presumably any other fault) when run by an unprivilged user. I've searched about and set everything I could think to set. The kernel.core_setuid_ok seemed most promising, but that hasn't seemed to work either. I saw reference to a bug in sysctl.c for my kernel version related to that variable, but I don't see evidence that it directly relates to my problem. Anyone have any ideas? The output below is obtained immediately after a full reboot. I'm using RedHat Enterprise 3, linux 2.4.21-40, and unable to upgrade to 2.6 at this time.
[root@---- root]# cat /etc/sysctl.conf
# Kernel sysctl configuration file for Red Hat Linux
# For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and
# sysctl.conf(5) for more details.
# Controls IP packet forwarding
net.ipv4.ip_forward = 0
So after putting this on hold and moving onto my next task, I happened to stumble accross an article mentioning prctl(8). I inserted the line
into my test code and it properly dumped a core. So now my questions are:
1) Is this a proper thing to do? Assuming the rest of the code is secure, are there any glaring reasons why I shouldn't release such code into the field?
2) Does this new information shed any light onto why kernel.core_setuid_ok didn't work for me?
Any other information related to the design mentality for suid fault proceedure, or an explaination of the process the OS follows, be it a description or a link to good information would be greatly appreciated. I'm quite keen on security, but I've still got a lot to learn.
you did great job with prctl.
Quoting 'man 2 prctl' on PR_SET_DUMPABLE:
"Since Linux 2.4) Set the state of the flag determining whether core dumps are
produced for this process upon delivery of a signal whose default behaviour is
to produce a core dump. (Normally this flag is set for a process by default, but it is cleared when a set-user-ID or set-group-ID program is executed and
also by various system calls that manipulate process UIDs and GIDs). ..."