This list is closed, nobody may subscribe to it.
2007 |
Jan
|
Feb
(10) |
Mar
(26) |
Apr
(8) |
May
(3) |
Jun
|
Jul
(26) |
Aug
(10) |
Sep
|
Oct
|
Nov
(2) |
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
|
Feb
(13) |
Mar
(4) |
Apr
(3) |
May
(5) |
Jun
|
Jul
(7) |
Aug
(8) |
Sep
(5) |
Oct
(16) |
Nov
|
Dec
(6) |
2009 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
(19) |
Jul
(4) |
Aug
|
Sep
(13) |
Oct
(10) |
Nov
(12) |
Dec
(2) |
2010 |
Jan
|
Feb
(2) |
Mar
(17) |
Apr
(28) |
May
|
Jun
(17) |
Jul
(11) |
Aug
(12) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
2011 |
Jan
|
Feb
|
Mar
(20) |
Apr
(10) |
May
(1) |
Jun
|
Jul
|
Aug
(15) |
Sep
(14) |
Oct
(2) |
Nov
|
Dec
|
2012 |
Jan
(1) |
Feb
(53) |
Mar
(15) |
Apr
(4) |
May
(2) |
Jun
(13) |
Jul
|
Aug
|
Sep
(12) |
Oct
|
Nov
|
Dec
(6) |
2013 |
Jan
(7) |
Feb
(8) |
Mar
(4) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
(6) |
Oct
|
Nov
(5) |
Dec
(8) |
2014 |
Jan
(17) |
Feb
(24) |
Mar
(8) |
Apr
(7) |
May
(18) |
Jun
(15) |
Jul
(5) |
Aug
(2) |
Sep
(49) |
Oct
(28) |
Nov
(7) |
Dec
(30) |
2015 |
Jan
(40) |
Feb
|
Mar
(9) |
Apr
(2) |
May
(9) |
Jun
(31) |
Jul
(33) |
Aug
(5) |
Sep
(20) |
Oct
|
Nov
(3) |
Dec
(12) |
2016 |
Jan
(14) |
Feb
(29) |
Mar
(10) |
Apr
(4) |
May
(4) |
Jun
|
Jul
(5) |
Aug
(19) |
Sep
(21) |
Oct
(2) |
Nov
(36) |
Dec
(30) |
2017 |
Jan
(101) |
Feb
(12) |
Mar
(7) |
Apr
(2) |
May
(29) |
Jun
(22) |
Jul
(7) |
Aug
(93) |
Sep
(27) |
Oct
(39) |
Nov
|
Dec
|
From: Herbert Xu <he...@go...> - 2017-06-10 04:29:01
|
On Mon, May 29, 2017 at 11:22:48AM +0300, Gilad Ben-Yossef wrote: > > +static inline int crypto_wait_req(int err, struct crypto_wait *wait) > +{ > + switch (err) { > + case -EINPROGRESS: > + case -EBUSY: > + wait_for_completion(&wait->completion); > + reinit_completion(&wait->completion); > + err = wait->err; > + break; > + }; > + > + return err; > +} This assumes that the request is used with backlog. For non-backlog requests this would result in a memory leak as EBUSY in that case is a fatal error. So this API can't be used without backlog. We could introduce a flag to indicate whether we want backlog or not, or maybe we should change our API so that in the non-backlog case we return something other than EBUSY. Opinions? Thanks, -- Email: Herbert Xu <he...@go...> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt |
From: Nayna <na...@li...> - 2017-06-09 13:43:33
|
On 06/08/2017 02:25 PM, Micka wrote: > Hi, > > I would like to know what boot aggregate measure means ? It is an aggregated hash of PCRS 0-7. > > I have a problem, my PCR 10 is changing every time I reboot my device: > > 10 ddee6404dc3bd4ee300406cd93181c5a2187b59b ima-ng > sha1:9797edf8d9eed36b1cf92547816a51c8af4e45ee boot_aggregate > You can verify your boot_aggregate by using the test scripts from package ltp-ima-standalone-v2.tar.gz as available on: https://sourceforge.net/projects/linux-ima/ Steps to use it are specified in below link: http://linux-ima.sourceforge.net/linux-ima-measurements.html Thanks & Regards, - Nayna > I have only activated: ima_audit=1 > > Michael Musset, > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > _______________________________________________ > Linux-ima-user mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-ima-user > |
From: Rock L. <roc...@gm...> - 2017-06-09 10:06:33
|
> > tar and rpm have support for storing file signatures in extended > attributes, and many backup tools support storing and restoring xattrs as > well. I agree with you. But I tried tar for many times, it seems doesn't work. Since tar is under GPLv3, and I don't want GPLv3, so I don't bother with tar ;-). Instead, dar is perfect tools to keep the xattrs as I expected. It is kind of tricky to keep xattrs during update. For example, sometimes I need to transmit(like scp) files with signature to a IMA enabled device, it is hard to keep the signature (although rsync is capable of doing this). And some filesystems, they don't support xattrs (like vfat, sorry to metion this fs, but sometimes I need to use adb to push files), which makes me a little headache. If signature can be kept in a sig file, and IMA is able to load signature from this .sig, it would be perfect. I noticed Tizen supports loading .sig files https://wiki.tizen.org/Security:IntegrityMeasurement/Examples But it seems Linux doesn't support this feature yet. > >> BTW, do the .sig files used for appended signatures feature? And how >> can I generate a file with append signature ? > > My patches allow checking for appended signatures in a limited number of > IMA hooks: FIRMWARE_CHECK, KEXEC_KERNEL_CHECK and KEXEC_INITRAMFS_CHECK. > > The appended signature support uses the same format that the Linux kernel > uses for signing modules, which is different from what evmctl generates. > > You can add appended signatures to files using the sign-file tool from the > Linux kernel source code. See this document for details on how to use it: > > https://www.kernel.org/doc/html/latest/admin-guide/module-signing.html > > -- > Thiago Jung Bauermann > IBM Linux Technology Center > -- Cheers, Rock |
From: Thiago J. B. <bau...@li...> - 2017-06-08 18:50:02
|
Rock Lee <roc...@gm...> writes: > Mimi Zohar <zo...@li...> writes: >> You can't, but yesterday Thiago Bauermann posted patches for adding >> appended signature support. > > Wow, it's really a good news. I was looking for a perfect way for > upgrading purpose (through network). And I found IMA is a good way to > support my goals. But IMA stores signature in xattr which is not very > convenient for me to upgrade my device. Because xattrs are seperate > from the real file data and it can be lost easily, so I need to keep > the xattrs carefully. But with the appended signature featues, > signature is treated as a part of file data, I don't need to worry > about the xattrs things. Did I miss something ? tar and rpm have support for storing file signatures in extended attributes, and many backup tools support storing and restoring xattrs as well. > BTW, do the .sig files used for appended signatures feature? And how > can I generate a file with append signature ? My patches allow checking for appended signatures in a limited number of IMA hooks: FIRMWARE_CHECK, KEXEC_KERNEL_CHECK and KEXEC_INITRAMFS_CHECK. The appended signature support uses the same format that the Linux kernel uses for signing modules, which is different from what evmctl generates. You can add appended signatures to files using the sign-file tool from the Linux kernel source code. See this document for details on how to use it: https://www.kernel.org/doc/html/latest/admin-guide/module-signing.html -- Thiago Jung Bauermann IBM Linux Technology Center |
From: Rock L. <roc...@gm...> - 2017-06-08 12:20:10
|
> > You can't, but yesterday Thiago Bauermann posted patches for adding > appended signature support. > Wow, it's really a good news. I was looking for a perfect way for upgrading purpose (through network). And I found IMA is a good way to support my goals. But IMA stores signature in xattr which is not very convenient for me to upgrade my device. Because xattrs are seperate from the real file data and it can be lost easily, so I need to keep the xattrs carefully. But with the appended signature featues, signature is treated as a part of file data, I don't need to worry about the xattrs things. Did I miss something ? BTW, do the .sig files used for appended signatures feature? And how can I generate a file with append signature ? -- Cheers, Rock |
From: Mimi Z. <zo...@li...> - 2017-06-08 11:49:15
|
On Thu, 2017-06-08 at 16:59 +0800, Rock Lee wrote: > Hi, > > Besides storing IMA signature in xattr of a file, we can also store it > in a .sig file. If I store the signature in a .sig file, how can I > make the kernel load the signature form .sig file instead of from > xattr of a file ? > > Use this command to generate a .sig file. > evmctl ima_sign -f --key /etc/ima/public.key foo > > After this, we will get a foo.sig You can't, but yesterday Thiago Bauermann posted patches for adding appended signature support. Mimi |
From: Rock L. <roc...@gm...> - 2017-06-08 08:59:30
|
Hi, Besides storing IMA signature in xattr of a file, we can also store it in a .sig file. If I store the signature in a .sig file, how can I make the kernel load the signature form .sig file instead of from xattr of a file ? Use this command to generate a .sig file. evmctl ima_sign -f --key /etc/ima/public.key foo After this, we will get a foo.sig -- Cheers, Rock |
From: Micka <mic...@gm...> - 2017-06-08 08:56:12
|
Hi, I would like to know what boot aggregate measure means ? I have a problem, my PCR 10 is changing every time I reboot my device: 10 ddee6404dc3bd4ee300406cd93181c5a2187b59b ima-ng sha1:9797edf8d9eed36b1cf92547816a51c8af4e45ee boot_aggregate I have only activated: ima_audit=1 Michael Musset, |
From: Micka <mic...@gm...> - 2017-06-07 13:13:24
|
I would like to configure the IMA to take account the Mac address of the device ? Which part of Linux can help me on this topic ? Is it the U-boot job to do that ? And what exactly the boot aggregate measure ? Thanks everyone for the help, Le mer. 15 mars 2017 à 22:26, Ken Goldman <kg...@li...> a écrit : > On 3/15/2017 10:01 AM, Micka wrote: > > Do you know where I can find documentation about others PCRs ? which > > project/binary use those PCRs ? > > In general, pre-OS code uses PCR 0-7. PCR 8-15 are post-OS. The DRTM > stuff is at 17-22. > > Bitlocker uses 0-5, 8-11. > > I don't know of anything else in the Linux space other than PCR 10 for IMA. > > Avoid 15 and 23, which are resettable, unless you understand the > implications. > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Linux-ima-user mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-ima-user > |
From: Mimi Z. <zo...@li...> - 2017-06-02 20:54:12
|
On Fri, 2017-06-02 at 17:16 +0800, Rock Lee wrote: > > if you are a normal user, then you will not see any of the security.* > > attributes. If you are the root user, then they should display as well. > > > > If you are user root, the command you want should be > > > > tar --xattrs -cvjf file.tar.bz2 file > > > > assuming that you are using a version of tar that has been built to > > handle extended attributes. > > > > See also > > > > https://unix.stackexchange.com/questions/300168/how-do-i-get-a-dump-of-all-extended-attributes-for-a-file > > Hi Mark: > > Unfortunately, it seems tar does work well with security namespace > extend attributes(SMACK, IMA). I found dar is capable of archiving > files with all the extended attributes. Thanks anyway. As I recall, you need to include "--xattrs" when creating the tar, and then "--xattrs --xattrs-include=security.ima" when installing the tar. Installing tar packages containing file signatures requires a kernel with commit: 5d1a717ec04 "ima: add support for creating files using the mknodat syscall" Mimi |
From: Rock L. <roc...@gm...> - 2017-06-02 09:16:26
|
> if you are a normal user, then you will not see any of the security.* > attributes. If you are the root user, then they should display as well. > > If you are user root, the command you want should be > > tar --xattrs -cvjf file.tar.bz2 file > > assuming that you are using a version of tar that has been built to > handle extended attributes. > > See also > > https://unix.stackexchange.com/questions/300168/how-do-i-get-a-dump-of-all-extended-attributes-for-a-file Hi Mark: Unfortunately, it seems tar does work well with security namespace extend attributes(SMACK, IMA). I found dar is capable of archiving files with all the extended attributes. Thanks anyway. -- Cheers, Rock |
From: Mark D. B. <md...@ju...> - 2017-06-02 05:16:07
|
Rock Lee <roc...@gm...> writes: > I want to tar files with security.ima but failed. I tried command > like this: > > tar cvjf file.tar.bz2 file --xattrs > > I noticed user namespace extened attribute would be preseved, but > security.ima would be lost. Could anyone give me some advices ? You should try this command: getfattr -d -m . file if you are a normal user, then you will not see any of the security.* attributes. If you are the root user, then they should display as well. If you are user root, the command you want should be tar --xattrs -cvjf file.tar.bz2 file assuming that you are using a version of tar that has been built to handle extended attributes. See also https://unix.stackexchange.com/questions/300168/how-do-i-get-a-dump-of-all-extended-attributes-for-a-file Enjoy! -- Mark |
From: Rock L. <roc...@gm...> - 2017-06-02 04:07:51
|
Hi : I want to tar files with security.ima but failed. I tried command like this: tar cvjf file.tar.bz2 file --xattrs I noticed user namespace extened attribute would be preseved, but security.ima would be lost. Could anyone give me some advices ? -- Cheers, Rock |
From: Dr. G. W. <gr...@en...> - 2017-05-31 09:50:23
|
On Mon, May 29, 2017 at 01:32:38PM -0400, Mimi Zohar wrote: > Hi Guilherme, > > (Wow, you should did Cc a lot of people.) Indeed. We have namespaced a significant amount of the IMA code so we will continue the broadcast, under the assumption that this is of general interest to the community. Comments below. > On Thu, 2017-05-25 at 19:04 +0000, Magalhaes, Guilherme (Brazil R&D- > CL) wrote: > > Mimi, > > With the securityfs symlink we would address the case of setting > > policy inside containers, but we still would need a way to set the > > IMA policy per namespace outside containers. So, the current > > proposed interface would address the latter case. > > As an alternative to symlinks, taking this patch set as base, and > > still considering setting policy inside containers (or inside > > namespaces in general), it is possible to bind mount the securityfs > > files into the containers, but it would be needed to prevent > > read/write access to the namespaced IMA policy files for processes > > not running on the same namespace. > > > > These mechanisms would not require a change in the proposed design. > > Do you think these mechanisms are enough for the flexibility you > > asked? > > I'm really sorry Guileherme, but as I previously explained, IMA has > many aspects to it - the original file measurements (IMA-measurement), > file hash/signature appraisal (IMA-appraisal), and file audit messages > (IMA-audit) used for security analytics/forensics, not the file system > auditing.????To namespace IMA properly requires addressing some > underlying problems - securityfs, root privilege required for writing > security xattrs, per namespace IMA keyring - to name a few. > > I understand wanting to namespace the appraisal aspect first, but when > you asked me if anyone else is working on namespacing IMA at the > moment, I suggested starting with the IMA-audit aspect for a > reason.????By beginning with the IMA-audit aspect, we could ignore, at > least for the time being, some of these underlying problems, but > define the basic namespacing architecture.????By jumping to namespacing > the appraisal aspect, you've simply avoided addressing the IMA > namespacing architecture issues, which need to be addressed. > > Here are some, not by any means all, of the issues with namespacing > IMA. > > > - IMA-measurements: > > The namespacing design will need to support different types of > environments. For example, depending on the environment, namespaces > can come and go frequently. In such an environment do we really want > all the namespace measurements to be included in the system > measurement list, or should each namespace have its own measurement > list?????Should the namespace measurement policy be the same as the > system measurement policy?????Should the namespace (container) owner be > allowed to modify their own policy?????If a file matches a rule in both > the namespace and system policies, should the file measurement be in > both the namespace and the system measurement lists? > > > - IMA-appraisal > > Assuming the IMA appraisal policy requires file signatures, signatures > are verified based on the keys on the IMA keyring.????When discussing > namespacing IMA-appraisal, we might want different sets of keys in > different namespaces. This requires separate keyrings for each > namespace. ??In some use cases, we might want to include the keys on > the system IMA keyring, while in other use cases we might not. > > Even if real root initially installs the files with their file > signatures, stored as extended attributes, how will software be > updated, as writing file signatures requires root > privilege?Capabilities has recently added support to permit root in > the namespace to write security.capability.????Similarly when > namespacing IMA, root in the namespace needs the ability to write > security.ima. > > > - IMA-audit: > > The IMA-audit messages can augment other file system security > information used in security analytics/forensics.????This information > should be on a per namespace basis, meaning that each time a new file > is accessed/executed, there needs to be a separate audit message, even > if a message already exists in another namespace.????Maintaining and > cleaning up this per namespace cache information, allows development > of the IMA namespace architecture independently of other issues. > > My original suggestion stands. ??Start with namespacing IMA- > audit.????Afterwards resolve the securityfs issues needed for > namespacing IMA-measurement, and subsequently resolve the keyring and > xattr issues for namespacing IMA-appraisal. Although other subsystems > have already addressed some of the issues listed here, the advice to > start with IMA-audit is still valid. > > Small incremental change does not imply without an overall design, but > an overall design which is broken up in such a way (to ease review) > that builds upon the previous change. > > As both Apparmor and IMA use securityfs for policy, it would be nice > if their method for loading namespace policies would be similar too. Our deterministic platform modeling code is built on top of the IMA infrastructure. Our modeling implementation has namespace support so we ended up OS virtualizing a significant amount of the IMA infrastructure to implement container specific behavior modeling. So the following is under the moniker of been there, done that to some extent. As an aside, we refer to containers running in a modeled environment as 'canisters' since they are containers with a label. Based on our experiences, the community will want each namespace implementation to be as independent as possible. A primary benefit of namespaced implementations of integrity/behavior modeling is to enable more tractable deployments since the system can be run from a very small TCB whose behavior is rooted to a hardware integrity guarantee. System upgrades are way more tractable in this type of architecture. Each canister in our model has its own behavioral trajectory path which is the equivalent of a superset of the IMA measurement list. After the canister behavior is sealed, each canister reports forensics violations as new entries on the trajectory path. So forensic evaluations are enabled at the canister level, which is extremely valuable. Implementing all of this was fairly straight forward on top of the current IMA infrastructure. Mimi's recommendation to start with the audit layer is well taken, that is a solid pathway for determining how to generically address the relevant infrastructure issues. >From an implementation perspective we don't use bind mounts or the like. The securityfs pseudo-files all sense which namespace they are operating in which resulted in a much cleaner implementation, at least in our experience. We implemented a model where the behavioral eigenvectors (events) are surfaced through a new pseudo-file created for each canister. This pseudo-file is rooted in the /sys/fs/iso-identity pseudo-directory and named by the namespace inode number which was allocated for the canister namespace when the behavioral domain (namespace) is created. This could have been done as well in the securityfs filesystem but we were too {cramped for time,lazy} to implement polling and sysfs files gives you that for free. This seems to be a pretty flexible model for orchestration. We propagate the behavioral eigenvectors into individual SGX enclaves which monitor the behavior of each canister. The model would support propagating events into a vTPM as well. >From an orchestration perspective we plumbed all of this, including SGX support, into the most recent release of runc and it has all worked surprisingly well with respect to running existing containers. All you need to do is specify in the container config.json that the container is to run in an independent behavioral namespace. We do lament that runc was written in GO rather then C... :-) There are some rough edges which need polishing though. A more expressive and namespace specific policy engine needs to be addressed. In addition to the namespace implementation we implemented superblock independent content digests which closes what we believe is a rather significant measurement gap. Addressing network inode measurement is an entirely new and different can of worms as well. We have also spent a fair amount of time reflecting on Viro's rants with respect to IMA and all of its inherent ugliness... :-) Our major concern is what does the community want to do with respect to defining the CLONE_* flag which is used to signal that the integrity/behavior namespace should be unshared. We currently build on top of 4.4 LTS and we stole the last bit which was available. What are the thoughts with respect to expanding this resource as it won't be the last OS virtualization which is undertaken? > Mimi Hopefully the above reflections and experiences are useful datapoints. Have a good week. Greg As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102 development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: gr...@en... ------------------------------------------------------------------------------ "We can't solve today's problems by using the same thinking we used in creating them." -- Einstein |
From: Mimi Z. <zo...@li...> - 2017-05-30 02:28:20
|
On Mon, 2017-05-29 at 20:34 +0000, Magalhaes, Guilherme (Brazil R&D- CL) wrote: <snip> > >- IMA-audit: > > >The IMA-audit messages can augment other file system security information > >used in security analytics/forensics. This information should be on a per > >namespace basis, meaning that each time a new file is accessed/executed, > >there needs to be a separate audit message, even if a message already exists > >in another namespace. Maintaining and cleaning up this per namespace cache > >information, allows development of the IMA namespace architecture > >independently of other issues. > My understanding is that the Audit subsystem manages on its own, by using a > daemon per user namespace, the separation of messages per namespace. Audit > API (audit_log_start, audit_log_end, etc) clients, on its turn, must generate the > proper record and then use the Audit API to queue that record. What we did was > to add enough fields to the record to properly identify a pathname, considering > multiple mount namespaces. I thought this is what was missing on the IMA > perspective. Please clarify. I'm referring to the IMA-audit messages that were introduced in e7c568e0fd0c "ima: audit log hashes". Appending the namespace identification information to the existing information is not enough. The IMA-audit message needs to be generated the first time in each namespace. This requires storing the per namespace information separately from the common information, for example the file hash. The main difficulties are in how the common information vs. the per namespace information are stored, referenced, and cleaned up. Cleanup will need to address when either the namespace itself or a dentry is deleted. All of the different IMA aspects require storing, on a per namespace basis, IMA namespace specific information (eg. audit status within the namespace, measurement status within the namespace, appraisal results based on different policies/keys). Once the architecture is defined, namespacing the other IMA aspects should be straight forward. Mimi |
From: John J. <joh...@ca...> - 2017-05-29 21:50:00
|
On 05/29/2017 01:34 PM, Magalhaes, Guilherme (Brazil R&D-CL) wrote: > Hi Mimi, > Thanks for the feedback. > >> (Wow, you should did Cc a lot of people.) > Reducing the list for now. > << snip >> > > >> As both Apparmor and IMA use securityfs for policy, it would be nice if their >> method for loading namespace policies would be similar too. > Ok, we need to take a look then. > Some context to help you AppArmor policy namespaces are hierarchical in layout. Where a parent can create children namespaces, and those children can create grand children. Within securityfs this hierarchy is visible from apparmor/policy/ AppArmor tracks which policy namespace a task is in, and this determines what policy is available to the task, both for enforcement and visibility. Generally a task with rights to manage policy can load policy into its namespace and that namespaces children, but a task in a child namespace can not load policy into a parent namespace, ideally it shouldn't even be able to see it. The goal being to allow tasks within a namespace to manage it/ think about as though it is the root system namespace. Probably the simplest example for this is LXD on ubuntu where it creates a child namespace for its container, and the container OS can load apparmor policy without worrying about the rest of systems apparmor policy. To achieve this apparmor had to "virtualize" most of its files so that they change input/output based on the policy namespace of the task that opens them. This works well for files but does not work for the policy directory trees. To deal with the policy directory tree we create a special apparmorfs which is not available to mount from userspace and we do a kern mount on it as part of our setup. apparmor/policy becoming a magic symlink that is dynamically resolved to the correct subtree in apparmorfs for a given policy namespace. The links look like apparmor/policy -> apparmorfs:[1234] This gives us the virtualization without having to mess with the mount namespace (bind mounts), without requiring changes to userspace around mounts, or management assumptions (securityfs), and it matches with what nsfs is doing, so there is precedence for this approach. I will further add, this is just our solution for dealing with the fs interface. There are currently insufficient hooks in the LSM for dealing with interactions between policy namespaces and the rest of the system namespaces. Lukasz Pawelczyk posted a set of 3 patches a while ago now, focused on needs for providing some namespacing smack. user_ns: 3 new LSM hooks for user namespace operations I have messed with these and they are worth looking at. I plan to prose a new revision of the patch series hopefully soon. |
From: Magalhaes, G. (B. R&D-CL) <gui...@hp...> - 2017-05-29 20:35:34
|
Hi Mimi, Thanks for the feedback. > (Wow, you should did Cc a lot of people.) Reducing the list for now. >I'm really sorry Guileherme, but as I previously explained, IMA has >many aspects to it - the original file measurements (IMA-measurement), >file hash/signature appraisal (IMA-appraisal), and file audit messages >(IMA-audit) used for security analytics/forensics, not the file system >auditing. To namespace IMA properly requires addressing some >underlying problems - >securityfs, root privilege required for writing >security xattrs, per namespace IMA keyring - to name a few. We really considered all these aspects and they are either already addressed on this patch series or planed as future work items. That means we already have in plans incremental changes without compromising our basic design. We should have sent a summary of the design assumptions before hand, sorry. So, let me take this opportunity to present some of them. I believe we should have a brief phone conference to clarify the plan and make sure we are all on the same page. >- IMA-measurements: > >The namespacing design will need to support different types of environments. > For example, depending on the environment, namespaces can come and go >frequently. In such an environment do we really want all the namespace >measurements to be included in the system measurement list, or should each >namespace have its own measurement list? As a first step, we suggest a single measurement list for the entire system. The reason is what remote attestation requires. We would need a solution for the small number of TPM PCR limitation. The vTPM is not a simple solution and would need some effort on its own to be integrated with containers. Basically, we would need to adapt vTPM from VMs to the containers reality, maybe protecting the software stack with Intel SGX or other similar technology. So, we considered again this is a future work item and still possible to evolve from our first implementation. >Should the namespace measurement policy be the same as the system >measurement policy? Should the namespace (container) owner be allowed to >modify their own policy? If a file matches a rule in both the namespace and >system policies, should the file measurement be in both the namespace and the >system measurement lists? Most of this patch series is about policy per namespace. So, basically we propose one policy per namespace, so each namespace (container) could define what to measure and appraise. On our design, until a new namespace defines a custom policy, it is subject to the system policy. So, we designed that a namespace will always follow an IMA policy no matter what and then the current design is flexible enough to cover different ways to assure a namespace follows a policy. The detail about who/where a custom measurement policy is defined, we already discussed previously about the possible options (securityfs symlink, bind mount, etc). Again, this detail doesn't compromise the proposed design. >- IMA-appraisal > >Assuming the IMA appraisal policy requires file signatures, signatures are >verified based on the keys on the IMA keyring. When discussing namespacing >IMA-appraisal, we might want different sets of keys in different namespaces. >This requires separate keyrings for each namespace. In some use cases, we >might want to include the keys on the system IMA keyring, while in other use >cases we might not. Good point. This still is a future work item we could address in a later patch. Additionally, each namespace may require a different measurement template, and template per namespace is not yet supported on this patch set, but already in plan. >Even if real root initially installs the files with their file signatures, stored as >extended attributes, how will software be updated, as writing file signatures >requires root privilege?Capabilities has recently added support to permit root >in the namespace to write security.capability. Similarly when namespacing >IMA root in the namespace needs the ability to write security.ima. If I understood the problem correctly, we just need to replace, in the IMA hooks, the capable() calls with ns_capable(). This will make sure the capability checks will consider the correct namespace setting for the current user namespace. For instance, a CAP_SYS_ADMIN could be enabled for a fake 'root' user inside a given namespace (container), and that is enough for this fake root to set security.ima (through evmctl possibly). >- IMA-audit: >The IMA-audit messages can augment other file system security information >used in security analytics/forensics. This information should be on a per >namespace basis, meaning that each time a new file is accessed/executed, >there needs to be a separate audit message, even if a message already exists >in another namespace. Maintaining and cleaning up this per namespace cache >information, allows development of the IMA namespace architecture >independently of other issues. My understanding is that the Audit subsystem manages on its own, by using a daemon per user namespace, the separation of messages per namespace. Audit API (audit_log_start, audit_log_end, etc) clients, on its turn, must generate the proper record and then use the Audit API to queue that record. What we did was to add enough fields to the record to properly identify a pathname, considering multiple mount namespaces. I thought this is what was missing on the IMA perspective. Please clarify. >As both Apparmor and IMA use securityfs for policy, it would be nice if their > method for loading namespace policies would be similar too. Ok, we need to take a look then. -- Guilherme |
From: Mimi Z. <zo...@li...> - 2017-05-29 17:33:52
|
Hi Guilherme, (Wow, you should did Cc a lot of people.) On Thu, 2017-05-25 at 19:04 +0000, Magalhaes, Guilherme (Brazil R&D- CL) wrote: > Mimi, > With the securityfs symlink we would address the case of setting > policy inside containers, but we still would need a way to set the > IMA policy per namespace outside containers. So, the current > proposed interface would address the latter case. > As an alternative to symlinks, taking this patch set as base, and > still considering setting policy inside containers (or inside > namespaces in general), it is possible to bind mount the securityfs > files into the containers, but it would be needed to prevent > read/write access to the namespaced IMA policy files for processes > not running on the same namespace. > > These mechanisms would not require a change in the proposed design. > Do you think these mechanisms are enough for the flexibility you > asked? I'm really sorry Guileherme, but as I previously explained, IMA has many aspects to it - the original file measurements (IMA-measurement), file hash/signature appraisal (IMA-appraisal), and file audit messages (IMA-audit) used for security analytics/forensics, not the file system auditing. To namespace IMA properly requires addressing some underlying problems - securityfs, root privilege required for writing security xattrs, per namespace IMA keyring - to name a few. I understand wanting to namespace the appraisal aspect first, but when you asked me if anyone else is working on namespacing IMA at the moment, I suggested starting with the IMA-audit aspect for a reason. By beginning with the IMA-audit aspect, we could ignore, at least for the time being, some of these underlying problems, but define the basic namespacing architecture. By jumping to namespacing the appraisal aspect, you've simply avoided addressing the IMA namespacing architecture issues, which need to be addressed. Here are some, not by any means all, of the issues with namespacing IMA. - IMA-measurements: The namespacing design will need to support different types of environments. For example, depending on the environment, namespaces can come and go frequently. In such an environment do we really want all the namespace measurements to be included in the system measurement list, or should each namespace have its own measurement list? Should the namespace measurement policy be the same as the system measurement policy? Should the namespace (container) owner be allowed to modify their own policy? If a file matches a rule in both the namespace and system policies, should the file measurement be in both the namespace and the system measurement lists? - IMA-appraisal Assuming the IMA appraisal policy requires file signatures, signatures are verified based on the keys on the IMA keyring. When discussing namespacing IMA-appraisal, we might want different sets of keys in different namespaces. This requires separate keyrings for each namespace. In some use cases, we might want to include the keys on the system IMA keyring, while in other use cases we might not. Even if real root initially installs the files with their file signatures, stored as extended attributes, how will software be updated, as writing file signatures requires root privilege?Capabilities has recently added support to permit root in the namespace to write security.capability. Similarly when namespacing IMA, root in the namespace needs the ability to write security.ima. - IMA-audit: The IMA-audit messages can augment other file system security information used in security analytics/forensics. This information should be on a per namespace basis, meaning that each time a new file is accessed/executed, there needs to be a separate audit message, even if a message already exists in another namespace. Maintaining and cleaning up this per namespace cache information, allows development of the IMA namespace architecture independently of other issues. My original suggestion stands. Start with namespacing IMA- audit. Afterwards resolve the securityfs issues needed for namespacing IMA-measurement, and subsequently resolve the keyring and xattr issues for namespacing IMA-appraisal. Although other subsystems have already addressed some of the issues listed here, the advice to start with IMA-audit is still valid. Small incremental change does not imply without an overall design, but an overall design which is broken up in such a way (to ease review) that builds upon the previous change. As both Apparmor and IMA use securityfs for policy, it would be nice if their method for loading namespace policies would be similar too. Mimi |
From: Dmitry K. <dmi...@gm...> - 2017-05-29 15:26:39
|
Hi, I will check it soon Thanks, Dmitry On Tue, May 23, 2017 at 5:02 PM, Magalhaes, Guilherme (Brazil R&D-CL) <gui...@hp...> wrote: > Hi, > Have you taken a look into this patch set? Please let me know your comments. > > -- > Guilherme > > -----Original Message----- > From: Magalhaes, Guilherme (Brazil R&D-CL) > Sent: quinta-feira, 11 de maio de 2017 11:54 > To: dmi...@gm...; zo...@li... > Cc: lin...@li...; lin...@vg...; lin...@li...; lin...@vg...; vi...@ze...; jam...@or...; lin...@vg...; Souza, Joaquim (Brazil R&D-ECL) <joa...@hp...>; se...@ha... > Subject: Re: [Linux-ima-user] [RFC 00/11] ima: namespace support for IMA policy > > I would like to replace part of the email below which briefly presents each one of the patches in this series. This is the right summary: > > -- > Patches 1, 2 and 3 qualify the file pathname considering multiple namespaces. > Patch 4 adds the namespace securityfs file which is the interface to define IMA policy per namespace. New policy file is created for each namespace and the policy securityfs mechanism is completely reused. > Patch 6 adds a hook to fs/namespace.c to automatically delete all namespace IMA policy resources such as radix tree entry and securityfs files. > Patches 8 and 9 are small implementation details Patches 5, 7, 10 are the key changes to encapsulate all policy rules and flags in a structure per namespace. The correct structure is retrieved for the target namespace and the namespace rules are used on that context. > Patch 11 adds the enforce_ns appraise mode which enables different appraise modes per namespace. > -- > > ---- > Guilherme > > -----Original Message----- > From: Magalhaes, Guilherme (Brazil R&D-CL) > Sent: quinta-feira, 11 de maio de 2017 11:00 > To: dmi...@gm...; zo...@li... > Cc: vi...@ze...; jam...@or...; se...@ha...; lin...@vg...; lin...@vg...; lin...@li...; lin...@li...; lin...@vg...; ty...@do...; Souza, Joaquim (Brazil R&D-ECL) <joa...@hp...>; Edwards, Nigel <nig...@hp...>; Magalhaes, Guilherme (Brazil R&D-CL) <gui...@hp...> > Subject: [RFC 00/11] ima: namespace support for IMA policy > > The IMA policy rules and policy/appraise flags are now encapsulated on a new structure which completely describes the policy for a given namespace. The correct namespace structure is retrieved from a radix tree based on the namespace id in use by the process in the context whenever the IMA policy rules or flags are needed. The existent securityfs interface is reused to define policy per namespace. A new namespace file is used to create a folder for a given namespace id with a policy file which can then be used to define rules for that namespace. > > Patches 1, 2 and 4 qualify the file pathname considering multiple namespaces. > Patch 3 adds a new kernel config which enables all the policy per namespace functionality. > Patch 5 adds the namespace securityfs file which is the interface to define IMA policy per namespace. New policy file is creanted for each namespace and the policy securityfs mechanism is completely reused. > Patche 7 adds a hook to fs/namespace.c to automatically delete all namespace IMA policy resources such as radix tree entry and securityfs files. > Patches 8, 10, 11 and 14 are small implementation details Patches 6, 9, 12 are key changes to encapsulate all policy rules and flags in a structure per namespace. The correct structure is retrieved for the target namespace and the namespace rules are used on that context. > Patch 13 adds the enforce_ns appraise mode which enables different appraise modes per namespace. > > Other areas might still need work to completely namespace IMA. For instance, EVM and templates per namespace are not yet covered. > > Guilherme Magalhaes (11): > ima: qualify pathname in audit info record > ima: qualify pathname in audit measurement record > ima: qualify pathname in measurement file > ima: add support to namespace securityfs file > ima: store new namespace policy structure in a radix tree > ima, fs: release namespace policy resources > ima: new namespace policy structure to track initial namespace policy > data > ima: block initial namespace id on the namespace policy interface > ima: delete namespace policy securityfs file in write-once mode > ima: handling all policy flags per namespace using ima_ns_policy > structure > ima: appraise mode per namespace with new enforce_ns appraise mode > > fs/namespace.c | 4 + > include/linux/integrity.h | 9 + > security/integrity/ima/Kconfig | 8 + > security/integrity/ima/ima.h | 78 ++++- > security/integrity/ima/ima_api.c | 14 +- > security/integrity/ima/ima_appraise.c | 30 +- > security/integrity/ima/ima_fs.c | 454 ++++++++++++++++++++++++++++-- > security/integrity/ima/ima_init.c | 13 +- > security/integrity/ima/ima_main.c | 40 ++- > security/integrity/ima/ima_policy.c | 210 +++++++++++--- > security/integrity/ima/ima_template.c | 10 +- > security/integrity/ima/ima_template_lib.c | 70 +++++ security/integrity/ima/ima_template_lib.h | 13 + > security/integrity/integrity_audit.c | 5 + > 14 files changed, 860 insertions(+), 98 deletions(-) > > -- > 2.7.4 > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ > Linux-ima-user mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-ima-user -- Thanks, Dmitry |
From: Magalhaes, G. (B. R&D-CL) <gui...@hp...> - 2017-05-25 19:04:25
|
Mimi, With the securityfs symlink we would address the case of setting policy inside containers, but we still would need a way to set the IMA policy per namespace outside containers. So, the current proposed interface would address the latter case. As an alternative to symlinks, taking this patch set as base, and still considering setting policy inside containers (or inside namespaces in general), it is possible to bind mount the securityfs files into the containers, but it would be needed to prevent read/write access to the namespaced IMA policy files for processes not running on the same namespace. These mechanisms would not require a change in the proposed design. Do you think these mechanisms are enough for the flexibility you asked? Thanks. -- Guilherme -----Original Message----- From: Mimi Zohar [mailto:zo...@li...] Sent: quinta-feira, 25 de maio de 2017 08:46 To: John Johansen <joh...@ca...>; Magalhaes, Guilherme (Brazil R&D-CL) <gui...@hp...>; dmi...@gm... Cc: vi...@ze...; jam...@or...; se...@ha...; lin...@vg...; lin...@vg...; lin...@li...; lin...@li...; lin...@vg...; ty...@do...; Souza, Joaquim (Brazil R&D-ECL) <joa...@hp...>; Edwards, Nigel <nig...@hp...> Subject: Re: [RFC 04/11] ima: add support to namespace securityfs file Hi John, On Thu, 2017-05-25 at 00:36 -0700, John Johansen wrote: > On 05/24/2017 01:12 PM, Mimi Zohar wrote: > > On Thu, 2017-05-11 at 10:59 -0300, Guilherme Magalhaes wrote: > >> Creating the namespace securityfs file under ima folder. When a > >> mount namespace id is written to the namespace file, a new folder > >> is created and with a policy file for that specified namespace. > >> Then, user defined policy for namespaces may be set by writing rules to this namespace policy file. > >> With this interface, there is no need to give visibility for the > >> securityfs inside mount namespaces or containers in userspace. > >> > >> Signed-off-by: Guilherme Magalhaes <gui...@hp...> > > > > The design needs to be flexible enough for different types of > > containers, not just for when the orchestration layer provides the > > policy. With this design, the container owner has no control over > > the policy. > > > > One option is that we bind mount the securityfs/policy, so that root > > in the container will be allowed to read/write the policy. At some > > point, we might connect a vTPM to the container so that the > > container owner would be able to get a quote. For now even without > > a vTPM, the same mechanism would allow root within the container to > > read the measurement list. > > > I haven't looked at this enough yet on IMAs end, but another possible > solution is using a symlink and a magic jump_link similar to what nsfs is doing. > > The patch series I posted out a couple of weeks ago > [RFC][Patch 0/3] securityfs: add the ability to support symlinks > > adds symlink support to securityfs, and then patch 3/3 cribs from nsfs > updating apparmorfs to use jump_link to "virtualize" the apparmor > policy directory. This avoids needing to have the bind mount. > > I'll break the patch out more and repost so its easier to see if this > approach might work for IMA. Sorry, I've been meaning to take a look at your patches, but just haven't gotten to it yet. This approach sounds really promising. thanks, Mimi |
From: Mimi Z. <zo...@li...> - 2017-05-25 11:47:20
|
Hi John, On Thu, 2017-05-25 at 00:36 -0700, John Johansen wrote: > On 05/24/2017 01:12 PM, Mimi Zohar wrote: > > On Thu, 2017-05-11 at 10:59 -0300, Guilherme Magalhaes wrote: > >> Creating the namespace securityfs file under ima folder. When a mount > >> namespace id is written to the namespace file, a new folder is created and > >> with a policy file for that specified namespace. Then, user defined policy > >> for namespaces may be set by writing rules to this namespace policy file. > >> With this interface, there is no need to give visibility for the securityfs > >> inside mount namespaces or containers in userspace. > >> > >> Signed-off-by: Guilherme Magalhaes <gui...@hp...> > > > > The design needs to be flexible enough for different types of > > containers, not just for when the orchestration layer provides the > > policy. With this design, the container owner has no control over the > > policy. > > > > One option is that we bind mount the securityfs/policy, so that root > > in the container will be allowed to read/write the policy. At some > > point, we might connect a vTPM to the container so that the container > > owner would be able to get a quote. For now even without a vTPM, the > > same mechanism would allow root within the container to read the > > measurement list. > > > I haven't looked at this enough yet on IMAs end, but another possible solution > is using a symlink and a magic jump_link similar to what nsfs is doing. > > The patch series I posted out a couple of weeks ago > [RFC][Patch 0/3] securityfs: add the ability to support symlinks > > adds symlink support to securityfs, and then patch 3/3 cribs from nsfs > updating apparmorfs to use jump_link to "virtualize" the apparmor policy > directory. This avoids needing to have the bind mount. > > I'll break the patch out more and repost so its easier to see if this > approach might work for IMA. Sorry, I've been meaning to take a look at your patches, but just haven't gotten to it yet. This approach sounds really promising. thanks, Mimi |
From: John J. <joh...@ca...> - 2017-05-25 07:37:21
|
On 05/24/2017 01:12 PM, Mimi Zohar wrote: > On Thu, 2017-05-11 at 10:59 -0300, Guilherme Magalhaes wrote: >> Creating the namespace securityfs file under ima folder. When a mount >> namespace id is written to the namespace file, a new folder is created and >> with a policy file for that specified namespace. Then, user defined policy >> for namespaces may be set by writing rules to this namespace policy file. >> With this interface, there is no need to give visibility for the securityfs >> inside mount namespaces or containers in userspace. >> >> Signed-off-by: Guilherme Magalhaes <gui...@hp...> > > The design needs to be flexible enough for different types of > containers, not just for when the orchestration layer provides the > policy. With this design, the container owner has no control over the > policy. > > One option is that we bind mount the securityfs/policy, so that root > in the container will be allowed to read/write the policy. At some > point, we might connect a vTPM to the container so that the container > owner would be able to get a quote. For now even without a vTPM, the > same mechanism would allow root within the container to read the > measurement list. > I haven't looked at this enough yet on IMAs end, but another possible solution is using a symlink and a magic jump_link similar to what nsfs is doing. The patch series I posted out a couple of weeks ago [RFC][Patch 0/3] securityfs: add the ability to support symlinks adds symlink support to securityfs, and then patch 3/3 cribs from nsfs updating apparmorfs to use jump_link to "virtualize" the apparmor policy directory. This avoids needing to have the bind mount. I'll break the patch out more and repost so its easier to see if this approach might work for IMA. |
From: Mimi Z. <zo...@li...> - 2017-05-24 20:14:02
|
On Thu, 2017-05-11 at 10:59 -0300, Guilherme Magalhaes wrote: > Creating the namespace securityfs file under ima folder. When a mount > namespace id is written to the namespace file, a new folder is created and > with a policy file for that specified namespace. Then, user defined policy > for namespaces may be set by writing rules to this namespace policy file. > With this interface, there is no need to give visibility for the securityfs > inside mount namespaces or containers in userspace. > > Signed-off-by: Guilherme Magalhaes <gui...@hp...> The design needs to be flexible enough for different types of containers, not just for when the orchestration layer provides the policy. With this design, the container owner has no control over the policy. One option is that we bind mount the securityfs/policy, so that root in the container will be allowed to read/write the policy. At some point, we might connect a vTPM to the container so that the container owner would be able to get a quote. For now even without a vTPM, the same mechanism would allow root within the container to read the measurement list. Mimi > --- > security/integrity/ima/ima.h | 4 + > security/integrity/ima/ima_fs.c | 183 ++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 187 insertions(+) > > diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h > index 42fb91ba..6e8ca8e 100644 > --- a/security/integrity/ima/ima.h > +++ b/security/integrity/ima/ima.h > @@ -326,4 +326,8 @@ static inline int security_filter_rule_match(u32 secid, u32 field, u32 op, > #define POLICY_FILE_FLAGS S_IWUSR > #endif /* CONFIG_IMA_WRITE_POLICY */ > > +#ifdef CONFIG_IMA_PER_NAMESPACE > +#define NAMESPACES_FILE_FLAGS S_IWUSR > +#endif > + > #endif /* __LINUX_IMA_H */ > diff --git a/security/integrity/ima/ima_fs.c b/security/integrity/ima/ima_fs.c > index ca303e5..6456407 100644 > --- a/security/integrity/ima/ima_fs.c > +++ b/security/integrity/ima/ima_fs.c > @@ -23,6 +23,8 @@ > #include <linux/rcupdate.h> > #include <linux/parser.h> > #include <linux/vmalloc.h> > +#include <linux/proc_ns.h> > +#include <linux/radix-tree.h> > > #include "ima.h" > > @@ -272,6 +274,40 @@ static const struct file_operations ima_ascii_measurements_ops = { > .release = seq_release, > }; > > +#ifdef CONFIG_IMA_PER_NAMESPACE > +/* > + * check_mntns: check a mount namespace is valid > + * > + * @ns_id: namespace id to be checked > + * Returns 0 if the namespace is valid. > + * > + * Note: a better way to implement this check is needed. There are > + * cases where the namespace id is valid but not in use by any process > + * and then this implementation misses this case. Could we use an > + * interface similar to what setns implements? > + */ > +static int check_mntns(unsigned int ns_id) > +{ > + struct task_struct *p; > + int result = 1; > + struct ns_common *ns; > + > + rcu_read_lock(); > + for_each_process(p) { > + ns = mntns_operations.get(p); > + if (ns->inum == ns_id) { > + result = 0; > + mntns_operations.put(ns); > + break; > + } > + mntns_operations.put(ns); > + } > + rcu_read_unlock(); > + > + return result; > +} > +#endif > + > static ssize_t ima_read_policy(char *path) > { > void *data; > @@ -366,6 +402,9 @@ static struct dentry *ascii_runtime_measurements; > static struct dentry *runtime_measurements_count; > static struct dentry *violations; > static struct dentry *ima_policy; > +#ifdef CONFIG_IMA_PER_NAMESPACE > +static struct dentry *ima_namespaces; > +#endif > > enum ima_fs_flags { > IMA_FS_BUSY, > @@ -451,6 +490,139 @@ static const struct file_operations ima_measure_policy_ops = { > .llseek = generic_file_llseek, > }; > > +#ifdef CONFIG_IMA_PER_NAMESPACE > +/* > + * Assumes namespace id is in use by some process and this mapping > + * does not exist in the map table. > + */ > +static int create_mnt_ns_directory(unsigned int ns_id) > +{ > + int result; > + struct dentry *ns_dir, *ns_policy; > + char dir_name[64]; > + > + snprintf(dir_name, sizeof(dir_name), "%u", ns_id); > + > + ns_dir = securityfs_create_dir(dir_name, ima_dir); > + if (IS_ERR(ns_dir)) { > + result = PTR_ERR(ns_dir); > + goto out; > + } > + > + ns_policy = securityfs_create_file("policy", POLICY_FILE_FLAGS, > + ns_dir, NULL, > + &ima_measure_policy_ops); > + if (IS_ERR(ns_policy)) { > + result = PTR_ERR(ns_policy); > + securityfs_remove(ns_dir); > + goto out; > + } > + > + result = 0; > + > +out: > + return result; > +} > + > +static ssize_t handle_new_namespace_policy(const char *data, size_t datalen) > +{ > + unsigned int ns_id; > + ssize_t result; > + > + result = -EINVAL; > + > + if (sscanf(data, "%u", &ns_id) != 1) { > + pr_err("IMA: invalid namespace id: %s\n", data); > + goto out; > + } > + > + if (check_mntns(ns_id)) { > + result = -ENOENT; > + pr_err("IMA: unused namespace id %u\n", ns_id); > + goto out; > + } > + > + result = create_mnt_ns_directory(ns_id); > + if (result != 0) { > + pr_err("IMA: namespace id %u directory creation failed\n", ns_id); > + goto out; > + } > + > + result = datalen; > + pr_info("IMA: directory created for namespace id %u\n", ns_id); > + > +out: > + return result; > +} > + > +static ssize_t ima_write_namespaces(struct file *file, const char __user *buf, > + size_t datalen, loff_t *ppos) > +{ > + char *data; > + ssize_t result; > + > + if (datalen >= PAGE_SIZE) > + datalen = PAGE_SIZE - 1; > + > + /* No partial writes. */ > + result = -EINVAL; > + if (*ppos != 0) > + goto out; > + > + result = -ENOMEM; > + data = kmalloc(datalen + 1, GFP_KERNEL); > + if (!data) > + goto out; > + > + *(data + datalen) = '\0'; > + > + result = -EFAULT; > + if (copy_from_user(data, buf, datalen)) > + goto out_free; > + > + result = mutex_lock_interruptible(&ima_write_mutex); > + if (result < 0) > + goto out_free; > + > + result = handle_new_namespace_policy(data, datalen); > + > + mutex_unlock(&ima_write_mutex); > + > +out_free: > + kfree(data); > +out: > + return result; > +} > + > +static int ima_open_namespaces(struct inode *inode, struct file *filp) > +{ > + if (!(filp->f_flags & O_WRONLY)) > + return -EACCES; > + > + if (!capable(CAP_SYS_ADMIN)) > + return -EPERM; > + > + if (test_and_set_bit(IMA_FS_BUSY, &ima_fs_flags)) > + return -EBUSY; > + return 0; > +} > + > +static int ima_release_namespaces(struct inode *inode, struct file *file) > +{ > + clear_bit(IMA_FS_BUSY, &ima_fs_flags); > + > + return 0; > +} > + > +static const struct file_operations ima_namespaces_ops = { > + .open = ima_open_namespaces, > + .write = ima_write_namespaces, > + .read = seq_read, > + .release = ima_release_namespaces, > + .llseek = generic_file_llseek, > +}; > +#endif > + > int __init ima_fs_init(void) > { > ima_dir = securityfs_create_dir("ima", NULL); > @@ -490,6 +662,14 @@ int __init ima_fs_init(void) > if (IS_ERR(ima_policy)) > goto out; > > +#ifdef CONFIG_IMA_PER_NAMESPACE > + ima_namespaces = securityfs_create_file("namespaces", NAMESPACES_FILE_FLAGS, > + ima_dir, NULL, > + &ima_namespaces_ops); > + if (IS_ERR(ima_namespaces)) > + goto out; > +#endif > + > return 0; > out: > securityfs_remove(violations); > @@ -498,5 +678,8 @@ int __init ima_fs_init(void) > securityfs_remove(binary_runtime_measurements); > securityfs_remove(ima_dir); > securityfs_remove(ima_policy); > +#ifdef CONFIG_IMA_PER_NAMESPACE > + securityfs_remove(ima_namespaces); > +#endif > return -1; > } |
From: Magalhaes, G. (B. R&D-CL) <gui...@hp...> - 2017-05-23 14:03:37
|
Hi, Have you taken a look into this patch set? Please let me know your comments. -- Guilherme -----Original Message----- From: Magalhaes, Guilherme (Brazil R&D-CL) Sent: quinta-feira, 11 de maio de 2017 11:54 To: dmi...@gm...; zo...@li... Cc: lin...@li...; lin...@vg...; lin...@li...; lin...@vg...; vi...@ze...; jam...@or...; lin...@vg...; Souza, Joaquim (Brazil R&D-ECL) <joa...@hp...>; se...@ha... Subject: Re: [Linux-ima-user] [RFC 00/11] ima: namespace support for IMA policy I would like to replace part of the email below which briefly presents each one of the patches in this series. This is the right summary: -- Patches 1, 2 and 3 qualify the file pathname considering multiple namespaces. Patch 4 adds the namespace securityfs file which is the interface to define IMA policy per namespace. New policy file is created for each namespace and the policy securityfs mechanism is completely reused. Patch 6 adds a hook to fs/namespace.c to automatically delete all namespace IMA policy resources such as radix tree entry and securityfs files. Patches 8 and 9 are small implementation details Patches 5, 7, 10 are the key changes to encapsulate all policy rules and flags in a structure per namespace. The correct structure is retrieved for the target namespace and the namespace rules are used on that context. Patch 11 adds the enforce_ns appraise mode which enables different appraise modes per namespace. -- ---- Guilherme -----Original Message----- From: Magalhaes, Guilherme (Brazil R&D-CL) Sent: quinta-feira, 11 de maio de 2017 11:00 To: dmi...@gm...; zo...@li... Cc: vi...@ze...; jam...@or...; se...@ha...; lin...@vg...; lin...@vg...; lin...@li...; lin...@li...; lin...@vg...; ty...@do...; Souza, Joaquim (Brazil R&D-ECL) <joa...@hp...>; Edwards, Nigel <nig...@hp...>; Magalhaes, Guilherme (Brazil R&D-CL) <gui...@hp...> Subject: [RFC 00/11] ima: namespace support for IMA policy The IMA policy rules and policy/appraise flags are now encapsulated on a new structure which completely describes the policy for a given namespace. The correct namespace structure is retrieved from a radix tree based on the namespace id in use by the process in the context whenever the IMA policy rules or flags are needed. The existent securityfs interface is reused to define policy per namespace. A new namespace file is used to create a folder for a given namespace id with a policy file which can then be used to define rules for that namespace. Patches 1, 2 and 4 qualify the file pathname considering multiple namespaces. Patch 3 adds a new kernel config which enables all the policy per namespace functionality. Patch 5 adds the namespace securityfs file which is the interface to define IMA policy per namespace. New policy file is creanted for each namespace and the policy securityfs mechanism is completely reused. Patche 7 adds a hook to fs/namespace.c to automatically delete all namespace IMA policy resources such as radix tree entry and securityfs files. Patches 8, 10, 11 and 14 are small implementation details Patches 6, 9, 12 are key changes to encapsulate all policy rules and flags in a structure per namespace. The correct structure is retrieved for the target namespace and the namespace rules are used on that context. Patch 13 adds the enforce_ns appraise mode which enables different appraise modes per namespace. Other areas might still need work to completely namespace IMA. For instance, EVM and templates per namespace are not yet covered. Guilherme Magalhaes (11): ima: qualify pathname in audit info record ima: qualify pathname in audit measurement record ima: qualify pathname in measurement file ima: add support to namespace securityfs file ima: store new namespace policy structure in a radix tree ima, fs: release namespace policy resources ima: new namespace policy structure to track initial namespace policy data ima: block initial namespace id on the namespace policy interface ima: delete namespace policy securityfs file in write-once mode ima: handling all policy flags per namespace using ima_ns_policy structure ima: appraise mode per namespace with new enforce_ns appraise mode fs/namespace.c | 4 + include/linux/integrity.h | 9 + security/integrity/ima/Kconfig | 8 + security/integrity/ima/ima.h | 78 ++++- security/integrity/ima/ima_api.c | 14 +- security/integrity/ima/ima_appraise.c | 30 +- security/integrity/ima/ima_fs.c | 454 ++++++++++++++++++++++++++++-- security/integrity/ima/ima_init.c | 13 +- security/integrity/ima/ima_main.c | 40 ++- security/integrity/ima/ima_policy.c | 210 +++++++++++--- security/integrity/ima/ima_template.c | 10 +- security/integrity/ima/ima_template_lib.c | 70 +++++ security/integrity/ima/ima_template_lib.h | 13 + security/integrity/integrity_audit.c | 5 + 14 files changed, 860 insertions(+), 98 deletions(-) -- 2.7.4 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linux-ima-user mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linux-ima-user |
From: Tycho A. <ty...@do...> - 2017-05-18 22:05:09
|
Hi Guilherme, On Thu, May 11, 2017 at 10:59:56AM -0300, Guilherme Magalhaes wrote: > +static int ima_open_namespaces(struct inode *inode, struct file *filp) > +{ > + if (!(filp->f_flags & O_WRONLY)) > + return -EACCES; > + > + if (!capable(CAP_SYS_ADMIN)) > + return -EPERM; > + > + if (test_and_set_bit(IMA_FS_BUSY, &ima_fs_flags)) > + return -EBUSY; It probably makes sense to do something like: if (!(ima_appraise & IMA_APPRAISE_NAMESPACE)) return -EINVAL; here. I'll keep playing around with this patchset and see if I have any other feedback. Cheers, Tycho |