>> Yes confirmations are regarded as bad and capability systems don't >have them >> except for the install. Basically with capability security every >application >> has a list of capabilities which the installer will confirm, obviously >some >> things will be red flags ( ie high risk) , one big change is that >.NET >> assemblies are signed by a certificate so you have some idea who the >code >> comes from. Eg a Device Driver will be red flag and caution but most >apps >> will just copy an assembly to a new dir ( green) , A app throws up a >red >> flag it can report why and the risk. I think red flags will be >infrequent >> enough. Like ACL system whether to allow non technical users the right >to >> change device drivers , services and shared lib is a matter of policy. > >But who sets the policy then? Who owns the device?
The build but policy can be altered eg a server would have an admin concept where a mobile phone would not. Capabilities can simulate any ACL based security system but the reverse is not true. ACLs have some advantages , capability others but a system based on Capabilities if fundamentally much more secure though the ultimate security will fluctuate according to the policy. Its quite interesting that Capability systems and Multics were more secure than Unix and preceded it but Unix was a small Multics effort unfortunately we still suffer from a second rate security model. Its worth noting Unix uses capabilities in the form of file descriptors but that's where it ends. > >> Note the difference though with an ACL OS the moment an app is >installed it >> has access to everything the user (or root) has access to. >> >> Lastly the OS trusted parts are untouchable except for a trusted >updater >> which will download the files from a central repository configured at >> install. > >Who decides who is trusted? Trusted is equivalent to the kernel . Since we don't really have a ring 0 / 3 barrier we introduce it in software , certain libs /assemblies are trusted to do certain things eg native code ,pointers , HW access etc these are trusted . Trusted code is not available to non trusted code and has to be specifically made available. User code , drivers and services all run in a .NET sandbox though a few trusted pieces will get pointers to trusted code inserted at bootup. >> You may ask how does it open data files etc , by the user clicking in >a >> trusted file manager the user obviously is approving the action so no >need >> to pop up a dialog etc ( the same on a console if the user specifies >the >> file a file descriptor is passed into the app) . There is a lot of >> information on this and the Research OS are Eros, Capros and Coyotos. > >I guess given the application code is trusted/safe there should be >much less worry about buffer overrun exploits from the data file being >loaded. Sounds reasonable in that case. Correct there are no such exploits in type safe , memory safe code. Note a few trusted pieces can do this but no user code.. ( and that includes services and drivers) . So with less and less C code ( as we convert drivers and libs ) the system will be more and more secure. > >> Yes but you can't have ring 0 having write access and ring 3 not it >has to >> be global once you set a page as Read only the only access is by >changing >> the page to RW. Both MOSA and Sharp OS run with an MMU but still a >single >> address space ( with all ring 0 code) which is ok for them as they are >a >> more simple monolithic design hence they can mark pages as code or >read only > >So they use the MMU as an MPU essentially. Sort of , marking a block of code readonly is only half the job , you still need to prevent seeing it ( ie crypto keys ) or altering it from other processes. This is where the software checks come into it. > >> SOOOS is a microkernel design and I believe to gain >traction/acceptance I >> will need good performance ( with the history of Micro Kernels eg >Mach3 and >> Minix) . With no pages I can't do it in HW though I can use segments. >Note >> on Intel even with no MMU you can have a readonly flat code segment >which >> grows up and a rw data & stack segment which grows from the top down( >or >> visa versa) , you only need the SW check to make sure they don't >overlap( on >> x64 on i386 the HW has a seg limit) > >Yeah there is certainly historical issues to overcome to convince anyone >a microkernel is good for anything. It is for this reason im skipping the MMU and doing it all in compiler /software and ucLinux seems a great match. It already runs and is stable so these checks will gradually improve it. I suspect the code will run 5-10% faster than Gentoo Linux ( since its compiled for the system) , while I acknowledge this as pointless due to HW costs ( though is nice on some portable platforms) it will get it noticed and overcome some microkernel stigma which will allow us to concentrate on things that are more important ie security , reliability and maintability. >> That's attractive though I will need to add a 2 Meg shared.NET lib. >Its >> better to start small. > >I guess getting 32 or 64MB isn't too hard even for embedded systems >these days. 32Mb is viable. I used Compact Framework on CE 4 on these devices (~200Mhz arm) and it worked well. Also note C# apps are the same size as C apps here and can be quite tiny since the lib cost is global. > >> It's the non mutable and parallelism that attracts me esp when new PC >are >> able to run 12 threads in a single 6 core CPU. > >I just saw that there are 32 core mips chips out there (that are real >cheap and rather power efficient too) with lots of fast IO on them >(caviumnetworks makes some for example). I wonder if uclinux runs on >something like that. :) A Linux kernel is prob the first thing that is made at which point getting uClinux shouldn't be that hard. However for SOOOS ( the OS im working on) you need a kernel , a much cut down lib/toolset and a CIL to native compiler ( ie Mono). This compiler is a real issue and why im looking at Mono ( since about 6 people have been writing ours for 2 years) Mono supports S390 , s390x , Sparc , PowerPC ,mx86 , x86-64 , IA64 , Arm ( both endians) , Alpha , Mips and HPPA anything else will require a major piece of work porting the compiler. Since Xiptech has ported uClinux to MIPS platform it should run on the device (as 32 bit) with some work ( since Mips is mono1 not 2) . The beauty is .NET assemblies ( either from Mono Dev , Visual Studio or the command line compilers) will work on any platform making the lib/toolset and user apps much easier. Eg say you have a Option pricing module in C# , it will just run on these devices no work needed. Power efficiency is something that's an important goal, an OS shouldn't have the disk rattling away like my windows laptop. Also regarding OCaml ( F#) this is really nice for web access or XML parsing libs sot sure about something like the scheduler or file system though. Regards, Ben Kloosterman _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
