lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-Id: <1174598630.3085.285.camel@faith.austin.ibm.com> Date: Thu, 22 Mar 2007 15:23:50 -0600 From: Joy Latten <latten@...tin.ibm.com> To: David Miller <davem@...emloft.net> Cc: selinux@...ho.nsa.gov, netdev@...r.kernel.org, jmorris@...ei.org, vyekkirala@...stedcs.com Subject: Re: [PATCH]: Add security check before flushing SAD/SPD On Thu, 2007-03-22 at 12:01 -0700, David Miller wrote: > From: Joy Latten <latten@...tin.ibm.com> > Date: Thu, 22 Mar 2007 12:35:39 -0600 > > > Within selinux we check for authorization before deleting entries from > > SAD and SPD. > > > > We are not checking for authorization when flushing the SPD and > > the SAD. It was perhaps missed in original patch. > > > > This patch adds security check when flushing entries from SAD and SPD. > > > > Please let me know if this patch is ok. > > It was built against linux-2.6.21-rc4-git5. I have also tested it. > > > > Signed-off-by: Joy Latten<latten@...tin.ibm.com> > > I don't understand this and it does not sit well with me. > > If we are flushing the policy database, we are flushing it > regardless of what the security layer might or might not say. > > I would look at this patch differently if there were some > security level key being checked for a match here, which is > an input key to the flush, but that is not what is happening > here as the object is being looked at by itself. Yes, I understand what you are saying. I was concerned about having to check each entry to flush database. I did this patch because we check for authorization when deleting single specified entries from the SAD/SPD. It seem like a hole to me that we check for this, but that same user/process can delete the entire database with no checks. Unfortunately, each policy entry or SA can have a different security label. And that is why I would have to check each entry's security label before deleting. To see if the user/process has authorization to delete an entry with that security label. Including selinux list for suggestions. Joy - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists