Recent /proc/pid/mem exploit
by David Quigley
So I read through the recent privilege escalation vulnerability using
su and gpasswd which exploits weak permission checks in /proc/pid/mem
and tried to figure out why we didn't stop it. What it comes down to is
that /proc/pid and everything under it is given the same type as the
process itself. In the case of the gpasswd that type is groupadd_t.
Looking at the kernel code for /proc/pid/mem and its read/write
functions it seems that the only permission checking we do on that node
is done by the vfs. So from the SELinux perspective you would need allow
groupadd_t groupadd_t file:{open read write} to have access to
/proc/pid/mem. For some odd reason tons and tons of applications have
file:{open read and write} on itself.
One question that should be asked is why is is that we have so many
rules that contain sometype_t sometype_t file: {open read write}. Is it
necessary or something that is just being pulled in from a macro. If
this is necessary for other reasons the followup to this would be should
/proc/pid/mem have the same type as the process or should we have some
additional requirements permission wise for a process to read and write
to its own memory through /proc/pid/mem. What are the valid reasons for
a process to be poking around through its memory using /proc/pid/mem?
Dave
12 years, 3 months
Re: Creating files from initrc_t
by Dominick Grift
On Mon, 2012-01-23 at 15:57 +0000, Moray Henderson wrote:
> Hi
>
> On CentOS 5.6, I have just noticed that if a process running under context
> initrc_t creates a file or directory within a user's home directory, that
> object gets user_home_dir_t.
>
> If an unconfined_t process does the same thing, they correctly get
> user_home_t.
>
> Was this a bug or a feature?
>
> selinux-policy-2.4.6-300.el5_6.1
> selinux-policy-targeted-2.4.6-300.el5_6.1
>
>
> Moray.
> "To err is human; to purr, feline."
I guess that depends on how you look at it but compared to recent fedora
policy i guess you could consider this to be a bug.
This is supported in Fedora 16:
# sesearch --allow -s initrc_t -t user_home_dir_t -T | grep user_home_t
type_transition initrc_t user_home_dir_t : file user_home_t;
type_transition initrc_t user_home_dir_t : dir user_home_t;
type_transition initrc_t user_home_dir_t : lnk_file user_home_t;
type_transition initrc_t user_home_dir_t : sock_file user_home_t;
type_transition initrc_t user_home_dir_t : fifo_file user_home_t;
>
>
>
> --
> selinux mailing list
> selinux(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux
12 years, 3 months
Constraint violation question
by Joe Nall
When I'm tracking down a constraint violation, is there any automated way to determine which constraint is being violated?
joe
12 years, 3 months
Creating files from initrc_t
by Moray Henderson
Hi
On CentOS 5.6, I have just noticed that if a process running under context
initrc_t creates a file or directory within a user's home directory, that
object gets user_home_dir_t.
If an unconfined_t process does the same thing, they correctly get
user_home_t.
Was this a bug or a feature?
selinux-policy-2.4.6-300.el5_6.1
selinux-policy-targeted-2.4.6-300.el5_6.1
Moray.
"To err is human; to purr, feline."
12 years, 3 months
Report ot not, Rawhide
by Frank Murphy
When there are sealerts on Rawhide.
Where the only suggestion is to
either create a mypol, or report as bug.
If I don't know whether to allow or not
Should I bz or c&p here?
--
Regards,
Frank Murphy
UTF_8 Encoded
12 years, 3 months
FC recursive directories
by Nabeel Moidu
Hi
Can the file context specification recursively assign contexts when using
regex ?
Eg. I have
a/b/c/d
and if I specify in selinuxrule.fc
a* gen_context(system_u:object_r:myapp_exec_t)
Will this apply to only files under a or files under a/b, a/b/c and a/b/c/d
etc. also ?
--
Thanks and Regards
Nabeel Moidu
12 years, 3 months
Problems auditing yum behaviour
by Jonathan Gazeley
Hi list,
We recently migrated all our servers from CentOS 5 to 6 and in the
process we decided to default to keeping SELinux on, and learning how to
configure it properly :)
So far we've had good success with setting booleans and writing custom
policies, except for one Nagios plugin that checks yum status[1]. On my
boxes, the check_yum plugin is executed under NRPE as a non-privileged
user. This works fine with SELinux in permissive mode.
I've checked the audit log and this message is produced every time the
plugin tries to run:
type=AVC msg=audit(1326802289.462:4127902): avc: denied { read write }
for pid=3278 comm="yum" name="__db.001" dev=sda3 ino=8128221
scontext=unconfined_u:system_r:nagios_services_plugin_t:s0
tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=file
type=SYSCALL msg=audit(1326802289.462:4127902): arch=c000003e syscall=2
success=no exit=-13 a0=1e85440 a1=2 a2=0 a3=16 items=0 ppid=3277
pid=3278 auid=56933 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=87175 comm="yum" exe="/usr/bin/python"
subj=unconfined_u:system_r:nagios_services_plugin_t:s0 key=(null)
Running this through audit2allow produces this output:
#============= nagios_services_plugin_t ==============
#!!!! This avc is allowed in the current policy
allow nagios_services_plugin_t rpm_var_lib_t:file { read write };
It says the AVC is already allowed, but to make sure I packaged it and
loaded the new module. But, the AVC is still blocked and the plugin
can't run.
I've tried running semodule -DB to force dontaudit entries to be logged
to make sure I haven't missed anything that was being blocked silently.
Am I misisng something else, or is something wrong?
Thanks,
Jonathan
[1]
http://exchange.nagios.org/directory/Plugins/Uncategorized/Operating-Syst...
12 years, 3 months
selinux and openVPN and no log entries
by Ed Greshko
This is actually a "multi-part" question..... I'm on F16 using KDE.
As a regular user I'm attempting to create an openVPN configuration
which uses X.509 certs. I wanted to place the certs in $HOME/.openVPN
but ran into a problem. The logs showed the following error:
Jan 15 10:31:51 f16-1 nm-openvpn[2611]: Cannot load certificate file
/home/egreshko/.openVPN/CERT: error:0200100D:system
library:fopen:Permission denied: error:20074002:BIO
routines:FILE_CTRL:system lib: error:140AD002:SSL
routines:SSL_CTX_use_certificate_file:system lib
After a bunch of head scratching and diagnosing I guessed that it must
have been due to an selinux setting and confirmed this by switching to
"permissive" mode.
There were no log entries for the selinux denial. I saw in the archives
the pointer to http://danwalsh.livejournal.com/11673.html but running
the suggested "semodule -DB" didn't result in what I expected. I didn't
get any "usable" error message but these appeared instead.
Jan 15 10:36:05 f16-1 sedispatch: AVC Message for setroubleshoot,
dropping message.
So, I have (I think) 2 questions.....
1. What would need to be done to have meaningful selinux messages
written to the logs so they can be troubleshot?
2. What change could be made to allow the certs to be in $HOME/.openVPN?
Another comment would also be.... Why is the default situation that no
log entries or alerts are created? Doesn't that obscure the fact that a
selinux issue is preventing something and making it harder to diagnose?
Thanks,
Ed
12 years, 3 months
