JP2012226765A - Information processor, access control method, access control program, and recording medium - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an information processor, an access control method, an access control program, and a recording medium that can improve flexibility of access control to a program.SOLUTION: An information processor with a program comprises: access authority information management means for managing access authority information to the program; setting screen display means for displaying a setting screen to execute setting pertaining to an access authority to the program; and access authority change means for changing a range of the access authority permitted by the access authority information, on the basis of access authority change information corresponding to set contents received through the setting screen.

Description

  The present invention relates to an information processing apparatus, an access control method, an access control program, and a recording medium.

  In recent years, general-purpose programming languages such as C language or Java (registered trademark) language using an API (Application Program Interface) that has been made public in image forming apparatuses mainly called multifunction peripherals or multifunction peripherals after shipment. In some cases, development and installation of new applications can be performed (for example, Patent Document 1). In such an image forming apparatus, not only an application developed by a vendor of the image forming apparatus but also an application developed by another software vendor may be installed and used. Under such circumstances, if each application is unconditionally allowed access to the resources (programs, data, etc.) of the image forming apparatus, it is unforeseen such as leakage of confidential information or unauthorized operation of the image forming apparatus. May invite the situation. Therefore, appropriate security management (access control) is required for each application.

  For a Java (registered trademark) application, code-based access control can be performed by a security mechanism provided as a standard in the execution environment of Java (registered trademark). Specifically, access authority can be set in data called a policy according to the location of the program or the signer of the program. However, defining policies for each application (for each program) complicates the work of the administrator and at the same time enlarges the amount of policy information, which may lead to performance degradation.

  Therefore, for example, applications are classified into groups (leveled) according to their reliability, and access authority is set in groups (for each level) within a policy. In this case, if the group granularity (level level) is too fine, the meaning of grouping is lost. Therefore, it is effective to perform grouping (reducing the level steps) by a certain amount of rounding.

  However, a part of the range of access authority necessary for a certain application to realize its function may exceed the range of access authority permitted for the group to which the application belongs (that is, If some authority is not granted, the function of the application may not be realized.) However, if the group to which the application belongs is changed to a group in which access authority is permitted in a larger range, there is a problem that the authority given is too large for the reliability of the application. Therefore, there is a need for a mechanism capable of exceptionally granting an access right that is not permitted to a group to which the application belongs only for a specific application.

  The present invention has been made in view of the above points, and an object thereof is to provide an information processing apparatus, an access control method, an access control program, and a recording medium that can improve the flexibility of access control for a program. To do.

  Accordingly, in order to solve the above-described problems, the present invention displays an information processing apparatus having a program, an access authority information management means for managing the access authority information of the program, and a setting screen for performing settings relating to the access authority of the program A setting screen display unit and an access authority changing unit that changes a range of access authority permitted by the access authority information based on the access authority change information corresponding to the setting content received via the setting screen. .

  According to the present invention, it is possible to provide an information processing apparatus, an access control method, an access control program, and a recording medium that can improve the flexibility of access control for a program.

