When new policy & policy-sources packages get downloaded and installed from development, do I need to do:
cd /etc/security/selinux/src/policy make load make relabel
or is that only when first enabling SELinux?
Jeff
Has anyone started a selinux+fedora how-to? Is the old Red Hat Documentation being updated for fedora? That seems like it would be a good place to start from and add on to.
Dan
Quoting "Jeffrey C. Ollie" jeff@ollie.clive.ia.us:
When new policy & policy-sources packages get downloaded and installed from development, do I need to do:
cd /etc/security/selinux/src/policy make load make relabel
or is that only when first enabling SELinux?
Jeff
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Sat, 6 Mar 2004, Jeffrey C. Ollie wrote:
When new policy & policy-sources packages get downloaded and installed from development, do I need to do:
cd /etc/security/selinux/src/policy make load make relabel
Yes.
- James
James Morris (jmorris@redhat.com) said:
When new policy & policy-sources packages get downloaded and installed from development, do I need to do:
cd /etc/security/selinux/src/policy make load make relabel
Yes.
Does this mean policy *never* gets updated on a new rpm install without manual intevention? This seems bad.
Bill
On Mon, Mar 08, 2004 at 02:20:36AM -0500, Bill Nottingham wrote:
James Morris (jmorris@redhat.com) said:
When new policy & policy-sources packages get downloaded and installed from development, do I need to do:
cd /etc/security/selinux/src/policy make load make relabel
Yes.
Does this mean policy *never* gets updated on a new rpm install without manual intevention? This seems bad.
If I understand this...
In development cycles having the "current" best practice policy does make sense for some, but not outside the context of "default policy development".
The more general procedure would be to
cd /etc/security/selinux/src/policy # examine, compare with current, update for local needs, scratch, validate... then # iff all is ok make load make relabel
In fact the "policy" on "policy updates" should be the most constrained in the pile.
Tom Mitchell (mitch48@sbcglobal.net) said:
If I understand this...
In development cycles having the "current" best practice policy does make sense for some, but not outside the context of "default policy development".
Yes, but if you're pushing new policy that actually fixes bugs (think post-release here), you'd want that automatically installed on upgrade.
Bill
On Mon, Mar 08, 2004 at 11:07:43AM -0500, Bill Nottingham wrote:
Tom Mitchell (mitch48@sbcglobal.net) said:
If I understand this...
In development cycles having the "current" best practice policy does make sense for some, but not outside the context of "default policy development".
Yes, but if you're pushing new policy that actually fixes bugs (think post-release here), you'd want that automatically installed on upgrade.
I believe Jeff was working on this, however the hooks would have to be in rpm I imagine as you probably don't want rpm_script_t having write access to policy_src_t right?
Paul
On Tue, 9 Mar 2004 03:06, Paul Nasrat pauln@truemesh.com wrote:
On Mon, Mar 08, 2004 at 11:07:43AM -0500, Bill Nottingham wrote:
Tom Mitchell (mitch48@sbcglobal.net) said:
If I understand this...
In development cycles having the "current" best practice policy does make sense for some, but not outside the context of "default policy development".
Yes, but if you're pushing new policy that actually fixes bugs (think post-release here), you'd want that automatically installed on upgrade.
I believe Jeff was working on this, however the hooks would have to be in rpm I imagine as you probably don't want rpm_script_t having write access to policy_src_t right?
At the moment rpm_script_t has access to so much that there's no point in trying to impose any serious restriction on it.
I suspect that limiting rpm_script_t in any significant way will have to wait until we have multiple domains for rpm for installing packages with different signatures.
On Tue, Mar 09, 2004 at 03:21:34AM +1100, Russell Coker wrote:
On Tue, 9 Mar 2004 03:06, Paul Nasrat pauln@truemesh.com wrote:
On Mon, Mar 08, 2004 at 11:07:43AM -0500, Bill Nottingham wrote:
Tom Mitchell (mitch48@sbcglobal.net) said:
If I understand this...
In development cycles having the "current" best practice policy does make sense for some, but not outside the context of "default policy development".
Yes, but if you're pushing new policy that actually fixes bugs (think post-release here), you'd want that automatically installed on upgrade.
I believe Jeff was working on this, however the hooks would have to be in rpm I imagine as you probably don't want rpm_script_t having write access to policy_src_t right?
At the moment rpm_script_t has access to so much that there's no point in trying to impose any serious restriction on it.
I suspect that limiting rpm_script_t in any significant way will have to wait until we have multiple domains for rpm for installing packages with different signatures.
Are there thoughts for design changes to rpm. Hooks where the trust/level of rpm changes when packages are unsigned, when rpm is going to install or update digital signatures or updates to rpm itself. Some interesting flags... rpm --nosignature --nopreun --nopostun At what level do scriptlets run.
For now what are the tactical thoughts on updating policy during development. Is it as simple as kernel (/usr/src/linux*) where the top level dir famous name is a link to a versioned dir or will rpmnew/rpmsave be the norm. Since "rpm" is not universal what strategy has a chance of working with or without rpm so higher level SELinux documentation will get the right thing to happen.
Do/should tools like up2date and yum have standard exclusion rules (like kernel*) that will keep the old and the new side by side for comparison.
cd /etc/security/selinux/src diff -d policy policy.previous # stop look and listen. cd /etc/security/selinux/src/policy # policy could be a symlink to policy.newest make make relabel
If you're pushing new policy that actually fixes bugs will it break site policy? I would be unhappy if my co-lo box had this line changed. ;-) # uncomment to allow ssh logins as sysadm_r:sysadm_t define(`ssh_sysadm_login')
On Tue, 9 Mar 2004 04:53, Tom Mitchell mitch48@yahoo.com wrote:
If you're pushing new policy that actually fixes bugs will it break site policy? I would be unhappy if my co-lo box had this line changed. ;-) # uncomment to allow ssh logins as sysadm_r:sysadm_t define(`ssh_sysadm_login')
This is a difficult issue. For Debian I have it ask a heap of questions at policy upgrade time about replacing policy files, but lots of people seem to dislike that.
One possibility is to replace files that have not been changed. However that means that if a macro changes without the calling code changing then it could break policy compiles.
Hi,
On Tue, 2004-03-09 at 04:33, Russell Coker wrote:
One possibility is to replace files that have not been changed. However that means that if a macro changes without the calling code changing then it could break policy compiles.
That's basically what %config will do in rpm. It's probably the simplest default behaviour for things like tunables.te.
--Stephen
On Tue, 9 Mar 2004 18:11, "Stephen C. Tweedie" sct@redhat.com wrote:
On Tue, 2004-03-09 at 04:33, Russell Coker wrote:
One possibility is to replace files that have not been changed. However that means that if a macro changes without the calling code changing then it could break policy compiles.
That's basically what %config will do in rpm. It's probably the simplest default behaviour for things like tunables.te.
Yes, that will work quite well for tunable.te except when we add a new entry that defaults to enabled. If we produce a new policy that has define(`do_whatever') in the default tunable.te then users of the old policy won't get it. This may make things more difficult for us. But I guess we could make every default be a non-define (IE if you keep the old tunable.te you get the new default).
More difficult is macros/program/ directory, if someone changes files in that then the upgrade becomes a lot more difficult to manage.
Hi,
On Tue, 2004-03-09 at 11:57, Russell Coker wrote:
That's basically what %config will do in rpm. It's probably the simplest default behaviour for things like tunables.te.
Yes, that will work quite well for tunable.te except when we add a new entry that defaults to enabled. If we produce a new policy that has define(`do_whatever') in the default tunable.te then users of the old policy won't get it.
That's true, but they _will_ get log output telling that the new config file has been created as tunables.te.rpmnew, and they can merge it themselves. There's really no straightforward way to get any better automation for it than that, right now, unless we move each tunable to a separate file in a tunables/ directory (and it might well make sense to do that, at least to group related tunables together.)
Cheers, Stephen
Russell Coker wrote:
On Tue, 9 Mar 2004 04:53, Tom Mitchell mitch48@yahoo.com wrote:
If you're pushing new policy that actually fixes bugs will it break site policy? I would be unhappy if my co-lo box had this line changed. ;-) # uncomment to allow ssh logins as sysadm_r:sysadm_t define(`ssh_sysadm_login')
This is a difficult issue. For Debian I have it ask a heap of questions at policy upgrade time about replacing policy files, but lots of people seem to dislike that.
One possibility is to replace files that have not been changed. However that means that if a macro changes without the calling code changing then it could break policy compiles.
RPM should leave the tunable.te file and create a tunable.te.rpmnew file.
Bill Nottingham wrote:
James Morris (jmorris@redhat.com) said:
When new policy & policy-sources packages get downloaded and installed from development, do I need to do:
cd /etc/security/selinux/src/policy make load make relabel
Yes.
Does this mean policy *never* gets updated on a new rpm install without manual intevention? This seems bad.
Bill
No we are working to make rpm do this automatically.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
Jeffrey C. Ollie wrote:
When new policy & policy-sources packages get downloaded and installed from development, do I need to do:
cd /etc/security/selinux/src/policy make load make relabel
or is that only when first enabling SELinux?
Usually a make load is all that is necessary. You need to relabel when the file context changes, but we are trying to keep that to a minimum.
Jeff
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
selinux@lists.fedoraproject.org
-
Bill Nottingham -
Daniel J Walsh -
Daniel Wittenberg -
James Morris -
Jeffrey C. Ollie -
Paul Nasrat -
Russell Coker -
Stephen C. Tweedie -
Tom Mitchell -
Tom Mitchell