[rsbac] WorkStation kernel
Andrea Pasquinucci
cesare at ucci.it
Wed Sep 21 17:26:32 CEST 2005
Dear Kang,
I'll try to make a long story short...
- after 1.2.5 will be out, I will prepare a new version of my fedora
_server_ rpms for Fedora 4, these will have all MAC features,
including separation of duty ecc. (I have a few things that I want to
add to it, like a working auditor role ecc.)
- if you read carefully my message about the workstation rpms, you'll
notice that there is NOT the AUTH module in the kernel !!!!!!!!! WHY?
Well you have to consider carefully the setup I am working with:
workstations with default install of Fedora and daily automatic
updates of all rpms (with yum), pratically NO HAND CONFIGURATION and
the user does not know the root password. In this setup I have 2
choices: go with RedHat kernels with Selinux and Exec-shield, OR try
to do something better :-), and this is what I am trying to do.
Instead of Selinux + exec-shield I have a RSBAC kernel _only_ with
PAX, DAZ and RES. True I do not have any separation of duty (but
neither has the RedHat kernel) nor MAC protection of executables, only
DAC protection (which means that root can do all what he wants). On
the other side I have DAZ and RES (which I have still to setup as I'd
like), a big plus for me.
The most important point is that the whole thing works by doing a
single "yum install rsbac....." on every machine and a reboot, after
that no configuration, no nothing to do (and all updates come
automatically too).
I have tried to have AUTH in the kernel, but there are so many
programs that need to get auth to do something in a workstation setup,
that it is a practically impossible task to include it, the only way
would be to do a new distribution: Fedora+RSBAC
Moreover, in this setup at boot and after yum runs I need to re-apply
the rsbac rights.
- Not having AUTH, I can do "su secoff -c .." to add rules (for DAZ and
PaX), otherwise as you say I should boot in softmode and then after
setting the rights, switch to enforcing mode (but my kernel runs
always in enforcing mode)
- About Wrappers: freshclam runs as user 'clamav' on Fedora, how can I
make it do a 'daz_flush'? with a suid wrapper seems to be reasonably
secure, notice that the wrapper does _not_ accept any parameters, so
there is no risk to make it doing other things; the only risk I see is
a DoS attack of a stupid user that keeps running it. I have used this
approach with wrappers with no parameters in other situations, and in
the appropriate circumstances I believe that they are resonably ok, if
not, please explain me why (after you read the code).
Andrea
On Wed, Sep 21, 2005 at 04:01:08PM +0200, kang wrote:
* Andrea Pasquinucci wrote:
*
* >Hi all,
* >
* >I have uploaded to http://fedora.rsbac.mprivacy-update.de/4_ws/ a
* >rpm of a compiled kernel + rsbac_admin tools and a rpm for configuration
* >scripts et al, for a very simple workstation setup running Fedora Core 4.
* >
* >There is not MAC protection but only DAZ, RES, PAX and FF modules. My
* >aim is to protect normal workstation users from
* >
* >- buffer overflows and similar (PaX)
* >- exhaustion of resources (RES)
* >- virus, worms and similar (DAZ + clamd)
* >
* >Each user can add simple MAC features using the FF module.
* >
* >There are major constraints in this setup: it must be compatible with
* >the distribution and must require _no_ user intervention to setup, only
* >automatic tools.
* >
* >NOTICE: this is really VERY PRELIMINARY (for example I haven't yet
* >understood why flash doesn't work anymore in firefox, nor added any RES
* >protection yet).
* >
* >TEST at your own risk, but if anyone is interested, please help.
* >
* >Andrea
* >
* >PS. more info in the README and INSTALL files there
* >
* >
* >
*
* Hi!
* I don't use Fedora but i've been looking a bit through your scripts.
* First thing is, in etc/rc.d/init.d/clamd.rsbac i see:
* su secoff -c "/usr/local/rsbac/bin/attr_set_fd DAZ FD daz_scanner 1
* /usr/sbin/clamd
*
* But I haven't seen something like booting into softmode and reverting to
* secure mode after boot is complete.
* Well, that probably means you let root changing to secoff user ?
* That's bad ! :)
* no one should be able to use the secoff without secoff password because
* its the key of privilege separations. Actually, we usually deny su to
* setuid and you have to login with secoff on the console or with ssh.
*
* Ive the same comment about your rsbac_daz_flush_wrapper.c which does
* setuid(400)
*
* Else nice work, I would be happy to see fedora people using a full
* preworking rsbac setup for their desktop :)
*
* kang
*
--
Andrea Pasquinucci cesare at ucci.it
PGP key: http://www.ucci.it/ucci_pub_key.asc
fingerprint = 569B 37F6 45A4 1A17 E06F CCBB CB51 2983 6494 0DA2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rsbac.dyndns.org/pipermail/rsbac/attachments/20050921/492cd103/attachment.bin
More information about the rsbac
mailing list