FIG. 2 is a diagram illustrating an example of a hardware configuration of a multifunction machine according to an embodiment of the present invention. 2 is a diagram illustrating a software configuration example of a multifunction peripheral according to an embodiment of the present invention. It is a figure which shows the structural example of the JSDK application in this Embodiment. It is a figure which shows the example of a definition of the policy setting file in this Embodiment. It is a figure for demonstrating a protection domain. It is a figure which shows the example of a format of a security patch. It is a figure which shows the example of a description of a CalledBy field. It is a figure which shows the 1st description example of a State field. It is a figure which shows the 2nd description example of a State field. It is a figure for demonstrating the process sequence at the time of JSDK application execution. It is a figure which shows the example of a definition of an application management file. It is a figure which shows the example of a display of an application setting screen. It is a figure for demonstrating the starting process of a JSDK application. It is a figure which shows the example of the policy loaded as an object. It is a figure which shows the dynamic change of a policy as a state transition of ProtectionDomain. It is a sequence diagram for demonstrating the process sequence when a policy is changed dynamically. It is a figure for demonstrating an example of the procedure from development of a JSDK application to operation | use. It is a figure which shows an example of an application development application.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a diagram illustrating a hardware configuration example of a multifunction machine according to an embodiment of the present invention. In FIG. 1, the multifunction machine 10 includes a controller 201, an operation panel 202, a facsimile control unit (FCU) 203, an imaging unit 204, a printing unit 205, and the like.

  The controller 201 includes a CPU 211, ASIC 212, NB221, SB222, MEM-P231, MEM-C232, HDD (hard disk drive) 233, memory card slot 234, NIC (network interface controller) 241, USB device 242, IEEE 1394 device 243, and Centronics device. 244.

  The CPU 211 is an IC for various information processing. The ASIC 212 is an IC for various image processing. The NB 221 is a north bridge of the controller 201. The SB 222 is a south bridge of the controller 201. The MEM-P 231 is a system memory of the multifunction machine 10. The MEM-C 232 is a local memory of the multifunction machine 10. The HDD 233 is a storage of the multifunction machine 10. The memory card slot 234 is a slot for setting the memory card 235. The NIC 241 is a controller for network communication using a MAC address. The USB device 242 is a device for providing a USB standard connection terminal. The IEEE 1394 device 243 is a device for providing a connection terminal of the IEEE 1394 standard. The Centronics device 244 is a device for providing a Centronics specification connection terminal.

  The operation panel 202 is hardware (operation unit) for an operator to input to the multifunction device 10 and hardware (display unit) for an operator to obtain an output from the multifunction device 10.

  FIG. 2 is a diagram illustrating a software configuration example of the multifunction peripheral according to the embodiment of the present invention. In FIG. 2, the software of the multifunction machine 10 includes a JSDK application 30, a JSDK platform 40, a native service layer 50, and the like. Each of these software implements its function by causing the CPU 211 to execute the processing procedure implemented in each software.

  The native service layer 50 provides an interface for using functions based on the hardware and software of the multifunction machine 10 to the upper module, and implements the function in response to the interface call (function use request). To control. For example, the native service layer 50 includes a module that provides an interface related to network communication control, a module that provides an interface related to facsimile control, and control of distribution processing of stored documents (document (image) data stored in the HDD 233). A module that provides an interface relating to the image, and a module that provides an interface relating to control of the imaging unit 204 and the printing unit 205. A module that provides an interface related to control of the memory, HDD 233, etc., a module that provides an interface related to control of the operation panel 202, a module that provides an interface related to control of authentication processing and accounting processing, a module that provides an interface related to user information management Is included.

  The JSDK platform 40 is a software platform that provides an execution environment for the JSDK application 30 and provides a Java (registered trademark) interface for the native service layer 50 to an upper module. The JSDK platform 40 includes a Java (registered trademark) standard class, a class library related to a class extended for the multifunction peripheral 10, a Java (registered trademark) virtual machine (VM41), and the like.

  The VM 41 controls the execution of the JSDK application 30 while sequentially interpreting the Java (registered trademark) bytecode. As a part of the control, the VM 41 restricts access to resources such as files, network sockets, and printers by the JSDK application 30 based on a policy defined in a policy configuration file 70 (policy configuration file). . That is, as a Java (registered trademark) standard mechanism, the VM 41 is configured to notify an instance (SecurityManager object) of the SecurityManager class when an access to a resource occurs. The SecurityManager object determines whether or not the resource can be accessed based on the policy setting file 70 in response to the call.

  By the way, the JSDK platform 40 is implemented as an OSGi (Open Service Gateway initiative) platform. The OSGi (Open Service Gateway initiative) platform is a standardized technology by the OSGi Alliance, and a software platform that provides an execution environment for software components created based on open software componentization technology based on the Java (registered trademark) language. It is. On the OSGi platform, Java (registered trademark) language software is implemented in the form of software components called “bundles”. One bundle is composed of one JAR (Java ARchive) file, and can be installed independently and dynamically (without restarting the apparatus).

  The JSDK application 30 is an application (hereinafter referred to as “SDK application”) created using a dedicated SDK (software development kit) published on the JSDK platform 40. Among SDK applications, an application developed using the Java (registered trademark) language is called a JSDK application.

  In the figure, as an example of the JSDK application 30, there are a SAS (SDK Application Service) manager 31, an application bundle 320, a service bundle 330, and the like. The SAS manager 310 performs control such as installation (addition), uninstallation (deletion), activation, and activation cancellation of other JSDK applications 30 (such as the application bundle 320 and the service bundle 330).

  The application bundle 320 is a bundle as the JSDK application 30 that displays an operation screen on the operation panel 202 and is directly used (operated) by an end user via the operation screen. In the drawing, a scan application 321 is shown as an example of the application bundle 320. The scan application 321 is an application that realizes reading of an image from a document by the imaging unit 204.

  The service bundle 330 is a bundle as the JSDK application 30 for providing a service to the application bundle 320 or the like. That is, the service bundle 330 executes processing corresponding to each service bundle 330 in response to a call from the application bundle 320 or the like, and returns the processing result to the application bundle 320 or the like. In the drawing, as an example of the service bundle 330, a scan service 331, a panel service 332, and the like are shown.

  The scan service 331 provides a service related to an image reading function. The panel service 332 provides a service related to display control of the operation panel 202.

  Next, security management related to the JSDK application 30 in the multifunction machine 10 will be described. As described above, the JSDK application 30 is a Java (registered trademark) application developed using the SDK that is effective in the JSDK platform 40. Therefore, an application created by a third vendor or the like after the multifunction device 1 is shipped can be installed in the multifunction device 1 as the JSDK application 30.

  Therefore, the multifunction device 1 classifies the range of access authority to the resources of the multifunction device 1 (categorized into groups) (this level is hereinafter referred to as “security level”), and each JSDK application 30 corresponds to its reliability. The code base access control is realized by giving the security level. The security level can be identified by a signature (electronic signature) attached to each JSDK application 30.

  FIG. 3 is a diagram illustrating a configuration example of the JSDK application according to the present embodiment. As shown in the figure, each JSDK application 30 includes files such as a JAR file 31 and an application management file 51. Here, the signature 33 attached (associated) to the JAR file 31 corresponds to a signature for identifying the security level. For example, the signature 33 is obtained by encrypting the hash value of the JAR file 31, and the security level is identified by the encryption key used for the encryption. The signature 33 is used not only for identifying the security level but also for checking whether the JSDK application 30 has been tampered with. In the present embodiment, the security level has three levels of level 1 (Lv1), level 2 (Lv2), and level 3 (Lv3). Lv1 has the highest access authority, and Lv3 has the lowest access authority.

  The access authority for each security level is defined in the policy setting file 70 based on the specifications of the Java (registered trademark) standard.

  FIG. 4 is a diagram showing a definition example of the policy setting file in the present embodiment. In the figure, since the format of the policy setting file 70 conforms to the specifications of the Java (registered trademark) standard, a detailed description of the format is omitted.

  In the figure, three grant entries are shown. In the signedBy field of the grant entry 71, Lv1 is specified. Therefore, the definition of the grant entry 71 is applied to the JSDK application 30 to which the signature 33 having the security level value Lv1 is attached. Similarly, the grant entry 72 is applied to the JSDK application 30 to which the Lv2 signature 33 is attached, and the grant entry 73 is applied to the atJSDK application 30 to which the Lv3 signature 33 is attached.

  In the grant entry 71, in (a), it is set that all packages (accessClassInPackage. *) Can be accessed at the time of execution (when the JSDK application 30 of Lv1 is executed) (RuntimePermission). In (b), it is set that dynamic linking to all libraries is possible. In (c), it is set that all files on the file system can be read and written.

  Thus, in the policy setting file 70, access authority is defined in correspondence with the security level. Therefore, in the multifunction device 1, the access authority of the JSDK application 30 is determined according to the security level corresponding to the signature 33 assigned to each JSDK application 30.

  By the way, each security level (Lv1, Lv2, Lv3) forms a protection domain (ProtectionDomain) in Java (registered trademark). FIG. 5 is a diagram for explaining the protection domain. A protection domain can be considered as a set of objects (that is, a set of access privileges) that a subject (here, JSDK application 30 or an instance of a class included in JSDK application 30) can directly access. In FIG. class and b. b. For lass, protection domain X is applied, c. class and d. An example in which the protection domain Y is applied to the class is shown. That is, a. class and b. The same access authority belonging to the protection domain X is given to the class. C. class and d. The same access authority belonging to the protection domain Y is given to the class. In the figure, one “access authority” may be considered as one permission entry in the policy setting file 70. One “protection domain” may be considered to correspond to one grant entry. Therefore, in the MFP 10 according to the present embodiment, a protection domain corresponding to Lv1, a protection domain corresponding to Lv2, and a protection domain corresponding to Lv3 are formed.

  Returning to FIG. 3, the application management file 51 is a file in which the components of the JSDK application 30, information necessary for installation, activation, and the like, and other management information are defined. 31. In the present embodiment, the application management file 51 includes a security patch 523. The security patch 523 is a patch (change information or difference information) for a policy definition that is statically set in the policy setting file 70. When the JSDK application 30 is executed, the multifunction machine 10 dynamically changes the definition of the policy setting file 70 by applying the security patch 523 associated with the JSDK application 30 (hereinafter, such a function is referred to as “ Policy dynamic change function ").

  FIG. 6 is a diagram illustrating an example of a security patch format. As shown in the figure, the format of the security patch 523 basically follows the policy format of the Java (registered trademark) standard. However, in the present embodiment, a portion surrounded by a broken line is expanded. That is, it is possible to add a CalledBy field and a State field to the grant entry and permission entry.

  In the CalledBy field, the timing at which the entry (grant entry or permission entry) to which the CalledBy field is assigned becomes valid. The timing is specified by a method call. The CalledBy field contains “CalledBy” from_class_name. to_class_name "". From_class_name is described in the format <calling class name>: <method name>, and to_class_name is described in the format <calling class name>: <method name>. However, the method name and the caller class name can be omitted.

A format example of “from_class_name.to_class_name” and its meaning are shown below.
(1) “Password: getPassWord”
In this case, the entry is validated (policy is changed) when the getPasswordWord method of the Password class is called.
(2) "Apli1: dispPassWord.Password: getPassWord"
In this case, the entry is validated when the getPassWord method of the Password class is called from the dispPassWord method of the Apli class.
(3) “Password”
In this case, the policy is changed when all the methods of the Password class are executed.

  For example, FIG. 7 is a diagram illustrating a description example of the CalledBy field. In the figure, (A) and (B) are defined to be substantially the same. That is, it is defined by the CalledBy field (the part surrounded by a broken line in the figure) that the authority to read the password file (Password.txt) is given when the password class getPasswordWord is called. However, in (A), since the CalledBy field is assigned to the grant entry, if the permission entry includes another permission entry, the CalledBy field is also effective.

  In the State field, the state of the MFP 10 in which the entry to which the State field is assigned becomes valid is designated. The State field is described in the format “State“ State_name ”. In State_name, a character string or a numerical value specifying the state is described.

  For example, when a parameter for identifying the state is fixedly determined, it can be described as follows.

  FIG. 8 is a diagram illustrating a first description example of the State field. In the figure, (A) and (B) are defined to be substantially the same. That is, it is defined by the State field (the part surrounded by a broken line in the figure) that the authority to read the password file (Password.txt) is given when the value of the predetermined parameter is “1”. ing. However, in (A), since the State field is assigned to the grant entry, if the permission entry includes other permission entries, the state field is also effective.

  Further, when it is desired to specify a parameter for identifying the state in the description of the State field, it may be described as follows.

  FIG. 9 is a diagram illustrating a second description example of the State field. In the figure, the State field is described as “State Counter. A == 0”. This is counter. A state where the parameter A is 0 is specified. That is, in (A) and (B) of FIG. When the parameter A is 0, it is defined that the authority to read the password file (Password.txt) is given.

  In the present embodiment, when the CalledBy field and the State field are defined for the same entry, the validity of the entry is determined by the AND condition of the two fields. However, you may make it determine by OR condition.

  Hereinafter, a processing procedure executed by the multifunction machine 10 will be described. FIG. 10 is a diagram for explaining a processing procedure when the JSDK application is executed.

  When a display request for a list of JSDK applications 30 (hereinafter simply referred to as “applications”) that can be activated is input via the operation panel 202 by a user (for example, an administrator) (S101), the SAS manager 310 The application management file 51 associated with each application installed in the MFP 10 and in a startable state is read (S102), and an application list screen is displayed on the operation panel 202 based on the definition information (S103).

  FIG. 11 is a diagram illustrating a definition example of an application management file. The definition example shown in FIG. 11 is expressed in a format obtained by extending JNLP (Java Network Launching Protocol (JSR-56 specification)) based on the XML (eXtensible Markup Language) format.

  In the figure, the definition information of the application management file 51 includes an information element 510 surrounded by <information> tags, a resource element 520 surrounded by <rsource> tags, and the like.

  The information element 510 mainly describes information for identifying an application and the creator of the application. That is, the title element 511 describes the title (application name) of the application. The vendor element 512, telephone element 513, fax element 514, and email element 515 describe the vendor name (vendor name), telephone number, FAX number, and mail address of the application. Further, the product-id element 516, the description element 517, and the icon element 518 describe the product ID of the application, the explanatory text about the application, and the icon file name of the application.

  On the other hand, the resource element 520 describes information related to resources necessary for executing the application. For example, the file name (path name) of the JAR file of the application is described as the value of the href attribute 521 of the jar element. The version of the application is described as the value of the version attribute 522.

  Furthermore, security. A security patch 523 is described as the value of the patch element. Also, security. A comment regarding the security patch 523 is described as the value of the comment attribute 524 of the patch element. Details of the definition contents of the security patch 523 will be described later.

  In step S103, a list of application names and icons of each application that can be activated based on the title element 511 and icon element 518 of the application management file 51 as described above is displayed on the application list screen.

  Subsequently, when an application to be activated is selected from the applications displayed on the application list screen (S104), the SAS manager 310 selects the selected application (hereinafter referred to as “current application”). An application setting screen of the current application is generated based on the application management file 51 etc. associated with, and displayed on the operation panel 202 (S105).

  FIG. 12 is a diagram illustrating a display example of the application setting screen. In the application setting screen 610 shown in the figure, information described in the application management file 51 is displayed as it is for the application name, description, version, product ID, and contact information (telephone, fax, email).

  In the security item 611 and the performance item 613, information related to or affecting the security level and the security patch 523 (that is, information related to the access authority of the current application) is displayed. In the figure, in the security item 611, the security level (level 3) of the current application is displayed, and a check button 612 for selecting whether or not to refer to the password file is displayed together with a message “refer to password file”. Yes. In other words, the current application needs to refer to the password file, and the permission / inhibition of the current application can be selected by the user using the check button 612. The SAS manager 310 determines that the current application is level 3 based on the signature 33 of the current application. The character string “refer to password file” is displayed based on the comment attribute 524 of the application management file 51. The password file is a file in which account information of the user of the multifunction machine 10 is recorded. The policy setting file 70 is an example of a resource for which read authority is not given to the level 3 application.

  In the performance item 613, the radio button 614 can select any one of security priority, optimum, and performance priority for the operation of the current application. This selection corresponds to selection of how faithfully the current application complies with the policy defined in the policy setting file 70. The policy fidelity decreases in the order of security priority-> optimal-> performance priority. However, performance is improved as a trade-off.

  When the user sets the security item 611 and the performance item 613 and clicks the OK button 615 (S106), the SAS manager 310 stores the setting contents in a predetermined parameter stored in the memory of the MFP 10 or the HDD 233. (S107). More specifically, the setting for the check button 612 is recorded as the value of the password file flag variable (passwdFlag). For example, “0” is displayed when the check button 612 is not checked (when password file reference is not permitted), and “1” when the check button 612 is checked (when password file reference is permitted). Is recorded in the password file flag variable. The setting for the radio button 614 is recorded as the value of a performance flag variable (performance Flag). For example, “1” is recorded in the performance flag variable when security is prioritized, “2” is recorded when optimal, and “3” is recorded when performance is prioritized. Subsequently, in response to a request from the SAS manager 310, the VM 41 of the JSDK platform 40 activates the current application (S108).

  Subsequently, the contents of step S108 will be described in detail. FIG. 13 is a diagram for explaining the startup process of the JSDK application.

  In step S1081, the VM 41 reads the JAR file 31 of the current application into the memory. At this time, the signature 33 for the JAR file 31 is also verified. That is, it is verified that the signature 33 is valid and that the JAR file 31 has not been tampered with. Therefore, when the signature 33 is not present or illegal, or when it is detected that the JAR file 31 has been tampered with, the activation of the JSDK application 30 is stopped.

  Subsequently, the VM 41 loads a policy (for example, a grant entry corresponding to Lv3) corresponding to the security level of the current application from the policy setting file 70 as an object (S1082).

  FIG. 14 is a diagram illustrating an example of a policy loaded as an object. In the figure, ProtectionDomain 411 is an instance of the ProtectionDomain class corresponding to the protection domain described above. The ProtectionDomain 411 is instantiated for each grant entry corresponding to the security level of the current application in the policy setting file 70.

  The permission collection 412 is an instance of the permission collection class that manages a set of permission objects as the name implies. The permission object is instantiated for each permission entry in the policy setting file 70 based on a concrete class corresponding to the access right permitted by the entry. In the figure, a RunTimePermission object and a FilePermission object are illustrated.

  As shown in the figure, a relation corresponding to the relation in the policy setting file 70 is formed between the ProtectionDomain 411 and the PermissionCollection 412.

  Subsequently, the VM 41 expands the class definition included in the JAR file 33 of the current application on the memory (S1083), and instantiates the current application based on the class definition (S1084). Subsequently, the VM 41 executes the instantiated current application (S1085).

  Next, a processing procedure when the security patch 523 is applied and the policy is dynamically changed for the application executed through the processing of FIGS. 10 and 13 will be described.

  Here, the security patch 523 included in the application management file 51 of FIG. 11 is referred to again. The security patch 523 includes three permission entries.

  The definition of the permission entry 5231 is “permission java.io.FilePermission“ Password.txt ”,“ read ”, CalledBy“ Password: getPassWord ”, State passwdFlag == 1”. This corresponds to a definition that permits the authority to read a password file (Password.txt). However, the reading authority is permitted by the CalledBy field and the State field when the Password: getPassWord method is called and the value of the password flag (passwdFlag) is 1 (that is, the application setting). The check button 612 on the screen 610 is checked).

  The definition of the permission entry 5232 is “permission java.security.AllPermission State performanceFlag == 2, CalledBy“ Apli1: init ””. This corresponds to a definition that allows all permissions (AllPermission). However, all rights are permitted by the CalledBy field and the State field when the Appli1: init method is called and the value of the performance flag (performance Flag) is 2 (that is, the application setting) And “optimum” is selected in the radio button 613 of the screen 610).

  The definition of the permission entry 5233 is “permission java.security.AllPermission State performanceFlag == 3, CalledBy“ Apli1: dispPassWord ””. This corresponds to a definition that allows all permissions (AllPermission). However, all rights are permitted by the CalledBy field and the State field when the Appli1: dispPassWord method is called and the value of the performance flag (performanceFlag) is 2 (that is, the application setting screen) And “Performance priority” is selected in the radio button 613 of 610).

  As described above, the security patch 523 is defined in correspondence with parameters set on the application setting screen 610 such as a password flag and a performance flag. Therefore, the SAS manager 310 may determine the display content of the application setting screen 610 based on the description of the security patch 523.

  Such a dynamic change of the policy by the security patch 523 can be grasped as a state transition of the ProtectionDomain 411. FIG. 15 is a diagram illustrating a dynamic change of a policy as a state transition of ProtectionDomain. In the same figure, a ProtectionDomain 411 and a permission collection 412 for the application 32 are shown. The application 32 indicates an instance of the current application.

  In the same figure, ProtectionDomain 411 has four states: state PD_Lv3, state PD_Lv3 +, state PD_Optimize, and state PD_Performance.

  The state PD_Lv3 is a state before the policy is dynamically changed by the security patch 523. In this case, an access authority for normal Lv3 is given.

  The state PD_Lv3 + is a state in which, in addition to the access authority of Lv3, the authority to read the password file (Password.txt) is given. The transition condition to this state is based on the password entry 5231 of the security patch 523 (FIG. 11). The getPassword method is being executed. However, the guard condition is that the password file flag is 1 by the State entry in the permission entry 5231.

  The state PD_Optimize is a state where all access rights are granted. The transition condition to this state is that, based on the permission entry 5232, the application 1: init method is being executed in a state where the performance flag (performanceFlag) is set to “2”.

  The state PD_Performance is also a state where all access rights are granted. The transition condition to this state is that, in the state where the performance flag (performanceFlag) is set to “3” based on the permission entry 5233, Appli1: dispPassWord is being executed.

  More specific description will be given below. FIG. 16 is a sequence diagram for explaining a processing procedure when a policy is dynamically changed. In the figure, a processing procedure when the application 32 requests to reference a password file will be described.

  In the figure, “apli1: Apli1” indicates the class name (Apli1) of the current application 32 and the identification name (apli1) of the instance. The current application 32 has an access right to the protection domain of Lv3 (that is, the security level of Lv3 is given). The Password 411 and the Password Word Access 412 are instances of the Password class and the Password Word Access class for accessing the password file (Password.txt) implemented in the JSDK platform 40 in the present embodiment. The Password class has access rights to the Lv2 protection domain. The PassWordAccess class has access authority to the protection domain of Lv1. Also, sm: SecurityManager 413 is an instance of a class that extends the Java (Registered Trademark) standard SecurityManager class for the present embodiment.

  As shown in the figure, in the definition of the policy setting file 70, as the access authority for the password file, read / write authority for Lv1 and read authority for Lv2 are permitted. On the other hand, neither read nor write authority is permitted for Lv3.

