pptp
by Paul Howarth
I'm currently using pptp (from Extras) for two different purposes:
1. to connect to my ADSL provider
2. to connect to $EMPLOYER's network
pptp is a point-to-point tunnelling protocol client tightly integrated
with pppd. It uses the GRE TCP protocol field to encapsulate packets to
be sent down the tunnel. Some diagrams are available at
http://pptpclient.sourceforge.net/diagrams.phtml
Detailed information about the protocol (RFCs etc.) can be found in the
pptp tarball in the SRPM.
The way I start pptp is from an initscript, which does:
pppd call filename
where /etc/ppp/peers/filename contains the pppd options for the call,
typically:
pty "/usr/sbin/pptp ip.of.pptp.server --nolaunchpppd"
user my.username
usepeerdns
updetach
... usual sorts of pppd options
So pptp gets called from pppd, and hence runs as pppd_t
Since pptp sends all sorts of packets down a tunnel, I find I need to
add SELinux rules like these to get it to work:
allow pppd_t var_log_t:file { append getattr };
allow pppd_t var_run_t:sock_file { create setattr unlink write };
allow pppd_t initrc_var_run_t:file { lock read write };
(these are standard pidfile/logfile issues I think)
allow pppd_t self:rawip_socket { create connect read write };
allow pppd_t self:tcp_socket connect;
allow pppd_t self:unix_stream_socket { accept connectto listen };
allow pppd_t fingerd_port_t:tcp_socket name_connect;
allow pppd_t port_t:tcp_socket name_connect;
allow pppd_t hostname_exec_t:file { execute execute_no_trans getattr
read };
allow pppd_t pppd_etc_rw_t:file { execute execute_no_trans };
allow pppd_t smtp_port_t:tcp_socket name_connect;
allow pppd_t devpts_t:chr_file ioctl;
Given that I may wish to connect to arbitrary ports down the tunnel, I
decided to cut my losses and do:
# setsebool -P pppd_disable_trans 1
Would it be possible to separate pptp from pppd_t and specify different
rules for it?
Paul.
--
Paul Howarth <paul(a)city-fan.org>
18 years, 9 months
FC4 policy: problems with /home
by Ruth Ivimey-Cook
Folks,
I've updated a fileserver to FC4, and have a problem with the policy settings
for /home.
Under /home I have directories for:
- users home directories
- samba, also containing some windows user profiles
- the server's web hierachy (what RH likes to put in /var/www)
- general shared files (e.g. mp3s)
Under FC3 all I had to do to get everything working was to include a line
equivalent to that for /var/www, but for /web (why not /home/web ? because
/web is a softlink to /home web).
Now, it rejects /web, so I tried adding /home/web to apache.fc, but that has
no noticeable effect when I do "restorecon -R /home/web".
In addition, something is now preventing access to /home/samba/*, I think
because it's called from in home_root_t and the files there are in
user_home_t. See below for the log messages.
Can anyone help me with pointers out of this mess?
Thanks,
Ruth
Jul 14 14:07:49 filestore kernel: [4379544.608000] audit(1121346469.104:0):
avc: denied { getattr } for path=/home dev=md2 ino=2
scontext=system_u:system_r:smbd_t tcontext=system_u:object_r:home_root_t
tclass=dir
Jul 14 14:07:49 filestore kernel: [4379544.608000]
audit(1121346469.104:0): avc: denied { read } for name=/ dev=md2 ino=2
scontext=system_u:system_r:smbd_t tcontext=system_u:object_r:home_root_t
tclass=dir
Jul 14 14:07:49 filestore kernel: [4379544.609000] audit(1121346469.105:0):
avc: denied { getattr } for path=/home/rivimey/.kde dev=md2 ino=6508546
scontext=system_u:system_r:smbd_t tcontext=user_u:object_r:user_home_t
tclass=dir
Jul 14 14:07:49 filestore kernel: [4379544.609000] audit(1121346469.105:0):
avc: denied { getattr } for path=/home/rivimey/.ICEauthority dev=md2
ino=6508597 scontext=system_u:system_r:smbd_t
tcontext=user_u:object_r:user_home_t tclass=file
--
Ruth Ivimey-Cook
Software engineer and technical writer.
18 years, 9 months
RE: Help with avc's on /init
by Stephen Smalley
On Wed, 2005-07-13 at 15:23 +0100, Ruth Ivimey-Cook wrote:
> Thanks. I wondered if it was in initramfs, but it's hard to check. Is there
> anything I can do to shut it up?
Looks like there is already a dontaudit rule in init.te for file
descriptors inherited from the rootfs, but that dontaudit rule only
deals with the file checks, not the descriptor use check. So I'd add:
dontaudit init_t kernel_t:fd use;
But I also see that init_t is unconfined in targeted policy (unlike
strict), so that would mean that /sbin/init is being allowed to inherit
the descriptor, so it is then passed along to all of its children.
Which means you'd have to essentially dontaudit it for all domains to
suppress, e.g.
dontaudit domain kernel_t:fd use;
Regardless, it should be bracketed with some ifdef, e.g.
hide_broken_symptoms, because this does reflect a base kernel bug (not a
bug in SELinux, but descriptor leakage by the base kernel) that needs to
be fixed.
--
Stephen Smalley
National Security Agency
18 years, 9 months
Help with avc's on /init
by Ruth Ivimey-Cook
Hi,
I've just updated my desktop to FC4, have updated the policy to latest
available versions, and am having problems with selinux denying access to a
file I can't even find! Hoping someone can help.
OS: FC4, updated today.
Policy 1-25-1
Mode Targeted
kernel 2.6.12.1 (kernel.org)
Jul 13 14:35:25 filestore kernel: [4294782.219000] audit(1121261725.182:0): avc: denied { use } for path=/init dev=rootfs ino=42 scontext=system_u:system_r:i18n_input_t tcontext=system_u:system_r:kernel_t tclass=fd
Jul 13 14:35:28 filestore iiimd[2511]: started.
Jul 13 14:35:39 filestore kernel: [4294796.393000] audit(1121261739.353:0): avc: denied { use } for path=/init dev=rootfs ino=42 scontext=system_u:system_r:system_dbusd_t tcontext=system_u:system_r:kernel_t tclass=fd
Jul 13 14:35:40 filestore kernel: [4294797.090000] audit(1121261740.050:0): avc: denied { use } for path=/init dev=rootfs ino=42 scontext=system_u:system_r:cupsd_config_t tcontext=system_u:system_r:kernel_t tclass=fd
Jul 13 14:35:40 filestore kernel: [4294797.580000] audit(1121261740.540:0): avc: denied { use } for path=/init dev=rootfs ino=42 scontext=system_u:system_r:hald_t tcontext=system_u:system_r:kernel_t tclass=fd
I've tried a general relabeling (admittedly, not since the most recent update,
but then it did something similar in the update itself).
I'm not quite sure what effect the denials are having, but the system is not
very stable at present.
Ruth
--
Ruth Ivimey-Cook
Software engineer and technical writer.
18 years, 9 months
user_u identity
by Preeti Malakar
Sir
user_u is a generic user identity for Linux users who have no
SELinux user identity defined
why is user_u authorized for roles sysadm_r and system_r
why is the user_r allowed to make a transition to sysadm_r and
system_r ( as in rbac file)
Thanking you
18 years, 9 months
Should file permissions match SELinux policy?
by Dax Kelson
I was porting some DNS courseware lab exercises to RHEL4 and FC3/4 and
the following came up.
In the file:
/etc/selinux/targeted/src/policy/domains/program/named.te
There exists policy so that only "named" can read named configuration
files.
# A type for configuration files of named.
type named_conf_t, file_type, sysadmfile;
[snip]
#read configuration files
r_dir_file(named_t, named_conf_t)
This is fine and works. The question comes then that the standard file
owner and group and permission are more open (and have been
historically).
-rw-r--r-- 1 root root 1323 Aug 25 2004 /etc/named.conf
Should the owner and group and permissions be made to match up with the
SELinux policy? ie:
chgrp named /etc/named.conf
chmod 640 /etc/named.conf
ala
-rw-r----- 1 root named 1323 Aug 25 2004 /etc/named.conf
How about this same question at a more general level.
What is the current practice regarding syncing up and matching SELinux
policy with the file owner/group and permissions?
Is there a current defined practice? If not, should there be? :)
Dax Kelson
Guru Labs
18 years, 9 months
Re: not installing SELinux with Fedora
by stewartetcie＠canada.com
On Sunday, 2005-06-19 at 16:08 (PDT)
Steve G <linux_4ever(a)yahoo.com> wrote:
>Its very easy to do, but you will be running your own
>distro. :) Just get a RH9 build host and use the
>rookery build system. It'll let you know which
>packages need TLC.
Beware of forks masquerading as subsystems. The offer
of mandatory access control is seductive, but the
SELinux implementation is flawed if it amounts to a
fork in the Linux code base.
>SE Linux does need some help in managing policy.
...
>This what's missing from SE Linux.
>A good configuration for the non-security expert.
If that were the only problem, it would be enough to
preclude the inclusion of SELinux from a general
purpose Linux distribution until such time as good
management tools are available.
On Monday, 2005-06-20 at 07:10 (PDT)
Stephen Smalley <sds(a)tycho.nsa.gov> wrote:
>Most distributions don't want to have to ship
>multiple variations of the kernel and userland, so
>they naturally don't want to have ship a SELinux and
>non-SELinux variant of kernel, coreutils, etc.
Yikes, I should have anticipated this, given the forum
and the topic, but, in the immortal words of Monte
Python, "No-one ever expects the Spanish inquisition!"
Let's be clear about one thing. I am neither a devil,
nor am I a devil's advocate and I really can't find the
time right now for an extended vacation at a U.S.
resort in Cuba, or even an unscheduled layover in
Syria. I know you guys listen to everything, all the
time, everywhere, but when my girl friend said, "Oh,
you devil," that was just a figure of speech. Really.
Now, let's approach the topic under discussion one step
at a time, as a Jesuit would.
Connecting to the internet can be risky, because we
don't know who else has an internet connection, or what
malicious plans they may have. So intellectual property
developers often disconnect clusters used as render
farms for movie production, or compile farms used for
code production, from external networks. This is as
appropriate for protecting open source products from
damage as it is for protecting proprietary products
from theft. In fact, many private nets don't connect to
the internet. SWIFT, the Society for Worldwide
Interchange and Funds Transfer, is a case in point.
Isolation provides strong security and we're not likely
to stop doing it anytime soon, but it is inappropriate
for all cases. That's why we use multi-homed firewalls
to interconnect the internet to a DMZ for the servers
that provide internet services and to the internal
firewalls that protect local area networks. This works
pretty well, even better since IP Tables came along,
and the proof is that most of the systems compromised
by intruders either lack such protection, or don't have
it configured properly.
Wouldn't it be nice to have a general purpose operating
system that could be pruned and tuned for optimal
performance on isolated systems, firewalls, servers,
workstations, or laptops for road warriors? Oh, and it
must be open source, because we can't validate system
security unless we can audit the code. Certification
requires certainty. A number of operating systems meet
these criteria.
One candidate is Linux (a. k. a. non-SELinux). If I
have to roll my own distro from Fedora in order to
optimize performance by removing unnecessary
subsystems, such as mandatory access control on an
isolated system, then Fedora is no longer a general
purpose system and it is no longer Linux, now it is
SELinux.
These comments are offered in the spirit of
constructive criticism. I'm grateful you declared your
bias, for your spirited defence of your product and
very grateful SELinux was contributed to the open
source community, warts and all. However, SELinux isn't
the only possible implementation of mandatory access
control for Linux (cf. sHype). If my criticicms are
valid, SELinux must either be improved, or it'll be
replaced by a better implementation. Perhaps I'm wrong.
Time will tell. Meanwhile, thanks for listening.
18 years, 9 months
using selinux to control user access to files
by Hein Coulier
hi, newby speaking here (totally lost in the selinux labyrinth).
What i want to accomplish with selinux is the following : i want to allow
different end-users (with different roles) to do something with some files.
I'll give you an example :
fileA : may be read by roleA and roleB
fileB : may only be read by roleB ; audited
fileC : may be read and changed by roleB ; audited
I read several pdf's, read the o'reilly book, but i seem to be unable to
achieve my goal.
Help would be appreciated.
tia, hecou.
18 years, 9 months
soundcards, anyone?
by Brian
Hello:
A book I am reading suggests that to find out what soundcards are
well-supported for Fedora and Red Hat Enterprise, to visit
"http://www.hardware.redhat.com". An interesting site, to be sure, but
it does not offer the list I would like to see. Does anyone know of such
a list?
Brian
18 years, 9 months
Selinux and bluetooth
by Paul Lacatus
I just installed FC4 on a laptop . Fresh install not upgrade. I was
trying to start my GPRS connection over bluetooth as I did in FC3. The
bluetooth service does not seem like working. Looking in the logs (
messages) I found:
Jul 9 23:56:02 fujitsu1020 hcid[3934]: Bluetooth HCI daemon
Jul 9 23:56:02 fujitsu1020 hcid[3934]: Can not open
/etc/bluetooth/hcid.conf
Jul 9 23:56:02 fujitsu1020 hcid[3934]: Config load failed
Jul 9 23:56:02 fujitsu1020 hcid[3934]: Can't open PIN file
/etc/bluetooth/pin: Permission denied (13)
Jul 9 23:56:02 fujitsu1020 sdpd[3936]: Bluetooth SDP daemon
All this files exist, have 644 permissions and corect in format since I start hcid and run "rfcomm bind all" by hand the bluetooth connection start working.
The problem is selinux since I modify to "permissive" all is working as expected. In "enforcing" is not working anymore. I think that selinux is preventing access to configuration files. I have all updates to the day.
Paul
18 years, 9 months