For example, when the dispPassWord method of the current application 32 is called,
1) The current application 32 calls the getPassWord method of Password 421 in order to acquire the password information recorded in the storage device in the multifunction machine 10 from within the method (S201). Subsequently, the read method (password file reference request) of PasswordAccess 422 is called in the getPassWord method of Password 421 (S202). Since PasswordAccess 422 is a class that directly accesses the password file, it calls the checkPermission method of the sm: SecurityManager 413 in the read method, thereby inquiring whether or not the password file has read authority (S203).

  Subsequently, the sm: SecurityManager 413 acquires the ProtectionDomain 411 corresponding to the current application 32 from the current application 32 (S204). Note that the sm: SecurityManager 413 can determine the current application 32 (its class name) attempting to access the password file by tracing the stack information.

  Subsequently, the sm: SecurityManager 413 traces the stack information and notifies the ProtectionDomain 411 that the Appli1: dispPassword method and the Password: getPassword method have been called (S205). In response to the notification, the ProtectionDomain 411 determines whether or not state transition is necessary based on the security patch 523 (see FIG. 11) of the current application 32.

  Here, the Permission entry 5231 of the security patch 523 is provided with a CalledBy field (“CalledBy“ Password: getPassWord ””), and the notification in step S205 applies to the condition of the CalledBy field. Therefore, if the value of the password file flag (passwdflag) is “1”, ProtectionDomain 411 changes its state from PD_Lv3 to state PD_Lv3 + and validates permission entry 5231. Specifically, the state transition corresponds to adding a FilePermission object corresponding to the permission entry 5231 to the permission collection 412 (S206).

  However, currently, the Apli1: dispPassWord method is being executed. Therefore, when the value of the performance flag (performanceFlag) is “3”, the ProtectionDomain 411 transits to the state PD_Optimize, and the permission entry 5233 is validated. In this case, an AllPermission object is added to the permission collection 412.

  If the currently executed method (for example, the method called in step S201) is “Appli1: init” and the value of the performance flag (performanceFlag) is “2”, the ProtectionDomain 411 returns to the state PD_Optimize. Transition is made and the permission entry 5232 is made valid. In this case, an AllPermission object is added to the permission collection 412.

  Subsequently, the sm: SecurityManager 413 acquires the permission collection 412 from the protection domain 411 (S207). Subsequently, the sm: SecurityManager 413 inquires of the permission collection 412 whether or not there is a right to read the password file (S208). The permission collection 412 determines whether or not the read authority is present by checking whether or not the permission object corresponding to the read authority for the password file is included in the permission collection 412. Here, the permission object is added in step S206. Therefore, it responds as a determination result that the read authority exists (S209).

  Subsequently, the sm: SecurityManager 413 notifies the ProtectionDomain 411 that it is leaving “Password: getPassword” (S210). In response to the notification, ProtectionDomain 411 returns (transitions) its own state to the original (PD_Lv). Strictly speaking, at this timing, the user has not exited from “Password: getPassword”. However, in the present embodiment, since the event for the ProtectionDomain 411 is issued by the m: SecurityManager 413, the exit is notified at this timing.

  Subsequently, the sm: SecurityManager 413 notifies the password access 422 that there is an access authority (reading authority) (S211). In response to the notification, the password file is read. Note that if the fact that access is not permitted is returned in S209, the sm: SecurityManager 413 issues an exception. The exception is notified to the current application 32.

  In the above description, the event for ProtectionDomain 411 is issued by sm: SecurityManager 413. However, such an event may be issued by current application 32.

  As described above, according to the MFP 10 in the present embodiment, the policy that is statically defined in the policy setting file 70 can be dynamically changed based on the security patch 523. Therefore, the flexibility of access control by the program can be improved appropriately.

  In the present embodiment, the example in which the entry to which the field is added is valid (that is, the authority relating to the entry is given) by the CalledBy field or the State field has been described. However, the entry to which the field is added by the CalledBy field or the State field may be invalidated (that is, the authority related to the entry is revoked). In this case, only in a specific case, it is possible to allow only an authority that is narrower than the authority originally granted.

  By the way, the security function or mechanism for the JSDK application 30 described above functions more effectively when procedures from the development to the operation of the JSDK application 30 are appropriately executed. Therefore, an example of a procedure (business model) from development to operation of the JSDK application 30 will be described below.

  FIG. 17 is a diagram for explaining an example of a procedure from development to operation of a JSDK application.

  First, a package including a JSDK platform 40 and a JSDK application 30 for realizing basic functions by a multifunction device vendor (manufacturer of the multifunction device 10 or a company that performs sales and maintenance of the multifunction device 10) (hereinafter, “JSDK package”). Is sold) (S501). Note that a signature 33 is added in advance to the JSDK application 30 and the like included in the JSDK package by the multifunction machine vendor. The JSDK application 30 included in the JSDK package is developed by the multi-function device vendor itself, and has a high reliability, and is assigned a security level of Lv1 or Lv2.

  The user of the multifunction device 10 purchases the JSDK package (S502), installs the JSDK platform 40, etc., in the multifunction device 10 (S503), and activates the JSDK platform 40 and the JSDK application 30 as necessary. (Use) (S504).

  On the other hand, an application development vendor that develops the JSDK application 30 for function expansion obtains (purchases) the JSDK platform 30 as a development platform, and develops a new JSDK application 30 on the JSDK platform 30 (S505). . Subsequently, the application development vendor creates an application development application (S506) and sends the application development application together with the JAR file of the developed JSDK application 30 to the MFP vendor, thereby approving the sale of the JSDK application 30. (S507).

  FIG. 18 is a diagram illustrating an example of an application development application. In the figure, the application development application form has items such as service bundle, security level, security patch, security patch reason, and performance.

  The service bundle describes the name of the service bundle 330 used by the application target JSDK application 30 (hereinafter referred to as “application target application”). The security level describes the security level required for the application to be applied. The security patch 524 is described in the security patch according to the format described in FIG. 6 as necessary. As the security patch reason, the reason why the security patch 524 is necessary is described. For the performance, a trade-off between the performance and safety of the application to be applied is applied. Specifically, the relationship between performance and safety is divided into stages, and a method for invalidating the security check (access authority check) is described for each stage. In the figure, there are three stages: a) safety priority, b) optimum, and c) performance priority.

Upon receiving an application for approval (S508), the multi-function device vendor evaluates (tests) the application to be applied (S509). In the evaluation, it is verified whether the resource consumption by the application to be applied is within the limit and whether there is a security violation (security patch validity). If the evaluation passes, the multi-function device vendor creates a distribution package for the application application (S510). The distribution package includes an application management file 51 and the like in addition to the JAR file of the application to be applied. In addition, a signature 33 corresponding to the applied security level is given to the JAR file. The signature 33 and the application management file 51 are created by the MFP vendor based on the application development application. Subsequently, the MFP vendor provides the distribution package to the application development vendor (S511).
The application development vendor receives the distribution package (S512) and sells the distribution package to the user (S513). When the user purchases a distribution package (S514), the user installs the JSDK application 30 included in the distribution package in the multi-function peripheral 10 (S515), performs activation (S516), and performs an operation (S517).

  According to the above procedure, the JSDK application 30 developed by the application development vendor is given a security level under the control of the multifunction device vendor, and the application of the security patch 524 is permitted. Therefore, it is possible to more effectively prevent unauthorized application execution.

  As mentioned above, although the Example of this invention was explained in full detail, this invention is not limited to such specific embodiment, In the range of the summary of this invention described in the claim, various deformation | transformation・ Change is possible.

10 MFP 30 JSDK application 40 JSDK platform 41 VM
50 Native service layer 70 Policy setting file 201 Controller 202 Operation panel 203 Facsimile control unit 204 Imaging unit 205 Printing unit 211 CPU
212 ASIC
221 NB
222 SB
231 MEM-P
232 MEM-C
233 HDD
234 Memory card slot 235 Memory card 241 NIC
242 USB device 243 IEEE 1394 device 244 Centronics device 310 SAS manager 320 Application bundle 321 Scan application 330 Service bundle 331 Scan service 332 Panel service

JP 2005-269619 A

Claims (10)

An information processing apparatus having a program,
Access authority information management means for managing program access authority information;
A setting screen display means for displaying a setting screen for setting the program access authority;
An information processing apparatus comprising: access authority changing means for changing a range of access authority permitted in the access authority information based on access authority change information corresponding to setting contents received via the setting screen.   The information processing apparatus according to claim 1, wherein the access authority changing unit changes a range of access authority permitted by the access authority information at a predetermined timing.   The information processing apparatus according to claim 2, wherein the predetermined timing is determined according to the start or execution of the program or according to a state of the information processing apparatus. An access control method executed by an information processing apparatus having a program,
A setting screen display procedure for displaying a setting screen for setting the program access authority;
Program access authority information managed by the access authority information management means of the information processing apparatus based on access authority change information in which access authority change information corresponding to the setting content received via the setting screen is defined And an access right changing procedure for changing a range of access rights permitted by the user.   5. The access control method according to claim 4, wherein the access authority changing procedure changes a range of access authority permitted by the access authority information at a predetermined timing.   The access control method according to claim 5, wherein the predetermined timing is determined when the program is started or executed or according to a state of the information processing apparatus. In an information processing apparatus having a program,
A setting screen display procedure for displaying a setting screen for setting the program access authority;
Program access authority information managed by the access authority information management means of the information processing apparatus based on access authority change information in which access authority change information corresponding to the setting content received via the setting screen is defined An access control program for executing an access authority changing procedure for changing the range of access authority permitted in the system.   8. The access control program according to claim 7, wherein the access authority changing procedure changes a range of access authority permitted by the access authority information at a predetermined timing.   The access control program according to claim 8, wherein the predetermined timing is determined according to activation or execution of the program or according to a state of the information processing apparatus.   10. A computer-readable recording medium on which the access control program according to claim 7 is recorded.

Images